“Most organizations fail not because they chose the wrong target platform, but because they started with the wrong question. “Which hypervisor should we move to?”. The right first question is: what should actually move, when, and at what cost?”
– Mark Googins, iShift CEO
This checklist is structured for two audiences simultaneously: the economic buyer who needs confidence in the business case and risk profile, and the technical champion who has to actually execute it.
1) Commercial Triage
[ ] Audit your current VMware contract. Identify renewal date, per-core vs. per-socket pricing, and any bundled components (NSX, vSAN, Aria) you may not be using but are paying for.
[ ] Quantify the cost delta. Compare your projected VMware renewal cost over 3 years against migration spend + target platform TCO. Include hidden costs: staff retraining, tooling, and one-time migration labor.
[ ] Identify leverage windows. Are any workloads already in AWS, Azure, or GCP? Cloud providers will often offer migration credits and architecture support to competitive displace VMware.
[ ] Freeze discretionary VMware expansion. No new VMs on VMware until the migration plan is finalized. Scope creep is the silent budget killer.
2) Discovery and Inventory
[ ] Run a full VM inventory. Use RVTools, vRealize Operations, or equivalent to export every VM with CPU/RAM allocation, actual utilization, OS version, and age. Right-size before you migrate — moving bloated VMs is just moving waste.
[ ] Map application dependencies. Identify which VMs communicate with each other (network flow data, not just assumptions). Tools like Zerto, CloudAmize, or AWS Migration Hub help. Migrating a VM whose dependency stayed behind is a 2 AM incident.
[ ] Flag VMware-specific dependencies. Are you using NSX network virtualization, vSAN for storage, or Site Recovery Manager for DR? These require migration paths of their own and are frequently overlooked until late in the process. Technical
[ ] Identify workloads that can simply be retired. In most estates, 15–25% of VMs are orphaned, redundant, or running applications that were decommissioned in name only. Retirement before migration saves money on both sides of the ledger.
[ ] PRO TIP #1 Don’t let discovery become a stall tactic. Most teams spend 3–4 months in discovery. With the right tooling and a structured intake process, a 500-VM estate can be fully inventoried, dependency-mapped, and classified in under three weeks. Speed here creates momentum that carries through every subsequent wave
3) Planning and Sequencing
[ ] Define migration waves. Group workloads by dependency clusters, not alphabetical order or business unit. Wave 1 should be simple, low-risk VMs.
[ ] Define “done” beyond infrastructure cutover. A migration is not complete when the VM boots on the new platform. Define success as: application validated, monitoring configured, backup confirmed, runbook updated, and handoff to ops completed.
[ ] Establish rollback criteria for each wave. Before every cutover window, document exactly what condition triggers a rollback and who has the authority to call it.
[ ] Select and validate migration tooling. Evaluate VMware HCX, Zerto, CloudEndure/AWS MGN, Azure Migrate, or Veeam, depending on your target. Run at least one rehearsal migration of a non-critical workload before committing to a wave.
[ ] Lock down a parallel-run window. For production workloads, plan for a minimum 2-week parallel run period where both old and new environments are active and compared.
[ ] PRO TIP #2 Wave 1 is your proof of concept — treat it that way. The first migration wave should be deliberately chosen to stress-test your toolchain, runbooks, and cross-team communication — not just to move easy VMs. Teams that use Wave 1 as a real dress rehearsal cut incident rates in later waves by more than half.
4) Security and Compliance
[ ] Re-evaluate network segmentation. If NSX was doing your micro-segmentation, you need a replacement policy before migrating. Security groups, VPCs, or host-based firewalls need to be configured on the target, not retrofitted later.
[ ] Audit encryption-at-rest coverage. VMware VM Encryption may have been transparent. Ensure your target platform and storage layer provide equivalent coverage and that your key management integration is in place.
[ ] Validate compliance posture on the target. If you operate under PCI-DSS, HIPAA, SOC 2, or FedRAMP, confirm that your target platform has appropriate certifications and that your control mapping is updated pre-migration, not post-audit.
[ ] PRO TIP #3 Update your CMDB and asset register. Migration is an opportunity to fix inventory debt. Every asset in the new environment should be recorded with owner, classification, and backup policy on day one.
5) Post-Migration Operations
[ ] Establish new operational baselines within 30 days. Define normal CPU, memory, network, and storage metrics for each migrated workload. Alerts calibrated against VMware history will fire constantly — or not at all — on a new platform.
[ ] Confirm backup and DR posture independently. Validate that RPO/RTO SLAs are met on the new platform and test a restore within 60 days of cutover.
[ ] Formally close the VMware footprint. Decommission hosts, reclaim licenses, and issue termination notices per your contract. Companies routinely pay for VMware licenses 12+ months after migration because no one owns the close-out step.
[ ] PRO TIP #4 Capture a cost-reality report at 90 days. Compare actual post-migration spend vs. the business case projection. Surface variances early — optimization is easier before patterns calcify.
PRO TIP #5 Know where your migration tool stops and your risk begins
Every migration tool has a boundary — and vendors rarely advertise where it is. VMware HCX, for example, handles compute mobility well but has known limitations with storage policies, stretched layer-2 networks, and vSAN-backed VMs that aren’t clearly documented until you’re mid-migration. AWS MGN excels at replication but hands off networking, IAM, and DNS configuration entirely to your team. Zerto is strong on continuous replication but requires careful thought around journal sizing and WAN bandwidth under load.
The risk isn’t the tool — it’s assuming the tool covers more than it does. Before committing to any toolchain, run a formal boundary analysis: document exactly what each tool automates, what it assists, and what it leaves completely to manual process.
The Exit is Complex. Staying is More Expensive
The organizations that succeed treat this as a structured program, not a project. That means a named program owner, a steering committee with CFO visibility, and a weekly migration scorecard. It’s unglamorous. And it works.
This checklist covers the essential structure, but every environment has idiosyncrasies. The value isn’t in the list — it’s in the discipline of working through it before the first VM moves.
We are iShift, a migration partner currently supporting VMware exit initiatives involving more than 41,000 VMs across over 3,000 hypervisors. Do you want to learn more? VMware Exit Migration
Do you want to test-drive the alternatives side by side? Proof of Value Environment – VMware Alternatives
