What Actually Transfers from vSphere to Proxmox, and What Does Not

Every platform migration has two budgets. One is the licensing arithmetic that got the project approved, and it is usually the one people can recite. The other is the retraining cost, which nobody estimates and everybody pays. For a team moving from vSphere to Proxmox VE, most of that second budget is spent discovering which of their instincts still apply. Why so many teams are making the move is a licensing story; this one is about the day after the decision.

The good news is that more transfers than the interface suggests. The bad news is concentrated in three specific places.

The concept map

Virtualization primitives are more portable than vendor documentation implies. If you understand why a feature exists, you can usually find its counterpart.

vSphere	Proxmox VE	Notes
vCenter Server	The cluster itself	No separate management appliance. Every node serves the same web interface.
vSphere HA	Proxmox HA stack	Same idea, restart guests elsewhere when a node fails.
vMotion	Live migration	Works, including between nodes with differing CPUs if you set the model carefully.
DRS	Dynamic Load Balancer	New. See below.
VMFS or vSAN	ZFS, Ceph, LVM, directory	The largest conceptual jump in the whole migration.
Distributed switch	SDN	WireGuard and BGP arrived recently.
Templates and linked clones	Templates and linked clones	Nearly the same, including the terminology.
Resource pools	Pools	Grouping and permissions, similar in spirit.
No equivalent	LXC containers	Proxmox runs system containers natively alongside VMs.

That last row is the one people underestimate. A meaningful fraction of workloads that live in small virtual machines on vSphere are better served by containers on Proxmox, and consolidating them is where a lot of the density gain actually comes from.

The DRS-shaped hole, recently filled

For years the strongest technical objection to Proxmox in a serious environment was the absence of anything resembling the Distributed Resource Scheduler. Proxmox had HA, so a failed node did not take workloads down. What it lacked was continuous rebalancing: the thing that quietly moves guests around so no host ends up carrying the cluster.

Proxmox VE 9.2, released on 21 May 2026, shipped a Dynamic Load Balancer. It uses real-time resource utilization in placement decisions and can automatically migrate guests managed by the HA stack to reduce imbalance across cluster nodes.

If you evaluated Proxmox before mid-2025 and rejected it on this point, the objection has a different answer now. Whether it is as mature as a feature VMware has been refining since 2006 is a fair question and one you should test rather than take on faith, but “there is no equivalent” is no longer accurate.

The same release added WireGuard and BGP support to the SDN stack, including BGP and EVPN filtering with route maps and prefix lists, plus custom CPU model management in the web interface and the ability to arm and disarm the HA stack during maintenance. That last one exists because somebody got fenced during a planned outage, and it is the kind of feature that only gets built by people running the thing in anger.

What does not transfer

Storage assumptions. This is the big one. VMFS is a clustered filesystem that hides a lot of decisions from you. ZFS and Ceph do not. ZFS wants to own bare disks, has opinions about RAID controllers that amount to “do not use one,” and its ARC will consume RAM in a way that alarms people reading a memory graph for the first time. Ceph is a distributed storage system with its own failure modes, its own vocabulary, and a genuine operational learning curve. Neither is harder than VMFS in absolute terms. Both are different enough that habits misfire.

The support relationship. With VMware you opened a case. With Proxmox you can buy a subscription that includes tickets, and the response times are published, but a large amount of the community’s operational knowledge lives in the Proxmox forum rather than in a knowledge base. Teams that are used to escalating find this uncomfortable at first. Teams that are used to reading find it faster.

Third-party tooling assumptions. Backup products, monitoring integrations, and automation that speak vSphere APIs do not speak Proxmox. Proxmox Backup Server is good and is the obvious answer for backups. For everything else, check before you commit rather than after.

What to do with a team mid-migration

The most useful preparation is not a Proxmox course. It is Linux fundamentals, because Proxmox VE 9.2 is Debian 13.5 underneath with a Linux 7.0 kernel, and the platform does very little to hide that from you. An administrator comfortable at a shell, reading journalctl, and understanding how systemd services and ZFS pools behave will be productive quickly. One who has only ever used a vSphere client will not, regardless of how many Proxmox tutorials they watch.

That is the retraining budget in one sentence, and it is the honest reason some migrations go well and others stall.

The transferable lesson

Learn the primitive, not the product. Live migration is a concept before it is vMotion. Distributed storage is a concept before it is vSAN or Ceph. A team that understands why shared storage is required for a particular failover behavior can implement that behavior on any platform. A team that has memorized a menu path is holding a skill with an expiry date set by somebody else’s pricing committee.

Sources: Proxmox VE 9.2 release, Proxmox VE 9.0 release.