Establish why you are moving
Migrations justified only as modernisation tend to lose support when they get difficult, because there is no measurable outcome to defend. Migrations justified by a specific driver — a datacentre contract ending, capacity limits, a compliance requirement, a genuine cost model — survive contact with the inevitable problems.
Be sceptical of cost savings as the primary rationale. Cloud is often cheaper at variable load and more expensive at steady, predictable load. Model your own usage before promising a number.
Inventory by observation
Ask what depends on a system and you will get an incomplete answer, not through carelessness but because nobody remembers everything. Instrument instead: log every connection, query source, scheduled job, and file access.
Run that for a full business cycle. Month-end, quarter-end, and annual processes exercise code paths that are silent the rest of the time, and those are exactly the ones that fail after cutover.
Classify every workload
Not everything should move the same way, and deciding per workload prevents the common failure of refactoring things that should simply have been retired.
- Retire — still running, no longer used. Surprisingly common, and free capacity.
- Rehost — move as-is. Fastest, cheapest, no cloud-native benefit.
- Replatform — modest changes, such as a managed database. Usually the best return.
- Refactor — genuine rework. Reserve for workloads where the benefit is specific and named.
- Retain — leave in place, for now, with a documented reason and a review date.
Build the landing zone first
Accounts, network topology, identity, logging, and guardrails should exist and be tested before the first workload arrives. Retrofitting structure onto an environment that already has production systems in it is considerably harder.
Define this in code from the start. An environment that was clicked into existence cannot be reliably rebuilt, which removes most of the benefit of moving.
Sequence for reversibility
Move something low-risk first, to exercise the process rather than to prove the technology. The first migration always surfaces gaps in tooling, access, and monitoring, and it is much better to find them on an internal system.
Order the rest so each step can be reversed independently. A sequence where step four cannot be undone without unwinding steps one to three is a sequence with a single point of failure.
Treat data as its own project
Moving an application is weeks. Moving its data, validating it, and proving the copy agrees with the original is where the duration actually is — particularly for historical records written under schema and validation rules that have changed several times.
Plan reconciliation as first-class work with its own tooling and its own acceptance criteria. "The row counts match" is not reconciliation.
Rehearse the cutover and the rollback
A cutover plan that has never been run is a document. Rehearse it at production scale, time every step, and identify the point of no return explicitly.
Rehearse the rollback specifically. It is the part everybody writes down and nobody practises, which is why it so often fails at the one moment it is needed.
Optimise after, not during
Right-sizing during a migration means guessing, because real usage patterns in the new environment are not yet visible. Move first at conservative sizing, observe for a few weeks, then optimise against evidence.
Set up cost monitoring and alerting before the first workload lands. Cloud spend grows quietly, and the first surprising invoice usually arrives a month after anyone would have noticed the cause.
Finish the decommission
A migration is not complete until the old system is switched off and the contract ends. Half-finished migrations that leave both environments running are the most expensive possible outcome, and they are extremely common.
Put a date on decommissioning each source system, with a named owner, at the point the workload moves — not afterwards.