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. Usually the execution is fine. The plan failed, and the fix is to rebuild the plan.
Anatomy of the stall
Four defects show up in almost every 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. Map dependencies from traffic, not interviews. Interviews capture what people believe. Traffic shows what is true. The Discovery Agent records actual network connections — which servers talk, on which ports, how often. For workloads already in AWS, VPC Flow Logs give you the same picture. Interviews still matter for the why behind each connection, but the graph itself should come from observed traffic. 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 talk constantly move together, in the same wave, with their data stores. Applications that talk rarely can split across waves — with an explicit plan for the seam, meaning a latency budget you have actually checked or a queue between them. Chatty pairs split across a hybrid link are the most 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 continuously from the source and lets you launch test instances before cutover, so the source machine stays intact. Route 53 with a TTL lowered days in advance makes the traffic switch reversible in minutes. 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 keep the other side in sync with AWS DMS change data capture until you commit.
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.
Your team keeps execution
This rebuild works best as advisory work, and it should stay advisory. The engineers who will run the cutovers need the plan in their hands and its logic in their heads — an outside team that executes for you leaves the day the contract ends, and takes the muscle memory with it.
The deliverable is the plan itself: a reconciled inventory, a traffic-derived dependency map, waves re-cut by coupling, rollback criteria per wave, and dates you can defend to leadership. Read-only access covers all of it — discovery data, flow logs, existing runbooks. Nobody needs write access to your accounts to tell you the truth about your plan.
If your wave plan has stalled and needs a rebuild before anything else moves, that is exactly what our AWS migration advisory covers.