Migrating from VMware to Proxmox: process, risks, pitfalls

Starting point: when the migration is due

Why so many SMEs are considering the switch in 2026 I have calculated elsewhere: the licence costs of VMware and Proxmox compared differ by a factor of about six against VMware Cloud Foundation in the typical 3-host scenario. On top of that, the Broadcom licensing changes set a hard deadline: vSphere 8 support ends on 11 October 2027. This article starts where the decision has been made in principle and the implementation is being planned.

Step 1: inventory before the migration

Before the first VM moves, you need a complete picture of the environment. This list has worked well in practice:

• VM inventory: all VMs with operating system, size, CPU/RAM and criticality. Now is the moment to identify legacy systems that do not need to move at all.
• Dependencies: who talks to whom? Ordering of application and database servers, licence servers, time services, directory services.
• Special cases: USB dongles, passed-through hardware (GPU, serial ports), VMs with licences bound to MAC addresses or hardware IDs, VMs with a virtual TPM and BitLocker (back up the recovery keys).
• Storage: where do the VMs live today? Important because the import wizard cannot import VMs on vSAN directly and encrypted disks have to be decrypted first (more below).
• Network: VLANs, trunk ports, firewall rules and the guests’ network configuration, so the Proxmox bridges are configured correctly from the start.
• Backup chain: current backup product, retention requirements, restorability of old backups after the switch.
• Licence dates: when does the VMware subscription or support expire? That date drives the schedule backwards.

Step 2: the Proxmox import wizard for ESXi

Since version 8.2 (April 2024) Proxmox VE ships an integrated import wizard, tested by Proxmox with ESXi 6.5 to 8.0. It reads the source VMs exclusively through public ESXi interfaces and therefore does not depend on VMware’s VDDK developer kit, whose public download Broadcom withdrew at the end of August 2026. The flow in short:

• Add the ESXi host as an import source in Proxmox (Datacenter, Storage, Add, type ESXi). A vCenter works too, but according to Proxmox it is much slower, so point the wizard at the host directly.
• Select the VM in the source view: the wizard picks up the configuration such as CPU, RAM, disks and network cards and proposes a mapping.
• Set the targets: which storage the disks go to (for example ZFS, LVM-thin or Ceph), which bridge the network cards attach to, and for Windows VMs set the disk bus to SATA instead of SCSI (see step 3).
• Start the import: shut down the source VM first. With live import the VM already starts on Proxmox while the disks transfer in the background, which shortens the downtime considerably.

Step 3: handling Windows VMs correctly

Most pitfalls of an ESXi migration involve Windows. With the right order they are all avoidable:

• During the import, set the boot disk of Windows VMs to SATA instead of the proposed SCSI, as the Proxmox wiki recommends. Without VirtIO drivers, Windows will not boot from the VirtIO SCSI controller.
• After the first boot, install the VirtIO drivers (driver ISO from the virtio-win project, available via the Proxmox wiki) and then switch the disk to VirtIO SCSI. Alternatively the drivers can be installed in the source VM beforehand; a test migration should show whether that works cleanly.
• Uninstall VMware Tools before the move, because they are often hard to remove afterwards, and install the QEMU guest agent on Proxmox.
• Carry over MAC addresses when DHCP reservations, firewall rules or software licences depend on them.
• Plan for activation: due to the new virtual hardware, Windows or individual software may demand reactivation. Have licence keys and credentials ready.

Step 4: planning downtime realistically

• Order: first a non-critical test VM, then infrastructure services, then the business applications. Each wave validates the process for the next.
• Maintenance windows per VM instead of a big bang: live import typically pushes the interruption per VM down to minutes, but transferring large disks still takes its time over the network. 10-gigabit links between old and new environment pay off here.
• Rollback path: the source VM on ESXi initially stays untouched after the import. Delete it only once the new VM has run cleanly in production for a few days and is backed up.
• Plan buffers: experience says individual VMs need a second attempt, usually due to drivers or activation. That is normal and no reason to panic if the schedule has slack.

Step 5: rebuilding backup

The backup question comes down to two good paths:

• Stay with Veeam: Veeam Backup & Replication has supported Proxmox VE via a plug-in since version 12.2 (August 2024), and application-consistent backups of Windows and Linux VMs, for example running SQL Server, Oracle or PostgreSQL, since version 13 (September 2025). Version 13.1 (July 2026) adds replication between Proxmox hosts and instant recovery, the latter with experimental support for now. Licensing is per protected Proxmox VM via the Veeam Universal License, so check the licences you already have. Restore points from the old VMware environment remain usable and can also be restored to Proxmox.
• Switch to the Proxmox Backup Server: tightly integrated, with deduplication, incremental backups and verification. Subscriptions start at 560 EUR net per server per year (Community, intended by the vendor for non-production use), and at 1,120 EUR (Basic) for production, each with unlimited clients.

Typical pitfalls and their solutions

What stays different after the switch

To be fair: Proxmox does not replace vSphere in every detail, and Gartner rightly warns against underestimating the change. The most relevant everyday differences:

• Load balancing: since version 9.2 (May 2026) Proxmox ships an integrated dynamic load balancer that automatically live-migrates HA-managed guests based on current utilisation. It only covers HA-managed guests and is considerably younger than VMware DRS, whose maturity and feature depth it does not yet match. In small clusters that is rarely a real problem, but it should be part of the discussion.
• vSAN becomes Ceph or ZFS: Ceph shines from three nodes upward; for smaller setups, ZFS with replication or classic shared storage is the more pragmatic route.
• No NSX counterpart: the Proxmox SDN covers VLANs as well as VXLAN and EVPN overlays, plus the built-in firewall. It does not replicate complex micro-segmentation and central security management like NSX.
• Check the ecosystem: monitoring agents, storage integrations and specialised software that talk directly to vCenter need a Proxmox counterpart or a different approach.

Do it yourself or get support?

With solid Linux skills in-house, the migration is very doable on your own; the Proxmox wiki is excellent. Without those skills, with tight maintenance windows, or from roughly ten production VMs upward, support from a provider with Proxmox and VMware experience pays off. That is exactly what I offer as part of my IT infrastructure services: assessment, test migration, the move in waves, and ongoing operations with monitoring, updates and backup checks afterwards. Above all: start early, because little more than a year remains until vSphere 8 support ends in October 2027, and maintenance windows cannot be compressed at will.