Migrating from VMware to Proxmox: process, risks, pitfalls
The cost question is answered, now it is about the how: this guide walks through a VMware-to-Proxmox migration in an SME, from the inventory via the import wizard to the typical pitfalls with Windows VMs, backup and networking. Honest about the points where it gets bumpy. As of July 2026.
Published on July 12, 2026 · Daniel Gläser
Starting point: when the migration is due
Why so many SMEs are considering the switch in 2026 is calculated elsewhere: the license costs of VMware and Proxmox compared differ by a factor of seven to eight in the typical 3-host scenario, and the Broadcom licensing changes set a hard deadline with vSphere 8 support ending on 11 October 2027. This article starts where the decision has been made in principle and the implementation is being planned.
The essential point first
An SME migration with 10 to 30 VMs is no rocket science, but no weekend project either. The Proxmox import wizard removes a lot of manual work. The real effort sits in inventory, test runs and the special cases, not in copying disks.
Step 1: inventory before the migration
Before the first VM moves, you need a complete picture of the environment. This list has proven itself 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, license servers, time services, directory services.
- Special cases: USB dongles, passed-through hardware (GPU, serial ports), VMs with licenses bound to MAC addresses or hardware IDs.
- Storage: where do the VMs live today? Important because vSAN as a source datastore is not supported directly by the import wizard (more below).
- Network: VLANs, trunk ports, firewall rules, so the Proxmox bridges are configured correctly from the start.
- Backup chain: current backup product, retention requirements, restorability of old backups after the switch.
- License 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 with ESXi 6.5 to 8.0. The flow in short:
- Add the ESXi host or vCenter as an import source in Proxmox (Datacenter, Storage, type ESXi).
- Select the VM in the source view: the wizard picks up the configuration such as CPU, RAM and network cards and proposes a mapping.
- Set the targets: which storage the disks go to (ZFS, LVM-thin, Ceph) and which bridge the network cards attach to.
- Start the import: the source VM must be stopped for this. With live import the VM already starts on Proxmox while the disks transfer in the background, which shortens the downtime considerably.
Two known limits
First: vSAN as a source datastore is not supported directly. Move VMs to an NFS or iSCSI datastore via storage vMotion beforehand, or go via a backup restore. Second: live import makes the downtime short, but not zero; the source VM has to be off when the import starts.
Step 3: handling Windows VMs correctly
Most pitfalls of an ESXi migration involve Windows. With the right order they are all avoidable:
- Install VirtIO drivers in the source VM before the move (official driver ISO in the Proxmox wiki). Without the storage driver, Windows will not boot from the VirtIO controller on Proxmox.
- Fallback alternative: attach the disk as SATA/IDE first, boot Windows, install the VirtIO drivers and then switch to VirtIO SCSI. Works, but costs one extra reboot.
- Uninstall VMware Tools after a successful move and install the QEMU guest agent.
- Carry over MAC addresses when DHCP reservations, firewall rules or software licenses depend on them.
- Plan for activation: due to the new virtual hardware, Windows or individual software may demand reactivation. Have license keys and credentials ready.
Do not copy domain controllers, rebuild them
Proven Active Directory practice: do not migrate an existing domain controller as a disk copy. Instead, set up a fresh DC on Proxmox, let it replicate and transfer the roles. That avoids USN rollback risks and you keep a working directory service throughout the migration.
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 supports Proxmox VE via the plug-in since version 12.2 (August 2024), fully including application-aware backups for Windows VMs (SQL Server, Oracle, PostgreSQL) since version 13 (September 2025). For version 13.1 Veeam has announced replication jobs, initially local only, plus instant recovery as an experimental feature (as of July 2026). Existing Veeam licenses and restore points from the old VMware environment remain usable.
- Switch to the Proxmox Backup Server: tightly integrated, with deduplication, incremental backups and verification. Subscriptions from 560 EUR net per backup server per year, unlimited clients included.
Keep the old backups
Retention obligations do not end with the hypervisor switch. Make sure old VMware restore points stay readable for the entire retention period, and actively test one restore from them after the migration.
Typical pitfalls and their solutions
| Problem | Cause | Solution |
|---|---|---|
| Windows does not boot after the import | VirtIO storage driver missing in the guest | Install drivers beforehand or attach the disk as SATA/IDE first and retrofit |
| Import from vSAN fails | vSAN is not supported directly as a source datastore | Move the VM to an NFS/iSCSI datastore first or import via backup restore |
| Server gets the wrong IP or licensing complains | New virtual NIC has a new MAC address | Manually carry over the source VM's MAC address in Proxmox |
| VM is up but has no network | VLAN tag or bridge mapping wrong | Reconcile bridge and VLAN configuration against the ESXi port groups |
| Clock jumps, logins fail | Time synchronisation after the move | Check NTP in guest and host, use the domain time source for AD members |
| Application demands reactivation | Changed virtual hardware IDs | Have license keys ready, use the vendor's hardware-change process |
What stays different after the switch
Honesty is part of it: 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 real-time 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 belongs on the table.
- 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 and simple overlays, it does not replicate complex micro-segmentation 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, having a provider who does this regularly 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 many environments want to move before vSphere 8 support ends in October 2027, and good maintenance windows are getting scarce.
Sources
- Proxmox Wiki: Migrate to Proxmox VE (offizieller Leitfaden)
- Proxmox Backup Server: offizielle Subscription-Preise
- Veeam KB4738: Build-Nummern und Release-Daten von Veeam Backup & Replication
- heise: Proxmox VE 8.2 mit Import-Assistent für ESXi-VMs (April 2024)
- Proxmox Wiki: Windows VirtIO Drivers
- Veeam Help Center: Proxmox-VE-Unterstützung (Platform Support)
- Proxmox VE Roadmap: Versionen und Neuerungen
- Proxmox VE: offizielle Subscription-Preise
- Broadcom Knowledge Base 313548: Kern-Zählung und 16-Kern-Minimum
- Computer Weekly: Support-Ende von vSphere 8 im Oktober 2027
- The Register: Gartner zu Risiken des Ausstiegs (Mai 2026)
This article is carefully researched guidance, not legal or tax advice. For binding information, please consult your tax advisor or lawyer.
Frequently asked questions
How long does migrating a single VM take?+
The raw transfer depends on disk size and network. With live import the actual interruption per VM is typically in the range of minutes, because the VM starts on Proxmox while the disks transfer in the background. Add per-VM preparation and follow-up such as drivers, testing and documentation.
Can the migration be done with zero downtime?+
No. The source VM must be stopped when the import starts, but live import shortens the interruption to the reboot plus cutover time. For most SME services a planned window of a few minutes up to an hour per VM is realistic and manageable.
What do I do with VMs on vSAN?+
vSAN is not supported directly as a source datastore by the import wizard. Move the VMs to an NFS or iSCSI datastore via storage vMotion beforehand, or go via a backup and a restore onto Proxmox.
Does Veeam keep working after the switch?+
Yes. Veeam supports Proxmox VE via the plug-in since version 12.2 and fully, including application-aware backups, since version 13 (September 2025). Old VMware restore points remain readable. For version 13.1, replication (initially local only) and experimental instant recovery are announced, as of July 2026.
Does Windows have to be reactivated after the migration?+
Possibly. Due to the changed virtual hardware, Windows activation or individual applications may demand reactivation. With license keys at hand this is a five-minute task; without them it becomes a nuisance inside the maintenance window.
What happens to our VMware licenses?+
Subscriptions run until the end of their term and are then not renewed; cancel in time. Perpetual licenses remain formally valid and can serve as rollback insurance during the migration. Afterwards, decommission the old environment in an orderly way, including deregistration and documentation.
Migration planned, but nobody should do it for the first time?
I support VMware-to-Proxmox migrations from assessment to stable operations: test cluster, move in waves, backup transition and afterwards monitoring and updates. From Chemnitz for SMEs in Saxony and across Germany.
Daniel Gläser
Owner of Gläser IT-Solutions, Chemnitz
I build software and run IT infrastructure for small and medium businesses, from the first analysis to day-to-day operations. Everything here comes from real projects and is backed by sources.
