The VMware migration checklist.

Migrations don't fail because the tooling breaks. They fail because something nobody wrote down, an undocumented dependency, an untested restore, a rollback plan that existed only in someone's head, surfaces at 2 a.m. on cutover night. This checklist is the writing-it-down part. Pair it with the phase-by-phase timeline and the cost guide.

Pre-migration

1. Inventory everything

• ☐  Export a complete VM inventory: name, vCPU, RAM, provisioned/used storage, OS and version, owner, business function
• ☐  Flag legacy OSes (Windows 2008/2012, old RHEL/CentOS), they constrain target-platform choices
• ☐  Capture host details: CPU model, core counts, age, warranty status
• ☐  Document non-VM dependencies: physical servers, appliances, USB dongles, licensing servers
• ☐  Record per-VM performance baselines (CPU, memory, IOPS, latency) for post-migration comparison

2. Map dependencies

• ☐  Run dependency discovery (netflow/agent-based) for at least 2–4 weeks to catch monthly jobs
• ☐  Document inter-VM communication and app-tier groupings, these define your migration waves
• ☐  Identify hard-coded IPs, hostnames, and certificates that break on re-IP
• ☐  Interview app owners; the diagram always misses something a human knows

3. Audit licensing

• ☐  Confirm exact VMware subscription/SnS expiry dates and any auto-renew clauses (see licensing guide)
• ☐  Count physical cores per host, your Broadcom quote and your exit math both depend on it
• ☐  Inventory guest licensing tied to the platform: Windows Server, SQL, Oracle (core-count sensitive!)
• ☐  Check third-party tool entitlements (backup, monitoring, AV) for target-platform support

4. Backup & DR plan

• ☐  Verify current backups are complete and actually restorable, test a restore now, not during cutover
• ☐  Take a full backup baseline of every VM immediately before its wave
• ☐  Confirm backup software supports the target platform (or select replacement)
• ☐  Document current RTO/RPO per workload and confirm the target design meets them

5. Validate the target

• ☐  Target platform selected against real requirements, not demos (comparison matrix)
• ☐  Target environment built, patched, and monitored before the first VM moves
• ☐  Network connectivity, VLANs, firewall rules, and DNS tested end to end
• ☐  Storage performance benchmarked against source baselines
• ☐  If using a managed provider: SLA, exit terms, and compliance attestations reviewed (provider directory)

6. Pick the pilot & define rollback

• ☐  Pilot group selected: representative but low-blast-radius (dev/test plus one tolerant prod app)
• ☐  Written rollback criteria per wave: what failure triggers rollback, who decides, within what time box
• ☐  Rollback mechanics tested, actually fail back one pilot VM on purpose
• ☐  Success criteria defined per wave and signed by app owners in advance

During migration

7. Run the cutover runbook

• ☐  Per-wave runbook with timed steps, named owners, and decision points, rehearsed on the pilot
• ☐  Maintenance windows communicated to users and customers in advance
• ☐  Final replication sync verified before each cutover
• ☐  DNS TTLs lowered ahead of cutover day
• ☐  Source VMs powered off, not deleted, and locked against accidental restart
• ☐  Monitor source and target for replication lag and performance during each wave
• ☐  Keep the rollback path live until the wave's validation gate passes
• ☐  Log every issue and resolution as you go, wave 1's problems are wave 3's prevention

Post-migration validation

8. Prove it works

• ☐  Every VM passing health checks; app owners sign off against the pre-agreed success criteria
• ☐  Performance compared to pre-migration baselines, with deltas explained
• ☐  Backup jobs running and a test restore completed on the new platform
• ☐  DR failover/failback tested end to end
• ☐  Security scan and compliance checks (PCI/HIPAA/CMMC scope) on the new environment

9. Close it out

• ☐  Old VMware hosts decommissioned after the agreed hold period (keep a final cold backup)
• ☐  License termination/non-renewal notice sent to Broadcom or your reseller before the auto-renew date
• ☐  Monitoring, alerting, and CMDB updated to the new platform
• ☐  Runbooks and documentation rewritten for the new stack; team training completed
• ☐  Actual costs captured vs. budget, close the loop on the business case

The wave-gate cheat sheet

Want a second set of eyes on your plan, or providers who'll execute it under SLA? Start with a free assessment, and use the calculator to budget the project first.