Cloud Migration Guide

Start with a dependency map, not a server inventory

A list of servers tells you what you are running. It does not tell you what breaks when you move something. Before any workload moves, build a map of which services call which, where shared state lives, and which batch jobs quietly assume everything sits on one network.

The uncomfortable finds usually surface here: a reporting script nobody owns, a file drop that a finance process depends on, a hardcoded internal IP in a config file written years ago. Each of these is cheap to fix in the planning phase and expensive to discover during cutover.

• Capture inbound and outbound dependencies for every service, including scheduled jobs
• Identify shared databases — these decide your migration boundaries more than anything else
• Flag every hardcoded hostname, IP address, and file path
• Record data residency and compliance constraints per dataset, not per server

Choose a migration pattern per workload

There is no single right answer for an entire estate. Applying one pattern everywhere is what turns a nine-month plan into a two-year one. Assess each workload independently and accept that a mixed approach is the normal outcome.

• Rehost — move as-is. Fastest path, no cloud-native benefit. Right for stable systems nearing end of life.
• Replatform — move with targeted changes, such as swapping a self-managed database for a managed one. Best effort-to-benefit ratio for most workloads.
• Refactor — restructure the application for the cloud. Reserve this for systems where scaling or delivery speed is an active business constraint.
• Replace — retire the system in favour of a SaaS product. Often the cheapest option, and the one teams consider last.

Move data before you move compute

Compute is disposable; data is not. Establish replication to the target environment early and let it run while the rest of the migration proceeds. This turns cutover from a bulk transfer with a long outage into a short catch-up window.

Validate continuously rather than at the end. Row counts, checksums, and business-level reconciliation queries should run on a schedule against both sides so that drift is caught while it is still small.

Plan the rollback before the cutover

Every cutover plan needs a documented, rehearsed way back. Not a theoretical one — an actual runbook with named owners, a decision deadline, and a tested procedure. Teams that skip this end up making the rollback decision under pressure at 3am, which is when it goes badly.

Set an explicit go/no-go checkpoint with measurable criteria before traffic shifts. If the criteria are not met, the rollback executes automatically rather than being debated.

Budget for the post-migration month

Costs are almost always higher immediately after migration than they were on-premise, because lift-and-shift preserves oversized instances and nobody has tuned anything yet. This is expected, not a failure — but it should be planned for rather than discovered on the first invoice.

Schedule a right-sizing pass four to six weeks after cutover, once real usage patterns are visible. Tag every resource with an owner from day one so that this exercise is possible at all.