Large cloud migrations rarely fail because a single server could not be moved. They fail because hundreds of moves were poorly sequenced: tightly coupled systems were split across waves, cutovers collided with month-end processing, teams were overloaded in some weeks and idle in others, and nobody had a reliable view of what had moved and what remained. The discipline that prevents these problems is wave planning.
This playbook explains how to plan and run migration waves, from the first dependency analysis to post-migration hypercare. It draws on published guidance from AWS and Microsoft and complements decisions about migration strategy, such as which of the 7 Rs to apply, by focusing on the execution question: in what order, in what groups and with what safeguards should workloads move?
What a Wave Plan Is and Why It Matters
AWS Prescriptive Guidance describes a wave plan simply as a migration schedule: waves create manageable groups, reduce risk and organize work. A good wave plan answers several questions at once. Which applications move together? When does each group move? Who is responsible? What has to be true before a cutover can proceed? How will the plan change when new information appears?
Wave planning matters even more in 2026 than it did a few years ago. AI-assisted discovery and migration tools can produce inventories and target designs much faster, which means the bottleneck shifts to sequencing, coordination and business readiness. A fast factory with a poor plan simply produces problems faster.
A migration factory is only as good as its wave plan. Speed in discovery and conversion means little if dependencies are split, cutovers collide with business events or rollback was never rehearsed.
Step 1: Build a Trustworthy Inventory
The wave plan rests on the inventory. AWS lists the inputs as a complete view of the application portfolio, associated infrastructure, dependency mapping and a migration strategy for each application, along with ownership and a governance framework. In practice, assemble:
- An application catalog with owners, business criticality, environments and current migration strategy.
- Infrastructure data for servers, databases, storage and network components, ideally from automated discovery tools.
- Dependency data from network flow analysis or discovery agents, enriched with owner interviews.
- Non-technical constraints: maintenance windows, release freezes, contract end dates, regulatory reporting periods and business peaks.
Keep a single source of truth for scope, whether a migration tool, a database or a carefully controlled spreadsheet. AWS emphasizes that scope will change during the program, especially when new dependencies or servers appear late, so the inventory must be easy to update and version.
Step 2: Map Dependencies and Form Dependency Groups
Dependencies determine which workloads must move together. Both AWS and Microsoft distinguish between types of dependency:
- Hard or direct dependencies require low latency or immediate communication; the systems must migrate together or they will suffer performance problems.
- Soft or indirect dependencies are location-independent or tolerate latency; the systems can move separately, possibly with temporary hybrid connectivity.
- Business dependencies, which Microsoft highlights, link workloads through organizational or reporting relationships and are often worth honoring even when technical dependencies are weak.
Raw dependency data often suggests that everything connects to everything, because shared services such as directory services, backup and monitoring touch every server. AWS recommends filtering out these shared services, classifying connections by frequency and data volume, validating with application owners whether connections are synchronous, what latency they need and what happens if they fail, and looking for single applications that bridge large clusters, which can help break the data into smaller groups.
The result is a set of dependency groups (Microsoft calls them groups or waves; others use the term move groups): sets of applications that must migrate as a single unit. Microsoft advises documenting each group with a name, component inventory, critical dependencies and constraints, including supporting infrastructure such as load balancers, DNS records and caching layers. When unsure, it recommends grouping conservatively and splitting later.
Step 3: Size and Shape the Waves
AWS recommends keeping waves within six to ten weeks and preferring smaller waves, because they limit the impact of delays and blockers. Work that needs much longer, such as a full rewrite, is usually better handled outside the wave structure. Maximum wave size depends on risk appetite, meaning how much parallel change the organization can tolerate, and resource availability. Waves of similar length and structure support a factory-like approach.
AWS also describes several ways to organize waves, usually used in combination:
- By migration strategy or technology stack, which allows dedicated teams and consistent durations but needs more cross-pattern dependency analysis.
- By business domain, which keeps shared data together but exposes a whole domain if the wave fails.
- By technical capability, which starts faster as capabilities come online but can leave complexity pockets for later waves.
- By environment, moving non-production first, which lowers production risk but must catch dependencies missing from non-production.
- By business priority, which serves business outcomes but involves many teams and is harder to coordinate.
Step 4: Prioritize and Sequence
Microsoft’s guidance suggests starting with simpler, lower-risk workloads such as internal tools, development environments and low-usage standalone applications, migrating non-production environments before production to test the process and train operations teams, and including one or two representative complex workloads early to surface problems. Critical systems should follow once the team has demonstrated success, unless a business deadline forces earlier action, in which case extra safeguards and longer testing are needed. Microsoft also suggests a simple prioritization matrix: high-value, low-effort workloads first; high-value, high-effort workloads planned carefully with adequate resources; low-value, low-effort workloads used to fill gaps; and low-value, high-effort workloads deferred or avoided.
To sequence, AWS recommends a practical approach:
- Set date constraints: program length, data center exit dates, contract end dates, refresh cycles and dates to avoid, such as holidays and month-end.
- Create empty waves as a high-level structure, then assign dependency groups to them.
- Overlap waves so that while one wave is in migration and testing, the next is in design and preparation.
- Iterate on resource and size reviews until all waves are defined.
Microsoft adds that only the next wave needs to be planned in detail, with later waves kept at a high level, and that teams should set checkpoints at 25, 50 and 75 percent completion and compare actual and planned durations after each wave.
Step 5: Run Each Wave Through Defined Phases
AWS describes each wave as moving through design, cutover planning, pre-migration, cutover, hypercare or post-migration, and wave closure. A practical version of those phases looks like this.
Design
Confirm the migration strategy and target design for each application in the wave, validate dependencies with owners, and agree on success criteria, including performance baselines that will be compared after cutover.
Cutover planning
Write a cutover runbook for each dependency group, listing every step with an owner, a time and a verification check. AWS guidance describes cutover as executing a plan with dates, times, tasks and owners agreed by the migration and application teams, and stresses automating as much of the plan as possible because manual steps under production pressure are prone to human error. Include communication steps and a clear go or no-go decision point.
Pre-migration
Build the target infrastructure, typically through infrastructure as code, set up data replication, and run at least one dry run. Dry runs reveal missing firewall rules, forgotten scheduled jobs and incorrect configuration far more reliably than reviews.
Cutover
Execute the runbook, switch traffic, for example by updating DNS records, and run user acceptance tests. For complex applications with several components, AWS notes that you may migrate the full stack, the data layer or independent components separately, each with its own cutover strategy.
Rollback
Both AWS and Microsoft emphasize documenting rollback procedures and success criteria for each cutover. Define in advance the conditions that trigger rollback, the point of no return, and who has the authority to decide. Rehearse rollback during dry runs, not for the first time during a failed cutover.
Hypercare and closure
After cutover, monitor the application closely and keep migration and application teams available for rapid fixes. The AWS wave guidance cites a post-migration support period of about three days as typical within a wave, though critical systems may warrant longer. Decommission the source environment only after business users complete regression testing, the application is healthy and performance metrics are acceptable. Close the wave with a review that captures lessons learned and feeds them into the next wave.
Where AI Tools Help and Where They Do Not
AI-assisted tools are increasingly used in migration programs, and wave planning is one area where they can help, provided their output is treated as a draft. Useful applications include:
- Clustering dependency data into candidate dependency groups and highlighting bridge applications that link large clusters.
- Drafting cutover runbooks from templates and inventory data, which engineers then review and complete.
- Summarizing owner interviews and flagging inconsistencies between interview answers and observed network flows.
- Generating scenario comparisons, for example the effect of moving a dependency group to a later wave on team utilization.
What AI tools cannot do is make the business trade-offs: whether to accept a longer outage window for a critical system, whether a reporting deadline outweighs a data center exit date, or whether an application owner’s concern about a dependency should override the data. Those decisions remain with the wave lead, application owners and business stakeholders, and they should be recorded alongside the plan.
Governance and Tracking
A large migration involves many teams, so governance needs to be clear and lightweight. Useful practices include:
- A weekly wave review covering status, risks, scope changes and readiness for upcoming cutovers.
- A change process for scope: identify the change, analyze its impact on the plan, communicate it and update the plan, as AWS recommends.
- A shared tracking tool; Microsoft suggests using work items such as epics, features and tasks in a backlog tool to track waves.
- Clear roles: a wave lead, application owners, migration engineers, a cutover manager and a business representative for each wave.
- Metrics such as applications migrated per wave, planned versus actual duration, cutover success rate, rollback count and post-migration incidents.
A Hypothetical Example
Consider a hypothetical manufacturer that needs to exit a data center within 18 months, with about 300 applications in scope. Discovery tools and owner interviews produce an inventory and dependency map in the first two months. After filtering shared services, the team identifies about 60 dependency groups.
The first wave includes internal tools and the development and test environments for several business applications, plus one representative multi-tier application with a database, chosen deliberately to test the process. The team sizes waves at eight weeks and overlaps them so that design for wave two begins halfway through wave one. Month-end and quarter-end dates, along with an annual production planning period, are marked as blackout windows.
Wave one reveals that several applications depend on a file share that was not visible in the discovery data, and that the rollback procedure for the database application takes longer than expected. Both lessons are fed into the runbook template. By wave four, the team is migrating production systems at a steady pace, and the ERP-related dependency group is scheduled for a dedicated wave with extended hypercare. The data center exit is achieved with a small buffer, and the final wave review documents the remaining retained workloads and the reasons for keeping them.
Pitfalls to Avoid
- Trusting discovery data blindly. Validate dependencies with owners, especially for batch jobs and infrequent integrations.
- Oversized waves. Large waves amplify delays; prefer smaller, consistent waves.
- Ignoring the business calendar. Cutovers during peak periods or reporting cycles create avoidable risk.
- Skipping dry runs and rollback rehearsals. The first real test should not be the production cutover.
- Decommissioning too early. Keep the source environment until regression testing and performance validation are complete.
- Not learning between waves. Each wave should improve the next through updated templates and estimates.
Conclusion
Wave planning turns a migration from a large, risky event into a sequence of manageable, repeatable steps. Build a trustworthy inventory, map and validate dependencies, form dependency groups, keep waves small and consistent, sequence around business constraints, and run each wave through defined phases with automated runbooks, rehearsed rollbacks and proper hypercare. Above all, treat every wave as a learning opportunity. The guidance from AWS and Microsoft is clear on the fundamentals; the organizations that succeed are those that apply them with discipline, wave after wave.
How Hanoi Technology Can Help
Hanoi Technology plans and runs migration waves, from discovery and dependency mapping to cutover runbooks and hypercare, through projects, dedicated teams or managed services.