The short answer
Migration waves should be grouped by dependency first and risk second: systems that talk to each other frequently move together, and the first wave should be low-risk enough to prove the runbooks and the rollback. Each wave ends with a validation gate — application health, integrations, batch jobs and cost — before the next begins.
Key takeaways
- Chatty systems move in the same wave or the latency will find you
- Wave one exists to prove the rollback, not to deliver value
- Six to twelve workloads per wave keeps validation meaningful
- A validation gate that never blocks a wave is not a gate
Part of our guide to AWS migration: a practical guide to getting it right.
A wave plan is the difference between a migration that finishes and one that becomes permanent. The technical work is largely repetitive; the sequencing is where judgement is required.
Group by dependency first
The primary rule: systems that communicate frequently and synchronously move together. Split a chatty pair across the on-premise boundary and you have introduced network latency into a code path that never expected it. The migration will be technically complete and the application will feel broken.
Your dependency map from discovery drives this. Cluster tightly-coupled systems, then treat each cluster as a candidate wave. Where a cluster is too large to migrate at once, look for the seam with the least chatty interface and accept temporary hybrid latency there deliberately, having measured it.
Then order by risk
Within the constraints dependency imposes, sequence from low risk to high.
Wave one exists to prove the process. Pick something real but forgiving — an internal tool with a tolerant user base, ideally with a clear owner who will actually test it. The goal is not value delivered; it is a proven runbook, a proven cutover, and above all a proven rollback. If you cannot roll wave one back cleanly, do not start wave two.
Middle waves carry the volume. By now the runbooks are stable and the team is fast. This is where most workloads move.
The hardest systems go last — the ones with the most integrations, the strictest availability requirements, or the least institutional knowledge. By the time you reach them the team has done this many times.
One caveat: do not leave a workload until last purely because nobody understands it. Investigate those early even if you migrate them late, because the unknown is what wrecks timelines.
Size waves so validation stays meaningful
Six to twelve workloads per wave suits most organisations. Small enough that validation is genuinely performed rather than assumed, large enough that the programme progresses.
The constraint is rarely technical capacity. It is how many systems your business users can meaningfully test in the window available. A wave of forty workloads gets rubber-stamped, and defects surface weeks later when nobody can tell which change caused them.
Gate between waves
Each wave ends with an explicit gate covering:
- Application health and error rates against the pre-migration baseline
- Every integration point exercised, including the ones that only run on a schedule
- Batch and scheduled jobs completed successfully at least once
- Backups taken and a restore actually tested
- Monitoring and alerting confirmed working in the new environment
- Cost against the estimate for that wave
The cost check belongs there because it is the earliest point you can catch a systematic estimating error. Finding out at wave one that instances are twice the size they need to be is a cheap lesson; finding out at wave eight is not.
A gate that has never blocked a wave is not functioning as a gate.
Leave room in the plan
Something will need re-migrating. A dependency will surface that discovery missed. A business event will freeze changes for two weeks. Plans with no slack do not survive contact, and the pressure to skip validation is what turns a delayed migration into a failed one.
