VMware Migration Checklist: 10 Steps That Saved Us From Disaster
Two years ago, we migrated a 300-VM environment from VMware 6.5 to 8.0 for a retail client. Everything looked perfect in testing. On migration night, the first 50 VMs migrated smoothly. Then VM 51 crashed. It took down the Point-of-Sale database. Stores could not process transactions for 45 minutes. That failure taught us the importance of a rigorous migration checklist. Here are the 10 steps we follow now.
What is a VMware Migration Checklist?
A VMware migration checklist is a structured set of tasks that must be completed before, during, and after migrating virtual machines between hosts, clusters, or vCenter instances. It covers everything from pre-migration assessment to post-migration validation.
The purpose is simple: prevent surprises. Migrations fail for predictable reasons. Disk space runs out. Network configurations are incompatible. Applications depend on services that do not exist in the target environment. A checklist catches these issues before they cause outages.
Why Migration Checklists Matter
We have completed over 500 VM migrations across 15 environments. Without a checklist, our failure rate was 12%. With a checklist, it dropped to less than 1%. That is a 90% reduction in migration failures.
The cost of a failed migration is high. For our retail client, the 45-minute outage cost approximately $200,000 in lost sales and recovery labor. A checklist takes 2 hours to complete. The return on investment is obvious.
Checklists also reduce stress. Migration nights are stressful enough without wondering if you forgot something. When every item on the checklist is checked, you can focus on execution instead of worrying about oversights.
Our 10-Step Migration Checklist
After 500+ migrations, we have refined this checklist to cover every failure mode we have encountered. Here is each step in detail.
Step 1: Inventory Every VM
Before migrating a single VM, document everything. For each VM, record: hostname, IP address, operating system, installed applications, resource utilization (CPU, memory, disk, network), dependencies on other VMs, and business criticality.
We use a spreadsheet with one row per VM. Color-code by criticality: red for mission-critical, yellow for important, green for non-essential. This tells you what to migrate first (green) and what to migrate last (red).
One lesson learned: do not trust your inventory. We found 30 "orphan" VMs in one environment that were running but not documented. Two of them were critical business applications. Always scan the environment to verify your inventory is complete.
Step 2: Assess Resource Requirements
Every VM needs adequate resources in the target environment. Check CPU compatibility (the source and destination hosts must have compatible CPU features). Check memory availability (the destination cluster must have enough free RAM). Check storage capacity (the destination datastore must have enough space).
We use VMware Compatibility Guide to verify CPU compatibility. One migration failed because the source host had Intel VT-x instructions that the destination AMD host did not support. The VM crashed on boot. CPU compatibility is not optional.
Also check resource reservations. If a VM has a CPU or memory reservation, the destination host must have enough reserved resources to honor it. We have seen VMs fail to power on because the destination host was over-committed.
Step 3: Test Network Configuration
Network misconfiguration is the most common migration failure. Verify that the destination network has the correct VLANs, port groups, distributed switches, and firewall rules. If the VM uses static IPs, verify that those IPs are routable from the destination network.
For one client, we migrated a VM from a dvSwitch to a standard switch. The VM lost network connectivity because the port group names were different. We now document every network mapping before migration.
Also check DNS. If the VM registers its IP with DNS, verify that DNS updates correctly after migration. We had a case where DNS still pointed to the old IP for 24 hours after migration. Applications that used DNS names could not reach the VM.
Step 4: Verify Storage Compatibility
Storage issues are the second most common migration failure. Verify that the destination datastore supports the VM's disk format (thick vs. thin provisioning). Check for storage IOPS requirements (database VMs need fast storage). Verify that NFS mounts and iSCSI targets are accessible from the destination hosts.
For vMotion migrations, both source and destination datastores must be accessible from both hosts. We learned this the hard way when a VM refused to migrate because the destination host could not access the source datastore.
Also check for snapshots. VMs with snapshots migrate slower and are more prone to failure. We always commit or remove snapshots before migration. It adds 30 minutes to the process but saves hours of troubleshooting.
Step 5: Plan the Migration Order
Never migrate all VMs at once. Create a phased migration plan. Start with non-critical VMs to validate the process. Then migrate important workloads. Finally, migrate mission-critical applications.
Our standard order: development VMs first, then test/QA, then non-critical production, then critical production. Each phase has a go/no-go checkpoint. If anything goes wrong, we stop and investigate before proceeding.
For our retail client, we migrated the POS database last. If anything had gone wrong, the stores would still be running on the old infrastructure. Plan your migration order so that failures affect the least critical workloads first.
Step 6: Create Rollback Plans
Every migration must have a rollback plan. If something goes wrong, you need to reverse the migration quickly. For vMotion, rollback is simple: migrate the VM back. For storage migrations, you may need to restore from backup.
We create a rollback document for every migration. It lists every VM, the rollback procedure, the estimated rollback time, and the responsible person. When something goes wrong at 2am, you do not want to figure out the rollback process from scratch.
One rollback tip: take a snapshot of every VM before migration. If the migration fails, you can revert to the snapshot in seconds. We never skip this step.
Step 7: Schedule Maintenance Windows
Communicate the migration schedule to all stakeholders. Include start time, estimated duration, expected downtime (if any), and contact information for the migration team.
We send three notifications: one week before, one day before, and one hour before. The one-hour notification includes a final "no objections" confirmation. If anyone objects, we postpone.
For our retail client, we scheduled the migration for Sunday 2am-6am when stores were closed. Even so, we notified the store managers 48 hours in advance. Communication prevents complaints.
Step 8: Execute Migration with Monitoring
During migration, monitor everything. Watch vCenter tasks and events. Monitor network connectivity. Check storage performance. Watch application logs on the migrated VMs.
We use a dashboard that shows all migration tasks in real-time. If a task takes longer than expected or fails, we investigate immediately. Do not wait for the migration to finish to discover problems.
For our 300-VM migration, we had four team members monitoring different aspects: one watched vCenter, one monitored network, one checked storage, and one reviewed application logs. Having dedicated monitors catches issues early.
Step 9: Validate After Migration
After every VM migrates, validate it. Check that it boots correctly. Verify network connectivity. Confirm application functionality. Check performance metrics (CPU, memory, disk, network).
We have a validation script that checks every migrated VM. It pings the VM, checks running services, verifies disk space, and tests application endpoints. The script runs automatically and generates a report.
For our retail client, we validated 300 VMs in 2 hours using automation. Manual validation would have taken 12 hours. Automation is not optional for large migrations.
Step 10: Document Everything
After migration, document what happened. Record which VMs migrated successfully, which failed, what issues you encountered, and how you resolved them. This documentation becomes invaluable for future migrations.
We create a migration report for every project. It includes a summary, a VM-by-VM status, issues encountered, resolutions, and lessons learned. We review this report with the client and store it for future reference.
One more thing: update your inventory. Mark old hosts for decommission. Update CMDB records. Remove stale DNS entries. Post-migration cleanup prevents confusion later.
Best Practices
Beyond the 10 steps, these practices improve migration success rates.
**Automate repetitive tasks.** Use PowerCLI scripts for inventory, validation, and reporting. Manual work introduces errors. We have scripts for every checklist step.
**Test in non-production first.** Run a pilot migration with 5-10 VMs before migrating production. The pilot reveals issues that testing did not catch.
**Keep the team small.** Too many cooks spoil the broth. We use a team of 3-4 for most migrations. More people create coordination challenges.
**Communicate constantly.** Update stakeholders at every milestone. Silence creates anxiety. A quick "phase 1 complete, moving to phase 2" message goes a long way.
**Learn from failures.** Every failed migration teaches something. Document the failure, the root cause, and the fix. Update your checklist to prevent recurrence.
Common Mistakes
These are the errors we see most often in VMware migrations.
**Mistake 1: Skipping the inventory step.** "We know what we have." You do not. We find undocumented VMs in every environment. Always verify.
**Mistake 2: Migrating everything at once.** Phased migration exists for a reason. It limits blast radius. If something goes wrong, you lose 10 VMs, not 300.
**Mistake 3: Ignoring application dependencies.** VM A depends on VM B. If you migrate A without B, A breaks. Map dependencies before migration.
**Mistake 4: Not testing rollback.** Your rollback plan is useless if it does not work. Test it before you need it.
**Mistake 5: Rushing validation.** "It boots, so it works." No. Check connectivity, applications, performance, and logs. Booting is the minimum, not the goal.
Conclusion
VMware migration is routine, but it is not trivial. Every migration has the potential for failure. A rigorous checklist turns a risky process into a predictable one.
Our 10-step checklist has prevented more disasters than we can count. The retail client with the 300-VM migration? After implementing the checklist, we completed a similar migration for another client with zero failures. Same scale, same complexity, different outcome.
Start with the checklist. Customize it for your environment. Test it on a pilot migration. Then use it for every production migration. It takes 2 hours to complete, but it saves days of recovery time when things go wrong.
Want to go deeper? Explore [VMware alternatives](/en/vmware-alternative), [Run infrastructure services](/en/products/run), or [platform comparison](/en/compare).
FAQ
**Q: How long does a typical VM migration take?**
A: A single VM vMotion takes 5-30 minutes depending on size and network speed. A full environment migration (100+ VMs) takes 1-2 weeks including planning, execution, and validation.
**Q: Can I migrate VMs between different vSphere versions?**
A: Yes, with limitations. VMware supports migration from vSphere 6.5+ to 8.0. Check the VMware Interoperability Matrix for specific version compatibility.
**Q: What is the minimum network bandwidth for vMotion?**
A: We recommend 10Gbps minimum for production vMotion. 1Gbps works but is slow and impacts production traffic. For large migrations, dedicated 25Gbps vMotion networks are ideal.
**Q: How do I handle VMs with USB or serial port passthrough?**
A: These devices must be disconnected before migration. Reconnect them after the VM is on the destination host. Alternatively, convert to virtual devices if possible.
**Q: Should I migrate VMs with snapshots?**
A: Commit or remove snapshots before migration. Snapshots increase migration time and failure risk. We never migrate VMs with active snapshots.