Migration Waves: Sequencing Work You Cannot Do at Once
Migration waves group systems into ordered batches by dependency and risk, turning an impossible big-bang move into a series of reversible steps.
Definition
A migration wave is a planned batch of workloads moved together within a defined window, ordered so that shared dependencies, data, and identity are available before the applications that need them.
Context and scope
Large estates cannot move in one release; waves make progress measurable while keeping each step small enough to roll back.
Common misconceptions
- Waves are arbitrary batches — they follow dependency order and risk tolerance
- Faster waves are better — overly large waves recreate big-bang risk
- A wave ends at cutover — stabilization and decommissioning belong to the wave too
Anti-patterns
- Grouping by org chart instead of dependency and data gravity
- Starting a wave before its shared services are stable
- Running waves without a rollback criterion
Related concepts
Authoritative source
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/
Sequencing under constraints
A large migration cannot happen all at once, but it also cannot happen in random order. Waves impose sequence: some workloads must move first because others depend on them, some must move last because their risk is highest, and some cannot move until a prerequisite is in place. The wave plan is the answer to “what must be true before this can move?”
How waves are formed
Group workloads by dependency and coupling, not by department. Shared identity, networking, and data platforms usually form an early foundation wave. Applications with few dependencies and low criticality follow, providing practice and proof. High-risk systems and their tightly coupled databases come later, once the tooling and runbooks have been tested.
Wave zero
Every plan needs a wave zero: the shared services, landing zone, and observability that later waves assume. Skipping it produces a wave one that stalls halfway through because logging, DNS, or access control is missing. Treat wave zero as a product with its own acceptance criteria.
Running and exiting a wave
Define entrance criteria, a rollback trigger, and exit criteria before the wave starts. Entrance criteria might require a tested runbook and a named owner per application. Exit criteria include stabilization time, decommissioning of the old resources, and updated documentation. For example, a wave that cuts over successfully but never decommissions the source leaves permanent double cost and a second system to patch.
Compared to a big-bang migration
Big-bang migrations finish quickly in theory and fail expensively in practice, because one bad dependency invalidates the whole cutover. Waves accept slower total duration in exchange for reversible steps, measurable progress, and the ability to change the plan after each wave. The trade is coordination overhead, which is why wave size should stay small.