Most cloud migration plans are sequenced by how easy each workload looks. That produces an early run of quick wins, followed by a long stall when the team reaches the systems that actually matter and discovers nobody documented how they connect.
A better ordering principle is blast radius: how much breaks, and how visibly, if this move goes wrong on a Tuesday afternoon.
Move the environments nobody sees first
Development, staging and QA should go before anything in production. Not because they are easy, but because they exercise the landing zone, the networking, the identity setup and the runbook while the cost of a mistake is a delayed sprint rather than a customer incident.
Teams that skip this because non-production “does not count” end up discovering their VPC peering assumptions during a production cutover.
Then the workloads with few dependencies
The second wave is anything that can fail alone. Internal tools, batch jobs, reporting systems, anything with a small, well-understood set of callers.
The purpose of this wave is not the workloads themselves. It is building the operational muscle — monitoring, alerting, on-call, rollback — on systems where being wrong is survivable. By the time you reach revenue-critical services, the runbook should be boring.
What should go last
Four categories belong at the end, and usually for different reasons.
The highest-revenue path. Whatever takes the order or processes the payment. Not because it is technically hardest, but because it is the one where an hour of downtime is measured in money and reputation. Move it when the landing zone is mature and the team has rehearsed rollback for real.
Tightly coupled legacy. The system that six other systems talk to through undocumented interfaces. Moving it means moving its dependency graph, and mapping that graph honestly usually takes longer than the migration.
Anything with a data-residency or regulatory constraint. Where data is permitted to live is a legal question before it is an architectural one, and the answer determines the region, the provider and sometimes whether the workload moves at all.
Systems with a hard licensing dependency. Some vendor licences are priced or permitted differently in cloud. Find out before the cutover, not in the renewal conversation afterwards.
Some things should not move
A migration plan that reaches one hundred per cent is usually a plan that stopped asking the question.
Workloads with steady, predictable, high utilisation are frequently cheaper on hardware you already own. So are systems approaching end of life — migrating something you intend to decommission in eighteen months is paying twice for the same retirement.
The honest output of a migration assessment includes a list of things staying where they are, with reasons.
Sequence the data separately from the compute
Applications and their data do not have to move together, and pretending otherwise creates unnecessarily large cutover windows.
The questions that decide this are unglamorous: how much data, how long the copy takes at your actual bandwidth, whether the application tolerates the latency of reaching back across the link during transition, and how you reconcile if you have to roll back after writes have happened on both sides.
That last one is the one people skip, and it is the one that makes a bad night significantly worse.
Define what would make you roll back
Before each wave, write down the conditions under which you revert — specific numbers, decided in advance, by someone who is not going to be awake at 3am arguing about them.
Error rate above what. Latency above what. How long you wait before calling it. Without that, the decision gets made by whoever is most tired, and the usual answer is to push on.
Right-size afterwards, not during
Move like-for-like, then optimise once you have a fortnight of real usage data. Trying to resize during the migration means that when something performs badly you cannot tell whether it is the move or the new instance type.
The optimisation pass is where most of the cost saving actually comes from, and it is the step most often dropped once the migration is declared done.
We plan and run migrations as part of managed cloud services, including the assessment that tells you what should stay put. Tell us what you are running. Before you sign, read what a managed cloud SLA should actually commit to.
Common questions
What should you migrate to the cloud last?
The highest-revenue path, tightly coupled legacy systems, anything with a data-residency or regulatory constraint, and workloads with hard licensing dependencies. Move them once the landing zone is mature and rollback has been rehearsed.
What should move first?
Development, staging and QA. Not because they are easy, but because they exercise the landing zone, networking, identity and runbook while the cost of a mistake is a delayed sprint rather than a customer incident.
Should everything move to the cloud?
No, and a migration plan reaching one hundred per cent usually stopped asking. Steady high-utilisation workloads are often cheaper on hardware you own, and migrating something you will decommission in eighteen months pays twice for the same retirement.
