How to Migrate from VMware to Proxmox with Zero Downtime

Why migrate from VMware to Proxmox in 2026

The change in VMware's commercial model under Broadcom has been the catalyst, but the reasons to migrate go beyond the immediate cost. Perpetual vSphere licenses have disappeared: only mandatory annual subscriptions remain. Licensing has shifted from per-socket to per-core, which multiplies the cost on modern servers with 32, 64 or more core CPUs. Additionally, products that were previously sold individually (vSphere, vSAN, NSX) are now only available as part of mandatory bundles such as VMware Cloud Foundation (VCF) or vSphere Foundation (vSF).

Proxmox VE, built on KVM and LXC, with integrated Ceph and AGPL v3 licensing, offers an enterprise-grade open source alternative. Proxmox commercial support subscriptions range from EUR 110 to EUR 1,020/year per socket, a fraction of VMware's cost. But beyond savings, Proxmox delivers real technical advantages: native LXC containers, distributed Ceph storage at no additional license cost, a full REST API for automation and a rapidly growing community. For a detailed comparison between both platforms, check our article Proxmox vs VMware.

Migration planning

A successful migration begins long before touching the first VM. The planning phase is what determines whether the project completes without incidents or becomes an operational nightmare. The first step is to perform a comprehensive inventory of all VMs in the VMware environment: operating system, version, allocated resources (vCPU, RAM, disk), disk type (thick/thin provisioned), networking (VLANs, static IPs, firewall rules), service dependencies and criticality level.

With the complete inventory, VMs must be classified into migration groups by priority order. Development and staging VMs are migrated first as a proof of concept. Then non-critical internal applications. Next, lower-impact production workloads. And finally, critical services (databases, ERP, AD/LDAP). Each group must have a documented rollback plan: if something fails during a VM's migration, it must be possible to revert to the previous state on VMware within minutes.

It is essential to deploy a testing lab with Proxmox before touching production. Install a Proxmox cluster with at least 2-3 nodes, configure the network identically to the production environment (VLANs, bridges, firewall) and migrate a representative subset of VMs. This lab will serve to validate each migration method, fine-tune VirtIO drivers and establish real conversion times. The official Proxmox documentation on migration of servers to Proxmox VE is an excellent starting point.

Migration methods: four paths to Proxmox

There is no single migration method. Depending on the size of the environment, the available maintenance window and the tools you already have, you can choose between four main approaches. Each has its advantages and optimal use cases.

Step by step: migration with qemu-img

The most direct and universally applicable method is disk conversion with qemu-img. This approach works with any VM regardless of the operating system and requires no additional software beyond the tools included in Proxmox. The complete process is as follows:

1. Export the VM from VMware. Shut down the VM cleanly (guest shutdown). In vCenter, right-click the VM and select "Export OVF Template". This will generate an .ovf file (descriptor), one or more .vmdk files (disks) and an .mf file (checksums). Alternatively, you can copy the .vmdk files directly from the ESXi datastore via SCP or SFTP.

2. Transfer the files to the Proxmox node. Use SCP, rsync or shared NFS storage to move the VMDKs to the Proxmox node. If the disk is thick provisioned, the file size will be the total allocated amount; if thin, only the used space. For large disks (500+ GB), rsync with the --progress flag lets you monitor the transfer.

3. Convert the VMDK disk to QCOW2 format. On the Proxmox node, run the following command:

For large disks, add the -p flag to see progress. If you prefer raw format for maximum performance on local storage, replace qcow2 with raw. For Ceph storage, raw is the recommended option.

4. Create the VM in Proxmox. From the Proxmox web interface, create a new VM with the same resources (vCPU, RAM) as it had in VMware. Select the correct BIOS type: if the original VM used UEFI, select OVMF (UEFI); if it used legacy BIOS, select SeaBIOS. Do not assign a disk at this step; we will import it manually.

5. Import the converted disk. Use the qm importdisk command to attach the disk to the VM:

Where 100 is the VM ID and local-lvm is the target storage. Then, in the web interface, go to the VM's Hardware section, select the "Unused" disk and click "Edit" to assign it as a SCSI or VirtIO Block disk. Configure the boot order so this disk is first.

6. Install VirtIO drivers (Windows only). For Windows VMs, mount the VirtIO driver ISO (available from the Fedora/Red Hat repository) as an additional CD-ROM. Boot the VM and, from Device Manager, update the disk, network and balloon drivers. This is critical for performance: without VirtIO, the VM will use emulated IDE/e1000 drivers that are significantly slower.

