If you're searching for how to migrate VMware to Proxmox, you're probably already past the "should we?" question — Broadcom's licensing changes made that decision for a lot of Australian IT teams. What's left is the practical part: what to check before you start, what the built-in import tool actually does for you, and where the real work still happens by hand. This is a checklist, not a sales pitch — it covers the steps in order, with the traps that catch people out along the way. This guide is aimed at IT teams and MSPs running production VMware estates — a handful of hosts up to a small cluster — not homelab experimenters, who already have plenty of community write-ups to work from.
Start your VMware to Proxmox migration with an inventory and licensing audit
Before touching a single VM, get an honest picture of what you're moving. Pull a full inventory from vCenter or the ESXi host directly: every VM, its allocated vCPU and RAM, disk size and format, network adapters, and — critically — anything using a feature Proxmox handles differently or not at all. That means flagging VMs with vSphere-specific add-ons (vMotion-dependent DRS rules, Storage vMotion schedules, vSAN-backed disks) and anything running a vTPM, which needs separate handling (more on that below).
Also check guest OS compatibility while you're at it. Proxmox VE runs on the same KVM virtualisation extensions (Intel VT-x / AMD-V) that ESXi uses, so hardware compatibility is rarely the blocker people expect — the exception is PCIe passthrough for GPUs or specialised cards, which needs IOMMU support confirmed in the BIOS on the target hosts before you commit to a hardware refresh. Windows and mainstream Linux guests are well supported; older or vendor-specific guest OS versions are worth a quick check against the Proxmox wiki's guest OS notes before migration day.
While you're auditing, check your current VMware licence position against what a renewal would actually cost. Broadcom's vSphere Foundation is priced at roughly USD 135 per core per year, with a 16-core-per-socket minimum — so even a modest 8-core CPU is billed as 16 cores, putting the effective floor at around USD 2,160 per socket per year (Redress Compliance). That number is usually what triggers the migration project in the first place, and it's worth having in writing before you present the business case internally.
If you're already running Proxmox VE 8, note that it reaches end of life on 31 August 2026 — no more security patches after that date (endoflife.date). New deployments should start straight on Proxmox VE 9.2, the current release, built on Debian 13 "Trixie" (Proxmox press release).
The import wizard: what it handles, and what it doesn't
Proxmox VE has shipped a built-in ESXi Import Wizard since version 8.2, and by 9.x it's the default first attempt for most migrations rather than a niche tool. It connects directly to an ESXi host or vCenter, no export step required, and supports source ESXi versions from 6.5 up to 8.0.
For each VM, the wizard asks how you want the resulting disks stored: qcow2 (thin-provisioned, supports snapshots), raw (best performance, no extra overhead), or the native ZFS zvol format if your target storage is ZFS. It also handles network mapping between the source vSwitches and your Proxmox bridges, which removes a lot of the manual guesswork that used to make migrations error-prone.
It has real limits, though, and they're worth knowing before you schedule a migration window rather than discovering them mid-cutover:
- vTPM state cannot be migrated. If a VM has a virtual TPM attached — common on newer Windows Server and Windows 11 builds that enforce it — the wizard either fails or drops the vTPM entirely. Plan to disable or remove vTPM before migrating, and re-provision it on the Proxmox side if the workload genuinely needs one.
- VMs backed by vSAN storage won't import directly. The usual workaround is to migrate the VM's disks off vSAN to a standard datastore first, then run the import from there.
- Encrypted VM disks can't be imported as-is. Remove VM encryption before starting.
- Datastore names with special characters (particularly
+) can break the import. Rename the datastore if you hit this. - VMs with existing snapshots import significantly slower, and it's good practice to consolidate or remove snapshots beforehand regardless of which migration path you use.
None of these are dealbreakers, but they're exactly the kind of thing that turns a planned two-hour maintenance window into an all-nighter if you find out about them live.
Storage and networking mapping
Beyond what the wizard handles automatically, plan your target storage layout before you start rather than accepting whatever the default offers. If you're moving to Ceph or ZFS for software-defined shared storage, decide on your redundancy level and disk layout ahead of time — retrofitting that after VMs have already landed is far more disruptive than getting it right up front. See our Proxmox vs VMware comparison for how the storage and clustering models differ.
On the network side, map every vSwitch and port group to an equivalent Proxmox Linux bridge or VLAN-aware bridge before the cutover, and confirm VLAN tagging matches on both sides. A mismatched VLAN tag is one of the most common "the VM imported fine but nothing can reach it" support calls after a migration — check this explicitly rather than assuming the wizard's mapping matched your intent.
The choice between Ceph and ZFS comes down to scale and node count. Ceph needs at least three nodes to make sense and gives you distributed, self-healing storage that survives a full node failure — the right call for a cluster. ZFS is the simpler, proven choice for a single host or a two-node setup, with the trade-off that it doesn't natively distribute storage across nodes the way Ceph does. Don't default to Ceph just because it's the more talked-about option if you're only running two or three hosts; ZFS with regular scrubs and a solid backup plan covers that case with far less operational overhead.
Test before the real cutover
Run the import against one low-priority VM first, not your busiest file server. After it lands, confirm the guest boots cleanly, the network adapter came up on the right VLAN, and disk performance is where you expect it — a raw-format disk on fast local storage should feel identical to the source; qcow2 on spinning disk will not. Keep the source VM powered off rather than deleted during this test window, so you have an instant rollback if something's wrong, and only decommission it once the imported copy has been running cleanly for a few days. For anything client-facing, do this test pass during a low-traffic period so a bad first attempt doesn't become an outage.
Backup strategy on the other side
Don't leave backup as an afterthought once VMs have landed on Proxmox — decide on it before cutover so day one is already protected. Proxmox Backup Server (PBS) is the native option, tightly integrated with PVE, with built-in deduplication and encryption. NAKIVO is the other common choice for shops that want a single backup platform spanning Proxmox alongside VMware (during a phased migration), Hyper-V or physical servers, with broader application-aware recovery for workloads like SQL Server and Active Directory. We've covered the detailed trade-offs in our Proxmox backup: PBS vs NAKIVO comparison — worth reading in full if you're deciding between the two, or doing both in parallel during the transition.
When to get help
A single-host lab migration is a weekend project. A production cluster running line-of-business VMs, with storage vMotion dependencies, vTPM-enabled workloads and a change freeze window measured in hours, is a different exercise. If your environment includes any of the limitations above at scale — vSAN-backed storage, widespread vTPM use, or VMs too large to safely re-import if something goes wrong — it's worth getting a second set of eyes on the migration plan before you commit a maintenance window. Cloud Ready Solutions distributes both Proxmox and NAKIVO in Australia and works with MSPs and IT teams planning VMware exits; get in touch if you want the plan checked before you run it.
For the broader context on why this migration is happening across the market right now, see our 2026 VMware alternatives shortlist.