VMware Migration Checklist: What to Validate Before Moving Production Workloads

Changing virtualization platforms means moving an operating model, not simply converting VMDK files. Your team's runbooks, monitoring alerts, backup jobs, access roles, change procedures and escalation paths are all built around the current platform. Each of them needs a destination.

Treat the migration as a program with three outputs: a validated target platform, a sequenced workload plan, and an operations team that is ready to run production on day one. The steps below are ordered to produce those outputs in that sequence.

Build an inventory from data, not memory. Export from vCenter, cross-check against the CMDB, and interview application owners for anything the tools cannot see. The inventory should capture, at minimum:

Not every VM deserves the same migration approach. Classification lets you choose a method, a downtime window and a validation depth that fits each workload. Assign every VM to one category:

A VM that migrates successfully can still break an application if the systems it talks to are not considered. Map the dependency chain for each application before you place it in a wave: DNS, Active Directory, SQL databases, ERP platforms, internal and external APIs, firewalls, load balancers, storage paths and network segments.

Pay particular attention to hard-coded IP addresses, licensing tied to MAC addresses or hardware identifiers, and applications that expect low latency to a database. These are the issues that surface only after cut-over.

Do not migrate everything using the same downtime assumption. Agree a recovery point objective (how much data loss is acceptable) and a recovery time objective (how long the service can be unavailable) with each business owner.

These targets determine the migration method. A development VM can be powered off and converted. A business-critical database may require warm migration with incremental synchronization and a short final cut-over, or an application-level replication approach.

Before moving a single production workload, confirm that the target platform covers the operational capabilities your team relies on today — and test them, rather than reading them from a datasheet:

Start with representative but non-critical workloads. A good pilot includes at least one Windows and one Linux VM, one multi-tier application, and one workload with a real backup job. The goal is to prove the migration method, the validation checklist and the operations handover — not to move volume.

Document every surprise from the pilot. Each one is a correction to the plan before it affects production.

Sequence the remaining workloads in waves that increase in risk: pilot, then low risk, then medium risk, then business critical. Group applications with their dependencies so that tightly coupled systems move together.

Keep waves small enough to validate thoroughly and large enough to maintain momentum. Each wave should have a named owner, a scheduled window, a communication plan and a sign-off.

Every wave should have a rollback decision point — a moment, agreed in advance, when the team decides to continue or revert. Keep the source VM intact and powered off until validation is complete, and confirm that the rollback path has been tested, not just described.

A migrated VM is not a migrated service. Validate each workload against a consistent checklist before closing the wave:

Retire source VMs, hosts and licences only after each wave has been validated and has run through at least one normal business cycle. Archive the configuration, update the CMDB, and close out the old backup jobs deliberately. Early decommissioning removes your safety net; late decommissioning keeps paying for it — plan the date explicitly.