Cloud migration rarely fails on technology. It fails on sequence. Organizations pick a provider, sign a commitment, and only then discover that a third of their workloads cannot move without an application change nobody scoped. The bill arrives on schedule; the benefits do not.
The framework below is the order we use on migration engagements. It front-loads the decisions that are expensive to reverse and defers the ones that are cheap to change.
1. Assess the estate before you choose the platform
A workload inventory is not a server list. For each application you need four facts: who owns it, what it integrates with, what its data residency and compliance constraints are, and what the business impact is if it is unavailable for four hours. Those four facts determine migration approach far more than CPU and memory profiles do.
Expect the inventory to surface applications nobody claims ownership of. That is a finding, not a delay — undocumented dependencies are the single most common cause of migration rollback.
2. Classify by the 6 Rs, honestly
Rehost, replatform, refactor, repurchase, retire, retain. The discipline is in being honest about refactor. Refactoring is a software project with a software project's timeline, and it should never be hidden inside an infrastructure budget line.
- Rehost — lift and shift. Fastest path, lowest immediate savings, and entirely legitimate as a first wave.
- Replatform — managed database, managed runtime, no application rewrite. Usually the best return per unit of effort.
- Refactor — justified when the application is strategic and its architecture is the constraint on the business, not before.
- Repurchase — moving to SaaS. Cheapest technically, most expensive organizationally, because it is a process change.
- Retire — typically 10-20% of an estate. Finding these pays for the assessment.
- Retain — regulated, contractual, or hardware-bound workloads that stay put. Deciding this early prevents wasted design work.
3. Build the landing zone before the first workload
Identity, network topology, logging, tagging, guardrails, and cost allocation should exist as code before anything production-bearing arrives. Retrofitting governance onto a populated cloud account is one of the most expensive corrections in this discipline — every remediation touches a running system.
The cost of a landing zone built late is not the rebuild. It is every change-control conversation the rebuild requires.
4. Migrate in waves, and make wave one boring
Wave one should be low-risk, internally visible, and owned by a team that will give you honest feedback. Its purpose is to prove the runbook, not the strategy. Wave two is where you take on something with real business dependency, because by then the operational muscle exists.
Define rollback criteria per wave, in writing, before the wave starts. A rollback that is planned is a controlled event; a rollback that is improvised is an incident.
5. Attach FinOps on day one, not at the first invoice shock
Cloud spend is a function of engineering behaviour, and engineering behaviour follows visibility. Tagging standards, per-team budgets, and anomaly alerts cost days to implement and routinely save double-digit percentages of annual run rate. Commitment purchases — reserved capacity, savings plans — should wait until you have ninety days of steady-state usage data. Buying commitments during migration is buying against a workload shape that no longer exists by the time it settles.
What a realistic timeline looks like
For a mid-market estate of roughly 80-150 applications, assessment runs four to six weeks, landing zone three to five weeks, and migration waves eight to sixteen months depending on refactor volume. Anyone quoting materially less is either working with a smaller estate than they have been shown, or is deferring the governance work into your operations budget.
The decision that matters most
Not which cloud. It is whether the organization is migrating to reduce cost or to increase delivery speed. Those two goals produce different architectures, different wave orders, and different definitions of success — and a programme that has not chosen between them will under-deliver on both.
