Cloud Migration Strategy
Search for this question and most answers name one approach and defend it. None of them have seen your estate. This guide gives you the decision method instead: how to classify workloads, sequence waves, and keep each stage reversible until it has earned the right not to be.
A strategy is five paths applied selectively.
Vendors sell one path because it suits their delivery model, not because it suits every workload in your estate. A real strategy names all five and states plainly which workloads earn which path and why.
Path oneRehost, unchanged
Moves the workload as it stands onto new infrastructure. Cheapest and fastest, and the right call when a deadline matters more than cloud-native benefit yet.
Path twoReplatform, lightly adjusted
Keeps the architecture but swaps underlying services for managed equivalents. Earns real operational benefit without the cost of a rebuild.
Path threeRefactor, rebuilt
Changes the architecture itself. Justified only when the current design is the actual constraint on cost, scale or reliability.
Path fourRetire or retain
Some workloads are cheaper to switch off than to move, and others should stay exactly where they are for now.
Classification decides the path, not preference.
A workload assessment is not a checklist exercise done once and filed away. It is the evidence every later argument about strategy has to answer to, workload by workload. Skipping it in favour of a quick guess is how an estate ends up with the wrong path applied at scale.
Signal oneWhat it actually depends on
Map the calls a workload makes and receives before assuming it stands alone. Hidden dependencies are the most common source of a stalled wave.
Signal twoHow much downtime it can absorb
A workload with near-zero tolerance needs a different path and a slower cutover than one that can pause for an evening.
Signal threeWhat compliance duties travel with its data
Regulated data adds validation steps regardless of which path gets chosen, and can rule certain destinations out entirely.
Signal fourHow much technical debt it carries
A workload already straining against its own architecture rarely benefits from a straight rehost that just relocates the strain.
The estate moves in waves, ordered by what depends on what.
A migration planned as one cutover date is a migration planned to fail loudly. Waves let each move teach the next one something before the stakes rise. The order matters as much as the destination, because a badly sequenced wave surfaces every hidden dependency at once.
01Wave rule oneMove dependencies before dependents
A workload should never wait on something a later wave has not moved yet, or the sequence quietly breaks itself.
02Wave rule twoStart with a low-stakes pilot
The first wave should be small enough to fail safely and rich enough in edge cases to teach the team something real.
03Wave rule threeWeight later waves by risk, not size
A large but simple workload can move earlier than a small one carrying regulatory weight or fragile dependencies.
04Wave rule fourFeed each wave's lessons into the next plan
A wave plan fixed at the start and never revisited ignores everything the estate just taught the team about itself.
Reversible narrows as the migration proceeds.
Teams say a plan is reversible without asking at which stage that stops being true. The honest answer changes as data starts moving and old systems get retired.
During assessment, fully reversible
Nothing has moved yet. A classification can be revised freely once new information about a workload surfaces.
During a pilot wave, reversible within a window
A small wave can roll back cleanly for a defined period before its data diverges too far from the source system.
During full cutover, reversible only if rehearsed
A rollback path that was never tested against real data is not a rollback path, it is an assumption under pressure.
After decommission, effectively permanent
Once the source system is switched off and its capacity reclaimed, reversing the decision means rebuilding it from nothing.
A cutover is only as good as its rehearsal.
The difference between a calm cutover and a chaotic one is almost never the technology. It is whether the rollback was ever actually tried before it was needed. A plan that only exists on a slide is not yet a plan that has earned anyone's trust.
01Step oneFreeze the scope before the date
Nothing new enters a wave once its cutover is scheduled. A late addition is next wave's problem, not this one's risk.
02Step twoRun a dry cutover against real data
A rehearsal against sample data proves the mechanics work. A rehearsal against a real copy proves they survive contact.
03Step threeSet go and no-go criteria in advance
Deciding what counts as failure during the cutover itself, under pressure, is how teams push through a wave that should have stopped.
04Step fourKeep the old system live until it earns retirement
A short overlap window costs little and gives the new environment time to prove itself under real traffic first.
The business case has to survive the first wave.
A migration business case built entirely from assumptions will be wrong somewhere. The question is whether it can absorb that and still hold, or whether it collapses at the first surprise.
Hidden dependencies inflate the timeline
A workload assessed as standalone rarely stays that way once the first wave starts mapping its real connections.
Licensing terms rarely transfer cleanly
Software licensed for on-premises use often needs renegotiation before it can run legally in a new environment.
Data transfer has its own cost curve
Moving large volumes of data is neither instant nor free, and that cost belongs in the case from the start.
The team's skills gap shows up mid-move
An estate can be ready to migrate before the people running it are ready to operate the destination confidently.
Five questions that expose a fragile plan.
A migration plan that cannot answer these plainly is a plan still being written. Asking them early is far cheaper than discovering the gaps mid-wave.
01Who owns the go or no-go call for each wave?
If the answer is vague, the decision will default to whoever is in the room when pressure is highest.
02What happens if a wave uncovers a hidden dependency?
A plan without a pause option treats every discovery as a delay to push through rather than information to use.
03How is a workload's downtime tolerance actually measured?
An assumed tolerance and a measured one often disagree, usually in the direction that makes the cutover riskier.
04Which workloads are explicitly out of scope for now?
A plan that claims to move everything usually means nobody has decided which workloads should wait.
05What triggers a rollback once it is triggered?
Vague thresholds get argued away in the moment. Written triggers get followed, because nobody has to decide alone.
Each decision in the plan needs a named owner.
A wave plan with no owner attached to its decisions eventually gets decided by whoever is loudest in the room during a live incident, which is rarely the right person for it.
The workload owner confirms real behaviour
Whoever runs the workload day to day is the fastest route to catching an assumption in the assessment before it becomes a wave-time surprise.
The migration lead owns the sequence
One person should be able to explain why a given workload sits in this wave and not an earlier or later one.
A compliance reviewer signs off regulated data
Data carrying regulatory weight should never move on a technical sign-off alone, regardless of how confident the migration team feels.
An executive sponsor owns the go or no-go call
Pausing a wave costs schedule. Someone senior enough to accept that cost needs to be the one making the pause decision, not the engineer under pressure.
Turn the method into a plan for your estate.
This guide gives you the reasoning behind a sound migration strategy. Turning that into a scheduled wave plan for a real estate is a scoped piece of work in its own right.
See the migration practice itself
The assessment, wave planning, cutover and rollback work described here is carried out as a dedicated practice.
Scope your own estate
A scoping conversation turns the classification method into an actual wave plan for your specific workloads.
Read the neighbouring guides
The same decision discipline applies to running an estate afterward and to the pipeline that ships into it.
Asked before a wave plan is approved.
01How many workloads should a pilot wave include?
Few enough to fail safely if something goes wrong, and varied enough to surface real edge cases. A pilot chosen purely for simplicity teaches the team very little about the harder workloads still ahead.
02Is rehosting always the fastest option available?
Usually, but not always. A workload with unresolved licensing or compliance questions can stall a rehost just as easily as a refactor. Speed depends on what is actually blocking the move, not the path chosen.
03What if a workload cannot be confidently classified?
Treat the uncertainty as information rather than forcing a decision. A short, focused assessment of that one workload usually costs far less than guessing wrong and unwinding the move later.
04How is replatforming different from refactoring in practice?
Replatforming swaps components for managed equivalents without touching the overall architecture. Refactoring changes the architecture itself. The first is an adjustment; the second is a redesign with a matching budget and timeline.
05Should regulated data move in an early wave or a late one?
Neither by default. Regulated workloads should move once their validation steps are proven on a simpler wave first, so the compliance work is not also carrying the migration's learning curve.
06Can two migration paths run inside the same wave?
Yes, and this is common. A wave is a sequencing unit, not a single technique. It can carry a rehosted workload alongside a replatformed one if their dependencies allow it.
07What happens if the first wave changes the budget significantly?
That is the wave doing its job. A business case built to survive contact with reality gets revised, not defended past the point the evidence stopped supporting it.
08Does a migration strategy ever include doing nothing?
Yes, deliberately. Retaining a workload where it already sits is a legitimate outcome of the same assessment, not a failure to reach a migration decision. Revisiting that call later, once circumstances change, is part of the same discipline rather than a reversal of it.