Broadcom's licensing and partner-program changes have pushed a large number of enterprises into VMware migrations they didn't plan to run this year. Most of these estates are far too large to move in a single cutover. That makes wave planning, the practice of migrating workloads in sequenced, controlled batches, the most important discipline in modern VMware migration management.
It's also where migrations quietly go wrong. According to IDC, 31% of migrations miss their planned timeline, with legacy application complexity cited as the leading cause, and 18% have to roll back at least some workloads. Both failures trace back to the same root: workloads sequenced without a clear picture of how they depend on one another.
Our leadership recently wrote on LinkedIn about why VMware migrations go over budget, and the through-line is that overruns come from predictable problems that were never planned for. Consider this guide the breakdown: where those problems are caught or missed. It walks through the full wave-planning lifecycle for a vSphere migration, covering how to centralize your data, map dependencies, build and sequence waves, schedule them, and communicate throughout. Done well, wave planning turns a high-risk IT infrastructure migration into a controlled, predictable program.
What wave planning is, and why "big bang" fails
Wave planning groups your virtual machines into batches that move together in a deliberate order, rather than all at once. Each wave is scoped so that dependent systems move together, capacity isn't overwhelmed, and any problem stays contained to a small blast radius. It is the backbone of any large virtual machine migration.
The alternative is a single cutover that moves everything at once. That concentrates all the risk into one event, with no room to learn and no easy way to recover. At enterprise scale, big-bang migrations are how a weekend cutover turns into a week-long incident. Waves trade a little more elapsed time for dramatically less risk.
Step 1: Centralize your migration data
You cannot plan waves on data scattered across spreadsheets, vCenter exports, and a stale CMDB. The foundation of VMware migration management is a single, trusted source of truth. Pull the key sources together:
- Inventory: every VM, with its size, operating system, and configuration, from vCenter and discovery tools.
- The system of record: ownership, business service mapping, and change history from ServiceNow and its CMDB.
- Performance and utilization: so you can right-size targets and flag oversized workloads before they become problems.
- Storage and network context: the capacity and throughput that will govern how fast waves can safely move.
Then cleanse it. CMDB data drifts and duplicates over time, and planning on inaccurate data guarantees surprises later. Reconciling these sources into one view is the unglamorous work that makes everything downstream possible.
Step 2: Map your dependencies
Before you can group workloads, you have to understand how they connect. Data dependency mapping reveals which applications talk to which databases, which services are shared, and which network paths matter.
This is the step most teams underinvest in, and it is the one that decides the outcome. When a dependency is discovered during a cutover instead of during planning, you get the rework and rollbacks that show up in the statistics above. Map at four levels:
- Application to application: the integrations and API calls between systems.
- Application to data: database and storage dependencies.
- Shared services: authentication, DNS, logging, and other common infrastructure that many apps quietly rely on.
- Network: the live traffic flows that reveal relationships the CMDB never captured.
Agentless discovery and traffic analysis surface the dependencies documentation missed. The rule is simple: nothing that must move together should ever land in different waves.
Step 3: Build the waves
This is the core of migration wave planning. Group and sequence workloads using a few clear principles:
- Keep dependent workloads together. A cluster of systems that depend on each other moves as one unit, in one wave.
- Start low-risk. Sequence from least business-critical to most. Non-production and low-impact apps go first, mission-critical systems last, once the process is proven.
- Run a pilot wave first. A small, representative wave validates your tooling, runbooks, and timing before the stakes get high.
- Size waves to capacity. Model each wave against real network and target capacity so it finishes inside its window instead of spilling over.
- Contain the blast radius. Smaller, well-bounded waves mean a problem touches fewer systems and is faster to reverse.
- Define rollback criteria per wave. Decide in advance what "abort" looks like, so a bad cutover is a controlled decision rather than a scramble.
Structured preparation pays off measurably here. IDC finds that organizations running a formal readiness assessment before migrating have 2.4 times higher success rates.
Step 4: Schedule the waves
A wave plan is only as good as the calendar behind it. Tie each wave to real maintenance windows, change freezes, and business events, and sequence them to keep the overall program tight.
Scheduling is also a cost control. Every extra week of running old and new environments in parallel is a week of paying for both, and migrations that stretch beyond 12 months often see cost inflation of 30% or more. Tight sequencing keeps that window short. Manual scheduling in spreadsheets is where slippage starts, so automate it wherever you can.
Step 5: Communicate throughout
Most coordination failures are communication failures. A technically sound wave plan still fails if an application owner isn't told their system is moving, if leadership can't see status, or if an end user hits an outage nobody warned them about. Build communication into the plan:
- Notify owners and users before, during, and after each wave.
- Give leadership a single, current view of progress and risk.
- Keep one source of status so nobody is chasing updates across email and chat.
The payoff for disciplined, tooling-led execution is clear in the data: Forrester reports that 71% of partner-led migrations finish on time and on budget, versus 49% for self-managed efforts.
Why is it difficult to keep VMware migration scheduling and communications synchronized?
Because in most migrations they live in two different places. The schedule sits in a project plan or spreadsheet, while communications go out over email and chat. The two fall out of sync the moment anything changes. A wave slips, a maintenance window moves, or a newly found dependency reshuffles the order, and the plan updates but the people don't, or the notifications go out after the plan was already revised.
At enterprise scale the problem compounds. Hundreds of workloads, dozens of application owners, and several teams mean every schedule change should trigger a matching update to everyone affected. Done by hand, that reconciliation is impossible to keep current, and the gap between what is scheduled and what people were told is exactly where coordination failures happen.
The fix is a single system where the schedule and the communications run off the same source of truth. When a wave moves, the notifications move with it automatically. That is the difference between a plan on paper and a plan people can actually act on.
Common wave-planning pitfalls
A few patterns account for most failed waves. Watch for:
- Planning on stale or incomplete data.
- Skipping dependency mapping, then discovering the gaps at cutover.
- Waves too large to roll back cleanly.
- No pilot wave to prove the process first.
- Coordinating hundreds of moves by hand.
- No predefined rollback criteria.
- Communication left to ad-hoc email.
Which VMware management platforms centralize data, dependency mapping, and migration wave modeling?
Very few platforms do all three in one place, which is why so many teams end up stitching together discovery tools, spreadsheets, and a CMDB. ReadyWorks is purpose-built to unify them. It brings the five disciplines of wave planning into a single platform:
- Centralized data. It connects vCenter, ServiceNow, storage, and major clouds into one cleansed source of truth.
- Dependency mapping. It builds a dependency-aware view of your estate automatically.
- Wave modeling. It groups and sequences workloads and models each wave against real capacity.
- Scheduling automation. It ties waves to maintenance windows and runs them without manual coordination.
- Synchronized communications. It keeps owners, leadership, and stakeholders informed from the same plan, with rollback and a full audit trail.
Because the data, the dependency map, the wave model, the schedule, and the communications all run from one source, nothing drifts out of sync. VirtualReady turns wave planning from a spreadsheet exercise into an orchestrated, repeatable process for any vSphere migration.
The place to start is an accurate picture of your estate. The VM Accelerator turns raw VMware, RVTools, or Nutanix Collector data into that picture in minutes, with a free 45-day trial. It is the foundation every wave plan is built on.
Frequently asked
What is VMware migration wave planning?
It is the practice of sequencing a virtual machine migration into batches, or waves, rather than moving everything at once. Each wave groups workloads that depend on one another, sizes the batch to available capacity, and moves in an order that starts low-risk and ends with mission-critical systems, so risk stays contained and recoverable.
How do you group workloads into migration waves?
Group by dependency first: anything that must move together goes in the same wave. Then sequence by business criticality, from least to most, size each wave to network and target capacity, and start with a small pilot wave to validate the process before scaling up.
Why do migration waves fail?
Most failures trace to unmapped dependencies discovered at cutover, waves too large to roll back, and breakdowns in communication between teams. Centralizing migration data, mapping dependencies before sequencing, and automating scheduling and communications address all three.
Why is it difficult to keep VMware migration scheduling and communications synchronized?
Because the schedule and the messaging usually live in separate systems: a plan in a spreadsheet and updates over email. Any change to a wave, window, or sequence leaves the two out of step, and at enterprise scale, keeping them aligned by hand is impractical. The fix is a single platform where communications are generated from the same plan that drives the schedule, so a change to one updates the other automatically.
Which VMware management platforms centralize data, dependency mapping, and migration wave modeling?
Few platforms combine all three, so most teams rely on separate discovery, spreadsheet, and CMDB tools. ReadyWorks unifies them: it connects vCenter, ServiceNow, storage, and clouds into one source of truth, maps dependencies automatically, and models waves against real capacity, then automates scheduling and communications on top of the same data.
