In 2023, we lost a client because of a migration that went sideways. Not because the migration failed technically — the VMs all moved successfully. But because nobody told the finance department that their billing system would be down for 4 hours on a Friday night. The finance team had a regulatory submission due Saturday morning. The billing system being down meant they could not pull the reports they needed.
That incident cost us the client. It also gave us something valuable: a migration checklist that covers not just the technical steps, but the organizational communication, the business impact, and the recovery procedures that most migration guides ignore.
Since then, we have completed 50+ migrations without a single production disaster. This is that checklist.
Why Most VMware Migration Checklists Fail
Every vendor and consulting firm has a migration checklist. They all focus on the same things: export VMs, convert formats, import to new platform, verify. That is about 30% of what matters.
The other 70% — the part that actually prevents disasters — includes: stakeholder communication, business impact analysis, rollback procedures, data validation, licensing implications, network planning, and post-migration monitoring. Most checklists skip these because they are "soft" topics. But soft topics cause hard problems.
Our checklist is organized into 7 phases, each with specific checkpoints. We use it for every migration, whether it is VMware to VMware (version upgrade), VMware to Proxmox, VMware to Sangfor, or VMware to cloud.
Phase 1: Pre-Migration Assessment (Week 1)
The assessment phase determines whether your migration plan is realistic. Most migration failures trace back to an incomplete assessment.
Technical checkpoints:
[ ] Complete VM inventory — every VM with OS, CPU, RAM, disk, network config, dependencies.
[ ] Workload utilization analysis — 30-day average CPU, memory, disk I/O, network I/O for each VM.
[ ] Storage assessment — total storage used, thin vs thick provisioning, storage performance baseline.
[ ] Network assessment — VLAN structure, firewall rules, DNS dependencies, load balancer configurations.
[ ] Compatibility check — verify all hardware and software is compatible with the target platform.
[ ] Third-party dependency mapping — backup agents, monitoring tools, management plugins that need updates.
Business checkpoints:
[ ] Identify critical business processes and their supporting VMs.
[ ] Determine RPO/RTO for each critical workload.
[ ] Identify blackout periods — business periods when migration is not allowed.
[ ] Confirm budget and timeline alignment with business expectations.
[ ] Stakeholder sign-off on migration plan and downtime windows.
Phase 2: Stakeholder Communication (Week 1-2)
This is where our 2023 disaster happened. The technical team knew about the migration. The business teams did not. Here is our communication protocol:
Communication checkpoints:
[ ] Notify IT leadership — formal migration plan document with timeline, risks, and rollback procedures.
[ ] Notify department heads — which systems will be affected and when. Use plain language, not technical jargon.
[ ] Notify end users — minimum 2 weeks advance notice for any downtime. Include: what is changing, when, how long, what they need to do.
[ ] Notify external stakeholders — customers, partners, vendors who might be affected.
[ ] Set up communication channel — dedicated Slack/Teams channel or email group for migration updates.
[ ] Designate a migration communications lead — one person responsible for all migration communications.
[ ] Prepare emergency contact list — who to call if something goes wrong at 2 AM.
Phase 3: Preparation and Staging (Week 2-4)
This is where the technical groundwork happens. Do not skip these steps.
Infrastructure checkpoints:
[ ] Deploy target infrastructure — servers, storage, networking at the destination.
[ ] Verify network connectivity — test throughput, latency, and reliability between source and destination.
[ ] Configure storage — set up datastores, LUNs, or storage pools on the target.
[ ] Install and configure the target hypervisor or platform.
[ ] Set up management tools — monitoring, backup, alerting for the new environment.
[ ] Test backup and restore on the new platform — before migrating anything, confirm you can restore.
Data checkpoints:
[ ] Take full backups of all VMs to be migrated — not just snapshots, full backups.
[ ] Verify backup integrity — restore one backup to confirm data is complete and consistent.
[ ] Document current VM configurations — export VMX files, network configs, storage mappings.
[ ] Record current performance baselines — these become your post-migration comparison targets.
Phase 4: Pilot Migration (Week 4-5)
Always start small. Migrate 3-5 non-critical VMs first. This validates the process without risk.
Pilot checkpoints:
[ ] Select pilot VMs — choose VMs that represent different workload types (database, web server, file server).
[ ] Execute pilot migration — follow the exact procedure you plan for production.
[ ] Validate pilot VMs — boot, network connectivity, application functionality, performance.
[ ] Test rollback — can you restore the pilot VMs to the source if something goes wrong?
[ ] Document issues encountered — every problem you hit during the pilot is a problem you will not hit in production.
[ ] Update migration procedure based on pilot learnings.
[ ] Get stakeholder approval to proceed with production migration.
Phase 5: Production Migration (Week 5-10)
This is the main event. Execute in batches, not all at once.
Migration execution checkpoints:
[ ] Schedule maintenance windows — communicate exact start and end times to all stakeholders.
[ ] Pre-migration snapshot — take a snapshot of each VM before migration. This is your rollback point.
[ ] Execute migration — follow the documented procedure step by step.
[ ] Post-migration validation — boot, network, application functionality, performance comparison.
[ ] Update DNS and network configurations — point users to the new infrastructure.
[ ] Monitor for 24 hours — watch for performance issues, errors, or unexpected behavior.
[ ] Notify stakeholders of migration completion — confirm systems are operational.
Batch management checkpoints:
[ ] Migrate Tier 3 VMs first (lowest risk).
[ ] Migrate Tier 2 VMs next (moderate risk).
[ ] Migrate Tier 1 VMs last (highest risk, most validation needed).
[ ] Pause between batches if issues arise — do not proceed until issues are resolved.
Phase 6: Validation and Optimization (Week 10-12)
Migration is not complete when VMs are running. It is complete when you confirm everything works as well as (or better than) before.
Validation checkpoints:
[ ] Performance comparison — compare post-migration metrics against pre-migration baselines.
[ ] Application testing — functional testing of all critical applications.
[ ] User acceptance testing — have actual users verify their systems work.
[ ] Backup verification — confirm all backup jobs are running on the new platform.
[ ] Monitoring verification — confirm all alerts and dashboards are operational.
[ ] Security review — verify firewall rules, access controls, and encryption are intact.
[ ] Documentation update — update all infrastructure documentation to reflect the new environment.
Phase 7: Decommission and Closure (Week 12-13)
The final phase: clean up the old environment and close the project properly.
Decommission checkpoints:
[ ] Verify all VMs have been migrated — no VMs left behind on the old platform.
[ ] Take final backup of old environment — keep for 30-90 days as insurance.
[ ] Decommission old infrastructure — power down, unplug, repurpose or sell.
[ ] Reclaim licenses — VMware licenses can often be resold or reassigned.
[ ] Final stakeholder sign-off — confirm migration is complete and accepted.
[ ] Project retrospective — what went well, what could be improved, lessons learned.
[ ] Archive migration documentation — keep for future reference.
How We Use This Checklist
Every migration gets its own copy of this checklist. We use a shared spreadsheet where each checkpoint has: the item description, the assigned owner, the target date, the completion date, and notes.
We review the checklist daily during migration. Any unchecked item gets flagged. Any delayed item gets escalated. This simple process has prevented every disaster since 2023.
One more thing: we do not mark a migration as complete until ALL checkboxes are checked. No exceptions. If a checkbox cannot be checked (because the item is not applicable), it gets documented as "N/A — reason: ..." and signed off by the project lead.
Common Mistakes This Checklist Prevents
Mistake 1: Migrating without stakeholder communication. The checklist forces you to notify every relevant party. If someone complains they were not informed, you can point to the communication log.
Mistake 2: Skipping the pilot. The checklist requires a pilot migration before production. We have never regretted spending an extra week on a pilot.
Mistake 3: Not having a rollback plan. Every migration step includes a rollback option. If something goes wrong, you can undo the migration without starting from scratch.
Mistake 4: Forgetting about backup verification. Migrating without confirming you can restore from backup is like driving without brakes. The checklist forces you to test backup and restore before migration.
Mistake 5: Incomplete validation. The checklist requires performance comparison, application testing, user acceptance testing, and security review. Skipping any of these can leave undiscovered issues.
Conclusion: Checklists Save Careers
The client we lost in 2023? We won them back two years later with a migration that went flawlessly. They told us the difference was the checklist — they could see every step, every owner, every date. It gave them confidence that we knew what we were doing.
Here is your action plan:
1. Download or copy this checklist.
2. Customize it for your environment — add or remove checkpoints as needed.
3. Share it with your team and get buy-in.
4. Use it for your next migration. Every single time.
5. Update it after each migration based on lessons learned.
Migration checklists are not exciting. They are not innovative. But they work. And in our experience, "works" beats "exciting" every time.
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 VMware migration take using this checklist?
For a mid-sized environment (50-200 VMs): 10-14 weeks. Phase 1-2 (assessment and communication): 2 weeks. Phase 3 (preparation): 2-3 weeks. Phase 4 (pilot): 1-2 weeks. Phase 5 (production migration): 4-6 weeks. Phase 6-7 (validation and decommission): 2-3 weeks.
Q: Can I use this checklist for non-VMware migrations?
Yes, the checklist is platform-agnostic. The phases and checkpoints apply to any infrastructure migration: VMware to Proxmox, VMware to cloud, physical to virtual, or even data center relocations.
Q: What if I find issues during the pilot that require timeline changes?
That is exactly what the pilot is for. If the pilot reveals significant issues, communicate the timeline impact to stakeholders immediately. It is better to delay the migration by 2 weeks than to rush into production with known issues.
Q: How do I handle stakeholders who refuse to approve downtime windows?
Present the business case: the cost of the migration (including downtime) vs the cost of not migrating (continued risk, higher licensing costs, compliance issues). If they still refuse, escalate to executive leadership with a risk assessment document.
Q: Should I keep the old infrastructure running after migration?
Yes, for 30-90 days. Keep it powered down but accessible. If something goes wrong on the new platform that requires data from the old environment, you have a fallback. After 90 days, you can safely decommission.