After working on VMware environments for nearly two decades, one thing has become clear: the hardest part of a virtualization migration is rarely the technology.

It’s understanding the environment well enough to move workloads without breaking the applications that depend on them.

In this article I’ll walk through the practical approach I use when planning large VMware migrations, from discovery to wave planning.

Why Migrate?

Often times migrations within the IT Infrastructure are dictated by one of the following reasons:

Current infrastructure is so far out of date that it would take too many upgrades to get the infrastructure to a supported version of the software.
Bringing the Architecture back from the cloud
Complete infrastructure redesign to enable more modern workflows and Data Center Consolidation
NSX-V to NSX-T migration

Step 1 – Discovery and Environment Analysis

Before planning a migration, you need a clear picture of the existing environment.

This includes gathering data such as:

Number of VMs
CPU and memory usage
Storage consumption
Network segments
Cluster and host configuration
Application dependencies

A common tool used for this stage is RVTools, which can export a large amount of information from a vSphere environment.

Typical data points collected include:

VM inventory
Network assignments
Disk usage
Power state
CPU and memory allocation
Resource pool usage

Once collected, this data should be normalized into a format that allows analysis of:

VM density
Resource utilization
Network segmentation
Application grouping

The goal of discovery is to answer one fundamental question:

What actually exists in the environment today?

In many cases, organizations are surprised by what they find during this phase.

Step 2 – Application and Network Mapping

The next step is understanding how workloads communicate with each other.

Virtual machines rarely operate in isolation. Most applications consist of multiple tiers such as:

Web servers
Application servers
Database servers
Backend services

Understanding these relationships is critical to avoid breaking applications during migration.

Tools that can assist with this include:

vRealize Network Insight (Known as VCF Operations for Networks in recent releases)

The output of this phase should include:

Application groupings
Network segments used by each application
Dependency mapping between workloads

This allows workloads to be migrated as logical groups rather than individual VMs.

Step 3 – Designing Migration Waves

Once workloads are grouped logically, migrations should be organized into migration waves.

A migration wave is simply a group of workloads that will be moved together during a specific migration window.

Migration waves are typically designed around:

Application dependencies
Network segments
Resource availability
Business impact

A typical wave strategy might look like:

Wave	Workload Type	VM Count
Wave 1	Low-risk infrastructure systems	50
Wave 2	Internal applications	120
Wave 3	Tier-2 business applications	200
Wave 4	Tier-1 production workloads	150

Starting with low-risk workloads allows the migration team to validate the process before moving critical systems.

Step 4 – Selecting the Migration Method

There are several methods available for migrating virtual machines.

The appropriate method depends on factors such as:

Network availability
Downtime tolerance
Storage architecture
Distance between sites

Common migration approaches include:

vMotion

Used when environments share the same vCenter or when Enhanced Linked Mode is configured.

Advantages:

Zero downtime
Fast migration

Limitations:

Requires network and storage connectivity between environments.

Storage vMotion

Used when the storage platform is changing but the compute environment remains the same.

HCX Replication Assisted vMotion (RAV)

One of the most commonly used tools for large migrations between environments.

Advantages:

Handles long distance migrations
Works across different vCenters
Allows replication before cutover
Reduces migration downtime

Typical workflow:

VM replication begins
Data is synchronized between environments
Final cutover occurs
Source VM is powered off
Target VM becomes active

This approach allows migrations with minimal downtime even across data centers.

Step 5 – Handling Network Transitions

One of the biggest challenges in VMware migrations is network continuity.

Virtual machines often expect to remain on the same IP address and network segment.

There are several approaches to handling this:

Layer 2 Extension

Technologies such as HCX network extension allow networks to span across environments temporarily.

Advantages:

No IP changes required
Simplifies migration waves

Drawbacks:

Should be temporary
Can introduce complexity if left in place too long

Network Re-IP Strategy

In some cases workloads are migrated to new networks entirely.

This requires:

Application coordination
DNS updates
Change management

Gradual Gateway Migration

A common strategy is:

Extend the network between environments
Migrate VMs gradually
Once most workloads are moved, shift the gateway to the new environment
Remove the extension

This minimizes disruption while allowing a phased migration.

Step 6 – Testing and Validation

After each migration wave, validation should be performed.

Typical checks include:

Application availability
Network connectivity
DNS resolution
Storage performance
Monitoring alerts

Migration teams should also validate:

Backup functionality
Logging
Security policies
Load balancers
External integrations

Skipping validation can allow issues to go unnoticed until later waves.

Step 7 – Operational Readiness

After migration is complete, the new environment must be ready for day-2 operations.

This includes:

Monitoring configuration
Backup validation
Lifecycle management setup
Capacity planning
Documentation updates

Operational readiness is often overlooked but is essential for long-term stability.

Key Lessons from Real-World Migrations

Across many environments, several patterns emerge:

Discovery takes longer than expected.

Organizations rarely have accurate documentation of their virtualization environments.

Network dependencies cause the most problems.

Applications often rely on undocumented communication paths.

Migration tooling is rarely the hardest part.

The real challenge is understanding the environment well enough to move it safely.

Conclusion

VMware migrations are complex projects, but with proper planning they can be executed smoothly and with minimal disruption.

The key is approaching migrations as an architecture and planning exercise rather than just a technical task.

By focusing on:

Thorough discovery
Application dependency mapping
Logical migration waves
Proper tooling
Operational readiness

organizations can successfully modernize their virtualization platforms while minimizing risk.