Proxmox vs. VMware: Migration from a Real Project

Since Broadcom’s VMware acquisition, migration is no longer theoretical — for many SMBs it’s a hard necessity. Over the last 18 months we’ve delivered several migration projects; one of them serves here as an anonymized case study. The customer: a manufacturing SMB, about 80 employees, vSphere 7.0 with two ESXi hosts and one vCenter, classic FC SAN storage. The workload to migrate: 30 production VMs plus a few test systems.

What this article delivers is not “Proxmox beats VMware” — but an honest step-by-step record. We give wallclock times as ballpark figures only, not invented stopwatch numbers.

Starting point

• Hardware: 2× Dell PowerEdge R740 (2× Xeon Gold 6230, 384 GB RAM each), 1× Dell EMC Unity 380F (FC SAN, all-NVMe)
• vSphere: 7.0 U3, classic 3-license box (two hosts plus vCenter)
• VMs: 30 production, of which 6 Linux servers (web services, databases), 18 Windows servers (file servers, AD, Exchange, ERP), 6 Windows clients (RDP hosts)
• Data volume: about 14 TB used, 22 TB provisioned
• Backup: Veeam B&R 12 on a separate Synology NAS

The migration trigger: Broadcom’s license renewal would have meant a multi-x increase over the previous cost — coupled with mandatory migration to VMware Cloud Foundation. For an 80-person company that was simply disproportionate.

Target architecture

We chose the following setup with the customer:

• 3× Proxmox VE 9.0 nodes on existing Dell hardware (the two ex-ESXi hosts plus an additional node from the demo pool)
• Cluster with Corosync quorum, HA enabled
• Storage: keep the existing Unity 380F as is under LVM-thin via FC, in parallel build a new TrueNAS R30 as ZFS storage for future workloads
• Proxmox Backup Server on separate hardware, replication to the Synology NAS as a second rail
• PVE network: redundant 25 GbE, separate VLAN for Corosync, separate one for storage

This was deliberately a conservative migration: no concurrent storage swap, no new backup tool, no VM restructuring. One thing at a time.

Phase 1: inventory

A migration doesn’t fail because of Proxmox — it fails on undiscovered dependencies. Before any other activity we did a very detailed inventory:

Aspect	Captured
VM list	Name, OS, vCPU, RAM, disk size, IP, MAC, VLAN
Snapshots	Count, age, purpose (often “forgotten since 2022”)
VM Tools	VMware Tools installed? Version?
Hardware version	VMX compat level (typically 14–17)
Licenses	Per VM: which software, which license model (often MAC-bound!)
Backup status	Last successful backup, restore test yes/no
Dependencies	DNS, AD, database dependencies

This step alone cost roughly two working days — and saved us from several nasty surprises. Three of the 30 VMs had licenses bound to the VMware UUID and would have been flagged illegitimate on restore tests. One VM had 14 forgotten snapshots from a 2022 update attempt.

Phase 2: lab test

Before any production data moves, we walked through the whole procedure on a third Proxmox node running in parallel to production with two non-critical test VMs:

1. Check current Veeam backup of the test VMs
2. Method A: Veeam Instant Recovery to Proxmox — Veeam Backup & Replication 12.2+ supports PVE as recovery target
3. Method B: pve-vmware-import — tool from the PVE package, imports directly from ESXi
4. Method C: OVF export → qm importovf — the classic manual path

Result: Method A was the fastest and most reliable, because Veeam’s consistency seal is preserved and the restore test doubles as a functional test. Method B works for simple VMs but had trouble mapping multiple disk controllers. Method C is universal but takes noticeably more manual work per VM.

Phase 3: pilot

We picked five low-priority VMs as the pilot — all Linux, all with established backup hygiene, all without hard SLAs:

• 2× internal web apps
• 1× test database
• 1× CI/build server
• 1× internal monitoring (Grafana)

Migration during a Saturday morning maintenance window. Procedure:

1. Final Veeam backup
2. VM shut down in vSphere
3. Veeam Instant Recovery to the Proxmox node, new disk storage on LVM-thin
4. Uninstall VMware Tools, install QEMU Guest Agent
5. Set PVE network bridge to the correct VLAN
6. Boot up, functional test
7. DNS/DHCP: register new MAC if needed

Six hours later all five VMs were cleanly live. Over the following week we watched for issues — no critical problems. One detail surfaced later: the CI server’s average build time had crept up slightly after migration. Cause: ZFS compression on the new TrueNAS was not yet active, fixed afterward.