7. Verify and validate. Confirm the VM boots correctly, services respond, network connectivity works and disk performance meets expectations. Run the application-specific tests for your environment.

Step by step: migration with Veeam

If you already have Veeam Backup & Replication in your environment, you can leverage its V2V (Virtual-to-Virtual) restore capability to migrate VMs to Proxmox with minimal downtime. Since version 12, Veeam supports Proxmox VE as a native restore target, which greatly simplifies the process.

The workflow is: perform a full backup of the VM in VMware with Veeam, add the Proxmox cluster as a managed server in the Veeam console, and execute a "Restore to Proxmox VE". Veeam handles the disk format conversion (VMDK to KVM-compatible format), the VM creation in Proxmox and VirtIO driver injection automatically. The downtime is limited to the time needed for the last incremental backup and the network cutover (typically less than 5 minutes for most VMs).

The key advantage of this method is that Veeam automatically handles virtual hardware compatibility, disk controller conversion and driver injection, significantly reducing the risk of manual errors. Additionally, since you are working from an existing backup, you always have a restore point to fall back to in VMware if something does not go as planned.

VirtIO drivers and post-migration optimization

VirtIO drivers are the KVM equivalent of VMware Tools + PVSCSI + VMXNET3. They are paravirtualized drivers that allow the VM to communicate directly with the hypervisor without the hardware emulation layer, achieving near-native performance. It is absolutely essential to install them on all migrated VMs to obtain the expected performance.

On Linux VMs, VirtIO drivers have been included in the kernel for years; simply selecting the VirtIO device type in the VM configuration is sufficient. On Windows VMs, download the virtio-win ISO from the Fedora repository, mount it as a CD-ROM and run the installer. For a cleaner migration, you can install VirtIO drivers on the Windows VM before the migration while it is still running on VMware, so that when it boots on Proxmox the drivers are already available.

Testing and pre-cutover validation

Before redirecting production traffic to the VMs on Proxmox, it is essential to validate that everything works correctly. Testing must cover multiple layers: operating system, application, network and performance. We have developed a checklist based on our real migrations that covers the critical points.

• check_circle Clean boot: the VM starts without console log errors, the OS loads completely and services start automatically
• check_circle Network connectivity: ping to gateway, DNS resolution, access to external services, correct firewall rules
• check_circle Performance baseline: compare disk IOPS (fio), network throughput (iperf3) and CPU usage against VMware reference values
• check_circle Applications: all applications respond correctly, databases are accessible, logs show no errors
• check_circle Backup: Proxmox Backup Server or Veeam can back up the migrated VM correctly
• check_circle DNS and cutover: prepare DNS changes with low TTL (60-300s) to minimize propagation time when redirecting traffic

For the final production cutover, we recommend a DNS-based cutover strategy: reduce the DNS record TTL to 60 seconds 24-48 hours in advance, perform the cutover by changing the A/CNAME record to the new IP on Proxmox, and keep the original VM in VMware powered off but intact for at least 72 hours as a rollback plan. If possible, schedule the cutover during a low-traffic window (night, weekend).

EasyDataHost case study: real migration with 0 downtime

At EasyDataHost we have completed VMware to Proxmox migrations for clients with 45+ production VMs, including SQL Server database servers, Active Directory domain controllers, high-concurrency web applications and file services with tens of TB of data. The result: 0 minutes of downtime perceived by end users and 60% savings in licensing costs from the first year.

Conclusion

Migrating from VMware to Proxmox is not a leap into the unknown. It is a well-documented process, with mature tools (qemu-img, Veeam V2V, importovf) and a growing community of companies that have already completed it successfully. The key lies in planning: a comprehensive inventory, a testing lab, phased migrations and a rollback plan for each step. With this approach, the actual downtime for end users can be literally zero.

The economic savings are undeniable: 60% to 90% in licensing costs compared to VMware. But beyond cost, migrating to Proxmox delivers real technical advantages: native LXC containers, integrated Ceph, a full REST API and the peace of mind of not depending on a single vendor's commercial decisions. In a world where Broadcom has demonstrated it can change the rules overnight, technological sovereignty has a strategic value that goes beyond the euros saved.

If you are evaluating a VMware to Proxmox migration, our engineering team can help with a personalized analysis of your environment, a detailed migration plan and turnkey project execution. Get in touch and we will analyze your case at no obligation.