Who this is for
This guide is for infrastructure and application teams that run production workloads on VMware vSphere and need to move some or all of those virtual machines to a cloud provider. It fits a small IT team with a few dozen VMs and a larger platform group with hundreds. The checklist assumes you control vCenter and can get time from the application owners.
Use Checklist: migrate VMware virtual machines to the cloud when you plan a lift and shift, a phased replatform, or a data center exit. It focuses on virtual machine mechanics: inventory, virtual hardware, networking, identity, cutover, and cleanup. Database and file server moves have their own checklists and need extra work beyond this one.
Readers should know vSphere basics: clusters, hosts, datastores, port groups, snapshots, and VMware Tools. If you only consume VMs and do not administer vCenter, bring the platform engineer who does. The work goes faster when one person owns the migration plan and one person owns each application.
Before you begin
Start with a written scope and a freeze date. Decide whether you are moving to native cloud virtual machines, a VMware based cloud, or a mix. Native cloud VMs often need a new machine image, different drivers, and guest OS changes. A VMware based cloud can keep more of the existing operations model but may limit managed services and elasticity. Write the reason for each choice, not just the target.
Collect facts before you design. Export a vCenter inventory and a performance report for at least a full month, ideally a quarter. Capture virtual hardware version, VMware Tools version, disk format, snapshots, and any independent disks or raw device mappings. Check guest OS support and application support against the target platform. A VM that boots on vSphere may fail on different virtual network cards or storage drivers.
Check licensing and support early. Confirm how Windows Server, Linux subscriptions, and any software tied to host CPU or VMware will be licensed in the cloud. Read the vendor terms or ask the account team. Do not assume a license that works on an owned host can be moved. Also check backup, monitoring, and security agents for cloud compatibility.
The checklist
The order matters. Discovery and design cost less than a failed cutover. Work in waves, with a pilot first, then low risk systems, then business critical systems. Keep each wave small enough to test and reverse.
The bullets below are the minimum set for a controlled migration. Assign an owner to each item and record the evidence in one shared place. A spreadsheet is fine at the start, but move the final state into your service management tool.
Do not skip the rebuild option. A clean rebuild on a current OS image often removes years of drift, but it costs application work. Lift and shift is faster, yet it carries old drivers, unused software, and oversized disks into the new environment. Mark each VM as move, rebuild, replace with a managed service, or retire. That decision often matters more than sizing tweaks.
- Export a complete vCenter inventory with power state, guest OS, virtual hardware version, VMware Tools status, vCPU, memory, disk format, and datastore.
- Tag every VM by application, owner, environment, criticality, and recovery objective, then get written owner signoff.
- Map network dependencies: VLANs, port groups, static IPs, MAC address reservations, DNS records, DHCP reservations, firewall rules, load balancer members, and MTU settings.
- Record storage and placement details: VMDK sizes, thin or thick provisioning, independent disks, raw device mappings, snapshots, shared datastores, and host affinity rules.
- Confirm guest OS and application support for the target VM series or hypervisor before you commit to a size.
- Verify licensing and support terms for the guest OS, middleware, backup agents, and any software tied to VMware or host hardware.
- Build the target network and identity foundation first: subnets, routes, security groups, DNS forwarders, domain join, and time sync.
- Pick a migration method per VM, such as cold export, warm replication, backup and restore, or rebuild, and write down why.
- Right size from measured CPU, memory, disk IOPS, and network use over a full business cycle, and review reservations, limits, and shares before you map them to cloud quotas.
- Run a pilot with one low risk VM and one representative multi tier application, then compare boot time, latency, throughput, and backup.
- Write a per VM cutover runbook with the freeze window, lowered DNS TTLs, validation steps, rollback trigger, and named owner.
- Test a full restore of the cloud backup before cutover, and confirm that the backup agent works on the new virtual hardware.
- Schedule decommission after a stability window, remove old DNS and monitoring records, and archive the final image per retention policy.
What good looks like
A good migration has no mystery VMs. Every VM in the cloud maps to an owner, an application, a backup policy, a monitoring check, and a cost tag. The old vCenter inventory matches the new cloud inventory, with an explicit list of retired VMs. Network flows are documented and tested after cutover, not just before.
Performance is stable after the move. CPU ready time, memory ballooning, and disk latency should be checked in the new platform, because the metrics have different names and different meanings. Applications should pass the same smoke tests that ran on vSphere. Backup jobs should complete on schedule, and a restore test should pass.
Cleanup is part of the project. Old snapshots, orphaned disks, stale DNS records, unused public IPs, and idle vSphere hosts all cost money and create risk. Decommission in a planned window after the business owner signs off. Keep the final export or backup until the retention period ends.
What to do next
Pick a pilot and set a date. Build the inventory, choose the target platform, and write the first two runbooks. That small start will show you the real blockers: a legacy OS, a hard coded IP, a license gap, or an application owner who cannot give a freeze window.
If the scope is unclear, run a short discovery before you buy cloud capacity. Cloudverg offers the Discovery and roadmap sprint, a fixed price $9,500 engagement that runs two weeks and starts within 10 business days. It covers stakeholder interviews, current state review, target architecture, a phased roadmap, and a fixed price quote for phase one. The fee is credited to phase one if you start within 60 days. Compare that with doing the inventory and design in house, and pick the option that fits your team.
After the pilot, review the results with finance and operations. Confirm the run cost, the backup policy, and the support model. Then schedule the next wave. Do not move every VM at once just because the first one worked.
Frequently asked questions
How long does it take to migrate VMware VMs to the cloud?
A pilot can finish in days. A full estate usually moves in waves over weeks or months, driven by application freezes, data transfer size, and testing. The inventory and dependency mapping often take longer than the actual copy.
Can I lift and shift VMware VMs to the cloud?
Yes, many providers import OVF or OVA packages and VMDK disks, and some offer a VMware based cloud. Expect driver, network, and licensing work. A lift and shift is fastest for legacy apps but carries old configuration into the new platform.
Do I need to change IP addresses during a VMware migration?
Not always. Some target networks let you keep private IP ranges, but you must plan routes, DNS, and firewall rules. If you change addresses, update hard coded settings, certificates, and monitoring before cutover.