Why this matters
Cloud migration waves are batches of workloads that move through the same cutover window and the same checks. How to plan cloud migration waves is mostly a scheduling and dependency problem, not a cloud feature problem. A good wave plan tells you what moves next, what must move with it, who signs off, and what happens if the cutover fails.
Most migration surprises come from shared pieces. An app depends on a database, a file share, a DNS record, a certificate, an identity group, a batch job, or a monitoring agent that another team owns. If you move the app without the shared piece, the cutover looks fine until a real user hits a path you did not test. Wave planning makes those shared pieces visible before the window opens.
The business calendar matters as much as the technical graph. Finance close, payroll runs, audit periods, seasonal peaks, and month end reporting all create bad cutover dates. Waves give you a repeatable way to reserve good dates, keep support staff ready, and hold one rollback decision instead of many ad hoc ones. The plan should be boring enough that people trust it.
Before you start
Start with a workload inventory that includes the owner, business function, criticality, data class, integrations, runtime, license, support contract, and recovery target. A server list is not enough. Two apps on the same host may have different owners, data rules, and cutover needs. The inventory is the source for wave scope and for the first version of the dependency map.
Map dependencies in both directions. For each workload, record what it calls and what calls it. Include databases, file shares, message queues, scheduled jobs, identity groups, DNS names, network routes, certificates, monitoring, backup agents, and admin access paths. Give every dependency an owner and a status: confirmed, assumed, or unknown. Unknown is a valid status and a reason to keep the workload out of an early wave.
Set the rules before the first wave. Agree on the maximum wave size, the change freeze window, the approval path, the rollback authority, and the communication channel. Confirm the landing zone is ready: accounts, network, identity, logging, backup, and cost tags. Check vendor lead times and license terms for anything that needs a new contract. These are not details you want to discover during a cutover call.
How to do it
Build the dependency graph first, then group workloads into waves. Keep tightly coupled systems together unless you have a tested interface and a fallback. Move shared foundations into a wave zero when possible: identity, network, logging, DNS, backup, and the landing zone controls that every later wave will use. A shared service that is not ready will block every wave behind it.
Define a gate for each wave. A gate is a short list of evidence items: test results, owner sign off, rollback check, access review, and support handoff. The gate is not a status meeting. If an item is missing, the wave waits or shrinks. Shrinking is better than rushing. Keep the next wave in planning while the current one runs, so a late dependency does not force a bad decision.
Use a pilot wave to test the gate itself. Pick workloads with a real dependency but low business risk. Run the cutover, the checks, and the rollback drill. Then adjust the wave size and the gate. Schedule later waves around the business calendar and keep a two-wave lookahead. Re-plan after each wave instead of defending the original schedule.
- Inventory workloads and owners. List every workload with its owner, business function, criticality, data class, and recovery target. Do not stop at servers: include jobs, file shares, and integrations that users depend on. Confirm each owner can approve a cutover date.
- Draw the dependency graph. Record what each workload calls and what calls it, including identity, DNS, network, storage, and monitoring. Mark each link as confirmed, assumed, or unknown. Put a name next to every shared dependency.
- Prepare wave zero. Move or validate the shared foundations that later waves need: accounts, network, identity, logging, backup, and DNS. Test them with one low risk workload. Do not start application waves until these pass.
- Group by dependency and change risk. Place tightly coupled workloads in the same wave unless you have a tested interface. Keep high change risk items out of the first wave. Balance each wave so support and testing can cover it.
- Write exit criteria. Define measurable checks for technical health, business function, security, and rollback. Assign one owner for each check. Publish the criteria before the cutover window opens.
- Schedule cutover windows. Check the business calendar for finance close, payroll, audits, and peak periods. Reserve support staff and a rollback window. Avoid stacking two waves in the same week unless the teams are separate.
- Run a pilot wave. Pick low risk workloads that still exercise real dependencies. Run the full gate, including a rollback drill. Use the result to adjust wave size and the gate itself.
- Keep a two-wave lookahead. Plan the next two waves in detail and the rest at a high level. Update the plan after every gate review. Move a dependency, not the gate, when something slips.
How to check it worked
Check each exit criterion with evidence. Application health checks, synthetic transactions, error rates, latency, queue depth, backup restore tests, DNS resolution, certificate expiry, and access reviews all give you facts. Compare them with the baseline you captured before the wave. A green dashboard is not enough if the business transaction behind it is not tested.
Check the business result too. Review support ticket themes, user reports, batch completion, reconciliation output, and owner sign off. Talk to the people who use the system, not only the people who run it. If a workaround is still in place after the wave, the wave is not finished.
Review the plan itself. Did a dependency show up late? Did the gate take longer than expected? Did rollback work without a hero? Update the dependency map and the gate. A wave that passed but revealed a missing owner is a warning for the next wave. Adjust the next wave instead of compressing it.
Mistakes to avoid
The most common mistake is a wave that is too big. Large waves hide failures, stretch the cutover window, and make rollback a debate. Keep a wave small enough to test end to end and small enough for one support team to cover. Add size only after the gate has passed more than once.
Another mistake is grouping by department, server name, or convenience. Dependencies do not follow the org chart. A finance app may depend on an identity group owned by IT and a file share owned by operations. Group by dependency and change risk, then check the business calendar.
Skipping rollback is a common failure. A rollback plan needs a named owner, a tested path, and a time limit. Without it, the team improvises under pressure. The same applies to ownership after cutover: if no one owns the workload in the new environment, the wave is not done.
Treating the wave plan as a contract causes trouble. It is a forecast. Update it when a vendor slips, a dependency appears, or a business freeze changes. If you want help building the dependency map and wave sequence, the Cloudverg Discovery and roadmap sprint is a two-week fixed-price option that ends with an architecture, a phased roadmap, and a fixed-price quote for phase one.
Frequently asked questions
How many workloads should go in one migration wave?
Keep the first waves small enough to test end to end and roll back inside one cutover window. A wave should match the support and testing capacity you actually have, not the number you hope to move. Increase the size only after the gate passes cleanly more than once.
What should a wave exit criterion include?
It should include a technical check, a business check, a security check, and a rollback check. Each check needs an owner and evidence, such as a test result, a restore log, or a sign off. If any check is missing, the wave is not done.
Should shared services move before application workloads?
Usually yes for identity, network, logging, DNS, and backup, because every later wave depends on them. Put them in a wave zero and test them with one low risk workload. Some shared services need their own owners and change windows, so confirm that before you schedule.