Cloud migration: why waves beat the big bang

Single-cutover migration is appealing because it is simple to present: one date, a mobilised team, a before and an after. It fails for the same reason: it assumes everything not anticipated will be discovered and fixed inside the window.

What waves bring

Migrating in waves means splitting the estate into coherent batches and cutting over one batch at a time, each with its parallel run and its rollback point.

The first batch is the learning one. It reveals the surprises — undocumented dependencies, unexpected latencies, missing permissions — on a scope where impact is limited. Those surprises exist in every migration; the only question is which batch they land on.

Each wave is reversible. Rolling back one batch is a few hours' work. Rolling back a full migration is a project in itself, and almost never genuinely possible.

The team ramps up progressively. Runbooks sharpen, automation accumulates, wave five costs less than wave one.

How to split

Splitting by technical layer — all databases first, then all application servers — is the most tempting and the most dangerous: it creates a period where the application is spread across two environments, with network latencies nobody modelled.

Split by functional domain: one complete domain moves with its database, its servers and its flows. Cross-domain dependencies are handled with temporary interfaces, whose cost must be budgeted explicitly.

Recommended order: start with a low-criticality but realistic domain — neither the sandbox nor the core business. The sandbox reveals no surprises; the core business does not forgive the first one.

What to write before starting

The point of no return for each wave. The precise moment when rollback becomes impossible or too costly. That information must be known to everyone taking part in the cutover.

The success criterion for each wave. Measurable, verified before launching the next. "It seems to work" is not a criterion.

The rollback plan, tested. A rollback plan written and never executed is a reassuring fiction. Test it on the first wave, in real conditions.

The cost of dual running

During migration you pay for both environments. That is the main argument raised against the wave approach, and it is real: an eighteen-month migration means eighteen months of partial double billing.

Two answers. First, that cost is predictable and budgetable, unlike the cost of a failed cutover. Second, it shrinks with each wave, since the old environment can be decommissioned batch by batch — provided decommissioning is written into each wave's scope, with a payment milestone attached.

The only case that justifies a big bang

A contractual data centre deadline with no possibility of extension. In that case the block migration is imposed rather than chosen, and it must be prepared with a full rehearsal in an isolated environment — which costs more than the waves you were trying to avoid.