Wave 1 landed — it was the easy stuff, mostly stateless and self-contained. Wave 2 slipped twice. Wave 3 no longer has a date, and the weekly migration call has quietly turned into a status call about why nothing moved.
That is a stalled migration. The instinct is to push harder on execution — more standups, more escalation. Before assuming execution is the root cause, test whether the plan still reflects the estate and its dependencies.
Anatomy of the stall
Four defects are worth testing in a stalled wave plan.
- The dependency map lives in someone's head. One engineer knows the order service calls pricing over a hardcoded IP and that a nightly batch job reads from a file share nobody documented. When that person is unavailable — or simply wrong — a cutover fails in a way nobody predicted, and confidence in the whole plan drops with it.
- Waves were sequenced by application list, not dependency graph. Someone sorted a spreadsheet by business unit or by easy/medium/hard and cut it into waves. That works until wave 3 needs a database wave 5 owns, and suddenly wave 3 is blocked or running chatty traffic across a hybrid link.
- No tested rollback. The runbook says "roll back if needed" — no criteria, no owner, no rehearsal. So when a cutover goes sideways at 2 a.m., the team debugs forward, because rolling back is scarier than pressing on. One bad night like that and every future window gets harder to book.
- Cutover windows nobody protected. The window was on a calendar, but the DBA got pulled into a production incident, the app owner never confirmed, and a change freeze ate the backup date. A window nobody with authority defends isn't a window. It's a wish.
The rebuild: five passes
1. Inventory truth pass. Reconcile the plan's application list against what is actually running. Pull it from tooling, not memory: AWS Application Discovery Service — the Discovery Agent on servers, or the Agentless Collector against vCenter — checked against your CMDB and your cloud bill. Expect drift: servers still in the plan that were decommissioned last year, applications that appeared after the plan was written, "temporary" boxes doing permanent jobs. Get the reconciled inventory into AWS Migration Hub so status lives in one place instead of five spreadsheets.
2. Test interview evidence against observed traffic. Interviews explain intent and history; observed traffic can reveal connections the interviews missed. The Discovery Agent can record network connections — which servers communicate, on which ports, and how often. For workloads already in AWS, existing VPC Flow Logs can add network-flow evidence, within the limits of the configured fields and aggregation interval. Interviews still matter for the why behind each connection; the dependency map should combine observed evidence with owner knowledge. The engineer whose head held the old map becomes a reviewer of the new one instead of a single point of failure.
3. Re-sequence by coupling. Cluster the dependency graph. Applications that communicate constantly are candidates to move together, in the same wave, with their data stores. Applications that communicate rarely may be candidates to split across waves — with an explicit plan for the seam, such as a latency budget you have tested or a queue between them. Chatty pairs split across a hybrid link are one common cause of "we migrated it and now it's slow." The output is waves cut along coupling boundaries, not org-chart boundaries.
4. Rollback criteria per wave. Written before the window opens, three parts each: the health checks that define success (specific CloudWatch alarms and synthetic checks, not "app looks fine"), a decision point ("not green by hour four of a six-hour window means roll back"), and one named person who makes the call. Then make rollback mechanically cheap. AWS Application Migration Service replicates source servers and supports test launches before cutover. For DNS-based switching, lowering Route 53 record TTLs sufficiently in advance can reduce cache delays, but it does not guarantee a reversible-in-minutes rollback; resolver behavior and application state still matter. The hard case is data: once a target database has taken writes, rollback becomes reconciliation. For stateful cutovers, decide before the window which database is authoritative during validation and evaluate whether AWS DMS change data capture fits the engine, topology, and rollback plan.
5. Honest dates. Dates come from rehearsals, not steering-committee quarters. Time a representative MGN test launch and a DMS full load, and let those numbers set the window length. Mark freeze periods — quarter-end close, seasonal peak, audit weeks — on the plan before someone schedules through one. And state confidence explicitly: a wave date with named risks is credible. A precise date with silent risks is how the last plan died.
Keep execution ownership explicit
A rebuilt plan should leave the people who will own cutovers able to explain its logic, rehearse critical paths, and operate the runbooks. The client team may execute, an external team may help, or the work may be shared. In each model, name the client owner, decision rights, responsibility seams, and handoff in the scope.
The deliverable is the plan itself: a reconciled inventory, an evidence-backed dependency map, waves re-cut by coupling, rollback criteria per wave, and dates you can defend to leadership. If discovery data, flow logs, and runbooks already exist, the analysis can use read-only access. Creating or changing telemetry requires client-side work or separately approved write access, and the SOW should say which applies.
If your wave plan has stalled and needs a rebuild before the next cutover, a scoped Consulting engagement can cover planning, rehearsal, or delivery support with explicit ownership and handoff.