A comprehensive preparation guide for organizations planning to move off VMware. Use this checklist to avoid the most common (and costly) migration mistakes.
Why a Checklist Matters
Gartner estimates migration costs at $300–$3,000 per VM, with enterprise-scale projects taking 18–48 months. The organizations that migrate fastest and cheapest share one trait: they did thorough pre-migration homework.
This checklist is organized into six phases. Each skipped item is a potential outage, budget overrun, or rollback.
Phase 1: Understand What You're Actually Running
Before you pick an alternative, you need a complete inventory. Most VMware shops discover surprises during migration because nobody kept a clean asset register.
1.1 Server Hardware Inventory
- [ ] List every ESXi host: brand, model, CPU (vendor + cores + generation), RAM, NIC type/speed
- [ ] Document storage adapters: Fibre Channel HBAs, iSCSI, NVMe-oF — model, firmware, driver versions
- [ ] Check HCL compatibility against your target platform (Proxmox HCL, Hyper-V HCL, Nutanix HCL)
- [ ] Flag any hardware approaching EOL: If a server needs replacement within 18 months, consider refreshing BEFORE migrating (migrate once, not twice)
- [ ] GPU devices: passthrough, vGPU, NVIDIA GRID — verify driver/API compatibility on target platform
- [ ] Measure current utilization: CPU overcommit ratio, memory consumption, storage IOPS/throughput — this determines target sizing
1.2 Virtual Machine Inventory
- [ ] Complete VM list: name, OS, vCPU, RAM, disk count/size, provisioned vs actual usage
- [ ] Identify VMs with RDM (Raw Device Mappings): These cannot be migrated with standard tools — they need separate storage migration first
- [ ] Identify VMs with passthrough devices: PCIe, USB, serial ports — verify target platform support
- [ ] Flag VMs with active snapshots: Migrating a VM with snapshots is slow and risky — consolidate first
- [ ] Identify orphaned or powered-off VMs: Don't waste effort migrating dead workloads. Archive or delete them now
1.3 Dependency Mapping
- [ ] Map VM-to-VM dependencies: Application servers → database servers, web frontends → APIs
- [ ] Identify anti-affinity rules: VMs that must NOT run on the same host (e.g., redundant domain controllers, cluster quorum nodes)
- [ ] Document boot order requirements: Infrastructure VMs (DNS, AD, NTP) must come up before application VMs
- [ ] Map external integrations: Monitoring systems, SIEM, CMDB, CI/CD pipelines that talk to vCenter APIs
Phase 2: Understand Your VMware-Specific Dependencies
Some VMware features have no direct equivalent elsewhere. Discover these NOW — not during the migration window.
2.1 Networking
- [ ] Document all distributed switch (vDS) configurations: port groups, VLANs, NIOC shares, LACP/LAG configs
- [ ] NSX inventory: DFW rules, micro-segmentation policies, load balancers, NAT rules, VPN tunnels
- [ ] NSX V → T migration consideration: NSX policies do NOT map 1:1 to any other SDN platform. Expect to manually rebuild firewalling and segmentation
- [ ] Verify IP addressing strategy: Will VMs keep their IPs? (DHCP reservations, static IPs — document them all)
- [ ] MAC address dependency check: Some license servers and legacy applications bind to MAC addresses — list them
2.2 Storage
- [ ] Determine storage architecture: Standalone SAN/NAS → easiest migration. vSAN → need full-stack replacement or storage migration first
- [ ] Document VMFS datastores: version, LUN mapping, multipathing config
- [ ] vSAN-specific: disk groups, dedup/compression, erasure coding, stretched cluster — all need replatforming
- [ ] Storage vendor lock-in: Some storage arrays use VMware-only plugins (VAAI, VASA, VVols). Verify your array supports the target platform
2.3 VMware-Only Features (No Native Equivalent)
| VMware Feature | Status on Alternatives | Mitigation |
|---|---|---|
| Fault Tolerance (FT) | No true equivalent on any platform | Application-layer HA (DB replication, Keepalived, pacemaker) |
| DRS (fully automated) | Manual or semi-auto at best | Oversize initial placement, monitor and rebalance manually |
| vSAN stretched cluster | Limited/different implementations | Ceph stretch mode (Proxmox), SAN replication, or application-layer |
| NSX micro-segmentation | Partial on Nutanix Flow, Open vSwitch | Rebuild policies; expect significant effort |
| VM Encryption (native) | Platform-specific alternatives | dm-crypt, Ceph encryption, Hyper-V Shielded VMs |
| vSphere Update Manager (VUM) | Varies by platform | Patch management may shift from hypervisor to OS-level tools |
- [ ] Inventory every FT-protected VM — this is your single highest-risk item
- [ ] Audit DRS affinity/anti-affinity rules — document the INTENT, not just the config, so you can re-implement
- [ ] Document all vSphere tags and custom attributes used for automation, backup policies, or reporting
2.4 Backup & Disaster Recovery
- [ ] Confirm backup vendor supports your target platform: Veeam now supports Proxmox, but older versions may not. Check your exact version
- [ ] Audit backup policies: which VMs, what schedule, what retention — these need re-creating on the new platform
- [ ] DR replication: SRM, Zerto, array-based replication — verify target platform support or plan replacement
- [ ] Test restore procedures BEFORE migration: You need a fast rollback path. Validate that VMware backups restore correctly
Phase 3: Know Your Licensing and Financial Position
Timing your migration around licensing events determines your budget and schedule.
3.1 VMware Contract Audit
- [ ] Find your VMware renewal date(s): Different contracts may have different end dates
- [ ] Understand your current license model: perpetual (grandfathered) or subscription (VCF/VVF/vSphere Standard)
- [ ] Request renewal quote from Broadcom NOW (if within 12 months of renewal): This is your baseline for TCO comparison
- [ ] Calculate the cost of a "bridge" renewal: If migration takes 18 months but your renewal is in 6 months, you may need a short-term renewal. Budget for it
- [ ] Per-core minimum exposure: 72-core minimum per contract. If you have 48 cores across 6 servers (8-core each), you pay for 72. This changes the math significantly
3.2 Target Platform Budget
- [ ] License/subscription costs for target platform: Free (Proxmox, XCP-ng) vs paid (Nutanix, Red Hat) vs included (Hyper-V if already on Windows Server DC)
- [ ] Support contract costs: Proxmox ~$1K/yr per cluster, Nutanix bundled, XCP-ng €340-1,020/yr per node
- [ ] Migration tooling costs: Many tools are free (StarWind V2V, qemu-img, WAC) but enterprise tools (Veeam, Hystax, ZConverter) cost
- [ ] Hardware refresh cost (if needed): Factor in if your servers are near EOL or incompatible with the target platform
- [ ] Training budget: Budget 2-5 days of training per admin, plus a learning curve productivity dip
3.3 Build Your TCO Model
- [ ] Model 3-year and 5-year scenarios: License + support + migration labor + training + hardware
- [ ] Include the cost of doing nothing: Staying on VMware for 5 years at Broadcom pricing. This is often the most persuasive number
- [ ] Calculate break-even point: In how many months does the migration pay for itself?
Phase 4: Assess Your Team's Readiness
The best alternative on paper can fail if your team can't operate it.
4.1 Skills Inventory
- [ ] Survey the team: Is anyone already familiar with Linux/KVM, Hyper-V, or public cloud?
- [ ] Identify your vCenter power users: Their workflows need the most translation effort
- [ ] Assess scripting/automation skills: What's in PowerCLI today? Will it need rewriting in bash/Python/Ansible?
- [ ] Identify your NSX/networking specialist: They'll have the heaviest lift — NSX migrations are the hardest part
4.2 Training Plan
- [ ] Schedule training BEFORE migration starts: Teams that learn on the job make costly mistakes
- [ ] Run a lab migration: Give each admin a sandbox to break and rebuild on the target platform
- [ ] Identify platform certifications: If required by compliance or confidence-building (e.g., Nutanix Certified Professional, Proxmox VE Administrator)
- [ ] Document the "vCenter-to-[new platform]" translation map: Common tasks and how they translate (e.g., "vMotion → Live Migration → XenMotion")
4.3 Operations Impact
- [ ] Map monitoring tools: How will you monitor the new platform? Same tools or new ones?
- [ ] Patching cadence: How does the target platform handle updates? More frequent? Less?
- [ ] Backup workflow changes: If backup UI/API changes, update runbooks
- [ ] On-call runbook update: The 3am page-out playbook must be rewritten for the new platform
Phase 5: Pick Your Migration Strategy
There are four common migration patterns. Choose before you start executing.
5.1 Migration Patterns
| Pattern | Description | Best For |
|---|---|---|
| Lift and Shift | VMs converted as-is to the target hypervisor | Most migrations; lowest risk |
| Rebuild and Replace | VMs rebuilt fresh on the new platform from config management | Immature/appliance VMs or where you want to modernize |
| Hybrid Coexistence | Some workloads on VMware, some on new platform, indefinitely | Large enterprise; phased migration |
| Full Rip and Replace | All workloads moved, VMware decommissioned | Smaller environments; strong motivation to exit |
- [ ] Choose your pattern(s) per workload tier
- [ ] Decide: one big migration event or staggered batches? (Batches = safer, slower. Big bang = faster, riskier)
5.2 Wave Planning
- [ ] Define Wave 0 (POC): 20-50 non-critical VMs, validate tools + process + performance
- [ ] Define Wave 1 (Low Risk): Dev/test environments, internal tools, non-customer-facing apps
- [ ] Define Wave 2 (Medium Risk): Internal production, batch processing, reporting systems
- [ ] Define Wave 3 (High Risk): Customer-facing production, databases, FT-protected systems
- [ ] Define Wave 4 (Hardest): NSX-dependent, FT-protected, legacy OS, complex networked apps
5.3 Tool Selection
- [ ] Evaluate migration tools against your wave plan: Free tools for simple VMs, enterprise tools for complex/large-scale
- [ ] Test tool with a single representative VM first, then with your Wave 0 batch
- [ ] Measure throughput: How many VMs per day/week can the tool realistically handle?
Phase 6: Risk Mitigation and Rollback Planning
Assume something will go wrong. Plan for it.
6.1 Pre-Migration Validation
- [ ] Run a full backup of every VM the day before migration
- [ ] Test that backup restores cleanly — the worst time to discover backup corruption is during a failed migration rollback
- [ ] Snapshot source VMs immediately before migration (if the tool doesn't do this automatically)
- [ ] Pre-stage target environment: Storage, networking, VLANs, IP pools all configured and tested
- [ ] Validate target platform can boot a test VM before migrating any production workloads
6.2 During Migration
- [ ] Define a hard stop-loss trigger: "If X consecutive VMs fail, stop all migrations and investigate"
- [ ] Monitor source VM performance during replication: Migration tools that do block-level replication can impact source performance
- [ ] Have a rollback procedure documented and communicated: How fast can you power the source VM back on and fail back?
- [ ] Migrate during a defined maintenance window (don't rely on live migration for Wave 1)
6.3 Post-Migration Validation
- [ ] Network connectivity test: Can the VM reach its dependencies? Can clients reach the VM?
- [ ] Application health check: Does the application start? Do all services pass health checks?
- [ ] Performance baseline comparison: Compare CPU, memory, disk latency to pre-migration baselines
- [ ] Backup validation: Does the new platform's backup job succeed? Can you restore?
- [ ] Monitoring check: Is the VM reporting to your monitoring system? Are alerts firing?
- [ ] Wait 24-48 hours before deleting source VM/backup: Some issues only surface under real load
The One-Page Summary: Print This Before You Start
BEFORE YOU TOUCH A SINGLE VM, CONFIRM:
□ Complete VM inventory (OS, vCPU, RAM, disk, dependencies) — documented
□ Every FT-protected VM identified and application-layer HA plan ready
□ Every RDM and passthrough device identified and migration path confirmed
□ All NSX rules documented (they will not auto-convert)
□ VMware renewal date known and bridge cost budgeted
□ Target platform selected and POC tested (20-50 VMs)
□ Backup vendor confirmed compatible with target platform
□ Full backup completed and RESTORE TESTED for migration-candidate VMs
□ Team trained on target platform (NOT learning on the job)
□ Rollback procedure written, tested, and time-boxed
□ Migration tool tested at representative scale
□ Wave plan defined and approved by stakeholders
□ Maintenance windows scheduled and communicated
□ Post-migration validation checklist ready
What Happens If You Skip This
| Skipped Item | Typical Consequence | Real-World Example |
|---|---|---|
| FT inventory | Critical VM has no HA on target platform; outage on first host failure | Financial services firm: 6-hour trading system outage |
| RDM/passthrough audit | VM fails to migrate; extended troubleshooting; missed migration window | Healthcare org: PACS imaging system offline for 3 days |
| NSX policy documentation | Security rules lost; VMs exposed after migration | E-commerce: internal admin panel accidentally internet-accessible |
| Backup restore test | Migration fails, backup is corrupt, no rollback path | MSP: 3 customers lost data |
| Team training | Misconfigurations cause repeated outages; team morale tanks | Enterprise: migration abandoned halfway, stayed on VMware at higher cost |
| License renewal timing | Forced into expensive short-term renewal; migration budget gone | SMB: $80K unplanned Broadcom renewal, migration delayed 12 months |
Next Steps
Once you've worked through this checklist:
- Select your top 2 candidate platforms from the VMware Alternatives Comparison Guide
- Run a POC with 20-50 non-critical VMs on each candidate
- Read the migration tutorial for your chosen platform:
Last updated: April 2026. Migration tool landscapes change quickly — verify all tool compatibility before starting your project.
Top comments (0)