A migration strategy is a document that lets other people make consistent decisions without asking. If it does not do that, it is a statement of intent, and statements of intent do not survive the first system whose disposition is genuinely arguable.
This page sets out what such a document contains. The execution work, including assessment, waves, cutover and rollback, is in Cloud Migration and Modernization.
Begin with why, in terms that can be tested
Migrations are commissioned for different reasons and the reason determines every subsequent choice. Exiting a data center by a fixed date, reducing run cost, improving resilience, enabling a product change, meeting a compliance obligation: each implies a different sequence and a different tolerance for change.
Vague objectives produce inconsistent decisions. "Modernize our infrastructure" gives no way to choose between two defensible options; "leave the facility before the lease ends in eighteen months" chooses for you, repeatedly, and mostly in favour of speed over elegance.
State what will not be done
The most useful section of most strategy documents is the one listing what is out of scope. Systems that stay put, changes that are deliberately deferred, and improvements that are explicitly not part of this program.
Without it, scope arrives by accretion: an application is rewritten because somebody noticed it could be, a database is upgraded because it was being touched anyway, and a migration with a date becomes a modernization program without one.
Principles, and what they are for
Principles are the mechanism for making decisions consistently when the strategy's author is not in the room. They should be specific enough to settle an argument: whether managed services are preferred to self-managed equivalents, whether an application is changed during a move or afterwards, whether identical environments matter more than optimal ones, whether cost or speed wins when they conflict.
A principle nobody could disagree with is not a principle. If every reasonable person would already have done what it says, it is decoration.
A disposition for every system
The core of the deliverable is a list of every system with a decision attached. The common vocabulary comes from provider guidance, which names strategies including rehost, replatform and refactor along with retire, retain, relocate and repurchase. See AWS Prescriptive Guidance, Migration strategies.
The two dispositions that repay the most effort are retire and retain. Every system retired is work avoided entirely, and estates reliably contain systems nobody uses that nobody has been asked about. Every system honestly marked retain removes a false obligation from the plan.
Be honest about retain
Some systems will not move within the program: an application tied to hardware, a vendor product with no supported cloud deployment, a system awaiting a replacement already in procurement.
Marking them retain is a decision. Leaving them unassigned in the hope that something turns up is how a program reaches its final month with a small number of systems that were always going to be the hardest and now have no time. The strategy should say what happens to them, including the possibility that a facility presence continues for them alone.
Sequence is where strategy becomes plan
Dependencies constrain the order more than preferences do. Shared services generally move first or last, and moving them in the middle means everything is split across the boundary at the worst moment. Systems that share data want to move together. Systems with a hard external date move when that date requires.
Beyond the constraints, the sequencing choice is deliberate: start with something low-risk to establish the process, or start with something significant to prove the approach. Both are defensible and the choice should be stated, because teams behave differently depending on which is in force.
The target state has to be described
A strategy that says where systems are going without saying what they arrive into leaves every team to invent an answer. The target needs account and subscription structure, network design and address allocation, identity model, security baseline, logging and monitoring standards, tagging, and the provisioning mechanism.
These are the things that are cheap to decide early and extremely expensive to change once several hundred resources exist. Microsoft's Cloud Adoption Framework structures its guidance around exactly this sequencing, treating the landing zone as work that precedes migration rather than accompanying it. See Microsoft, Cloud Adoption Framework for Azure.
The cost model, including the overlap
Two costs are routinely absent from migration business cases and both are large. The first is the period during which both environments run: the old estate cannot be switched off until the last system leaves, so the overlap is paid at full price on both sides, often for a year or more.
The second is the cost of the migration itself, which is people rather than infrastructure. A business case comparing steady-state before against steady-state after, with nothing in between, is describing an outcome rather than a project. Cloud Cost Optimization and FinOps covers what the steady state then needs.
Where each workload goes, and on what grounds
A strategy should state the placement rule, not just the destination. Which constraints eliminate options outright, which workloads stay private and why, and what happens to systems whose constraints are unclear.
Data location, latency to a fixed dependency, licensing bound to physical cores, and regulatory obligations are the constraints that usually decide. The comparison itself is in Private Cloud, Public Cloud and Hybrid Cloud; the strategy's job is to say which of those factors apply to this organization and how they rank.
Plan for the hybrid period, because it is most of the program
For nearly all of a migration, the estate is split. Applications call across the boundary, identity spans both, monitoring covers each partially, and the link between them becomes critical infrastructure with no owner.
Treating that period as a transient state to be endured is how it becomes the longest and least managed phase. It deserves its own design, described in Hybrid Cloud Architecture Explained, and an owner.
Governance: who decides what, and how fast
Migrations generate a continuous stream of decisions, most of them small and some of them irreversible. The strategy should say which decisions a team makes alone, which need review, and who resolves a disagreement.
The failure mode when this is missing is not chaos but delay. Teams wait, escalate, or make a decision and later have it reversed. A named decision owner with a stated turnaround is worth more to a program's pace than almost any technical choice in the document.
Skills, and the honest version
Migration needs capabilities the existing team may not have and, more importantly, needs them while that team continues to run the current estate. Both halves are frequently underestimated.
The strategy should say who does the work, what is brought in, what is transferred, and what the team looks like afterwards. Plans that assume the existing team absorbs the migration alongside their current duties are the ones that slip quietly and continuously.
Risks with owners, not a list
A risk register that nobody revisits is paperwork. The version that helps names the few risks that could actually stop the program, with a named owner and a stated trigger for acting.
The recurring ones are worth writing down explicitly: a system whose owner cannot be found, a dependency discovered late, a vendor whose licensing forbids the target, and a cutover window that cannot be obtained because the business will not accept the outage.
How progress is measured
Counting migrated systems overstates progress, because the easy ones move first. Weighting by complexity or by the cost that can actually be switched off gives a truer picture, and the second one is what finance is really asking about.
The most informative metric is usually decommissioning: how much of the old estate has been turned off, not how much of the new one has been turned on. A program that has migrated most of its systems and decommissioned nothing has not yet delivered anything.
A strategy that is expected to change
Discovery continues throughout. Dispositions change, dependencies appear, and a system assessed as straightforward turns out not to be. A strategy treated as fixed becomes wrong and then ignored.
LABUSA approaches this boundary-first: establish what is in scope, what is not, and who holds each responsibility before the work starts, then revisit the dispositions as the estate reveals itself. The capability this planning work belongs to covers migration, operations and recovery together.