Phase 4: main migration

The remaining 25 VMs were split across two weekends, grouped by dependency:

Weekend 1: infrastructure VMs

• Active Directory (both DCs, one at a time)
• DNS/DHCP, file cluster, print server
• Backup proxy VM (self-referential step, plan B discussed upfront)

Weekend 2: application VMs

• ERP, Exchange, RDP hosts, database servers

Per weekend we scheduled a window from Friday evening to Sunday evening and kept a clear cutover order: platform services first (AD, DNS), then dependent applications. Ballpark per VM: 30–90 minutes wallclock depending on size and restore speed. We spare you exact stopwatch numbers — they don’t transfer across setups.

Between weekends 1 and 2 the environment ran hybrid: some services on Proxmox, others still on VMware. That works for two or three days, not weeks — complexity otherwise becomes untenable.

Phase 5: cutover and decommissioning

After the second weekend:

1. Final full Veeam backup of the old environment as a disaster fallback
2. Keep vSphere “cold” for two weeks — hosts shut down, vCenter offline, but recoverable
3. After two weeks: archive vSphere data, reinstall hosts (two repurposed as PVE nodes, one kept as cold spare)
4. Licenses: Broadcom contract terminated effective on the agreed date

Pitfalls (the honest list)

Remove VMware Tools completely

On three Windows VMs we still had registry remnants of VMware Tools after formal uninstall. Symptom: occasional one-second logon hangs after reboot. Fix: run VMware’s Tools Cleaner script before the restore procedure.

MAC addresses change

Migration assigns each VM a new MAC. That’s usually irrelevant — except for:

• DHCP reservations that must be updated
• MAC-bound software licenses that need regeneration
• Network bridge filters that need rebuilding
• Smart hosts and SMTP rules filtering on MAC (rare, but happens)

We recommend setting the MAC explicitly — Proxmox supports it per interface. If you want to keep the old MAC, copy it from the vSphere inventory.

Storage latency tuning

The old vSphere had aggressive Storage I/O Control (SIOC) configured. Proxmox runs by default with less throttling. Effect: right after migration, an I/O-heavy VM feels faster — at the cost of starving its peers. Fix: per-VM I/O limits in PVE (qm set <id> --scsi0 ...,iops_rd=...,iops_wr=...).

TPM disks

A Windows 11 RDP VM had a virtual TPM. Migration works, but TPM disk snapshots were unreliable until PVE 9.1. Workaround: put the TPM disk on separate storage (NFS/SMB qcow2), keep main disks on LVM-thin. PVE 9.1 fixed the snapshot bug for qcow2 TPM disks — the iSCSI bug is still open.

ESXi hardware version

One VM ran VMX version 17 with virtual features (vPMU, GPU reservation) that don’t map 1:1 to Proxmox. Had to be handled separately — ended up with qm set using a custom CPU type and without the exotic features.

Backup locations

Veeam B&R writes slightly different metadata in PVE mode. We initially repointed old backup jobs to new targets — which would have complicated retroactive restores from the old Veeam library. Better practice: keep the old library read-only, create the new one in parallel, let retention age out gradually.

Lessons

What we take from this project:

1. Inventory is half the migration. Cutting corners here costs double in the maintenance window.
2. Pilot with five non-critical VMs saves nerves. Don’t start with the AD cluster.
3. Veeam Instant Recovery to PVE is by far the fastest path when Veeam is already in place.
4. Remove VMware Tools cleanly, or Windows will misbehave.
5. Don’t change storage at the same time. Hypervisor first, then storage, then backup. Never all in one shot.
6. Two-week fallback window is cheap insurance — keep hosts cold instead of reinstalling immediately.

If you’re facing a comparable project, we’re happy to advise — with the same honest risk picture documented here. A 30-VM migration is, with proper preparation, doable across three weekends including the pilot, without uncontrolled risk.

Related articles:

• From VMware to Proxmox: structured switch
• VMware licensing changes: Proxmox as alternative
• Proxmox VE 9.2 release
• Official TrueNAS Proxmox plugin: NVMe/TCP

Sources

• pve-vmware-import documentation
• Veeam Backup & Replication 12.2 release notes (Proxmox support)
• VMware Tools removal (KB 2015638)
• Proxmox VE Storage Best Practices