Migration Wave Plan

Which applications move in which batch, in what order, and what the dependency between batches actually is.

Type Planning Artifact Stage Design Topic Cloud Migration Area Cloud Architecture

flowchart LR
  subgraph w0["Wave 0 — Foundation"]
    direction TB
    f1["Landing zone"]
    f2["Connectivity + DNS"]
    f3["Identity federation"]
    f4["Observability + backup"]
  end

  subgraph w1["Wave 1 — Prove it (6 apps)"]
    direction TB
    a1["Internal wiki<br/><i>rehost</i>"]
    a2["Reporting portal<br/><i>rehost</i>"]
    a3["Batch scheduler<br/><i>replatform</i>"]
  end

  subgraph w2["Wave 2 — Bulk (34 apps)"]
    direction TB
    b1["Departmental apps<br/><i>rehost ×26</i>"]
    b2["Shared services<br/><i>replatform ×8</i>"]
  end

  subgraph w3["Wave 3 — Hard cases (9 apps)"]
    direction TB
    c1["Order management<br/><i>refactor</i>"]
    c2["Data warehouse<br/><i>replatform</i>"]
    c3["Partner gateway<br/><i>refactor</i>"]
  end

  subgraph w4["Wave 4 — Exit"]
    direction TB
    d1["Mainframe interfaces<br/><i>replace</i>"]
    d2["Data centre exit<br/><i>contract ends Q3</i>"]
  end

  w0 -->|"platform accepted<br/>by security + ops"| w1
  w1 -->|"runbook proven<br/>rollback rehearsed"| w2
  w2 -->|"shared services live<br/>latency measured"| w3
  w3 -->|"last dependency<br/>severed"| w4

What it is

The sequencing of a migration: which applications move together, in what order, and — the part that carries the information — what condition must be true before the next wave may begin. The labels on the arrows between waves are exit criteria, not decoration.

Wave 0 is always platform, never applications. Wave 1 is always small, low-risk and chosen to prove the runbook rather than to deliver value.

When you produce it

After discovery and dependency mapping, before any business commitment to a date. It is the artifact that turns "we will be out of the data centre by March" into something with a critical path.

Who reads it

The steering committee, who fund it and track it. Application owners, who need to know which wave they are in and when. Operations, who staff each cutover. The data centre exit and contract-end dates on the right-hand side are usually what makes it urgent.

What good looks like

Exit criteria between waves, expressed as conditions rather than dates.
Migration strategy noted per application — rehost, replatform, refactor, replace, retire, retain.
The hardest applications are not last by default; they are where the dependency order puts them, and if that is last, the risk is stated.
Retire and retain are on the plan. Roughly a fifth of most portfolios should not move at all.
The contract or lease end date is visible, because that is the real constraint.

Common mistakes

Starting with the most valuable application, so the first cutover is also the first rehearsal.
Waves sized by calendar rather than by dependency, which guarantees a wave that cannot complete.
No exit criteria, so wave two begins while wave one is still failing.
Ignoring the data gravity, and moving an application away from the database it makes ten thousand calls a minute to.