Wave planning goes wrong when waves are grouped by team or by datacentre rack rather than by dependency. Applications that talk to each other must move together or tolerate the latency of being split, and that decision belongs in the plan.
Group by dependency cluster. Applications that exchange significant traffic should move in the same wave. Splitting a chatty pair across the migration boundary means every transaction crosses the internet, and the performance complaint arrives immediately.
Start with a low-stakes but real application. Wave 1 should be genuinely production (a pilot on something nobody uses teaches you nothing), but chosen so failure is survivable.
Define validation before the cutover, not after. Write down what 'working' means per application: which transactions must complete, what performance is acceptable, which integrations must be verified. Otherwise the go/no-go becomes a feeling.
Here's a preview. Unlock the free download to get all 3 sections (2 more below).
| Wave | Applications | Why grouped | Target window | Owner | Rollback decision point | Status |
|---|---|---|---|---|---|---|
| 1 | Internal wiki, dev tooling | Low criticality, few dependencies | 2026-11-08 | Platform | 4h after cutover | Planned |
| 2 | CRM, marketing automation | Tight integration pair | 2026-12-06 | Platform | 2h after cutover | Planned |
More free templates IT teams use alongside this one.
Migrations overrun because the assessment covered infrastructure and skipped the two things that actually cause delay: undocumented application dependencies and a team that has never operated the target platform.
Dependency maps built from interviews are wrong, because teams know what their application calls and rarely know what calls it. This one is built from observed traffic, with the interview used only to explain what you found.
Change control earns its reputation for bureaucracy when every change gets the same paperwork. This form routes by risk: standard changes are pre-approved and need almost nothing, while the genuinely risky ones get the scrutiny that would otherwise be spread thinly across everything.
By dependency cluster first, then by risk. Applications exchanging significant traffic belong in the same wave; splitting them means every transaction crosses the migration boundary. Start with something genuinely in production but survivable if it fails.
Long enough to cover a full business cycle including month-end, typically two to four weeks. Keeping the source intact makes rollback a decision rather than a restore, which is what allows aggressive cutover scheduling.
The interval when some systems have migrated and others have not. Latency between them, duplicated identity, and split monitoring all cause problems during it, and it usually lasts longer than planned, so it needs designing rather than enduring.
