Broadcom’s acquisition of VMware closed in November 2023 for roughly $61 billion, and within months the licensing model that most enterprise infrastructure teams had built around for a decade was gone. Perpetual licences were eliminated. The product catalogue shrank from over 8,000 SKUs to four bundles. Reported price increases range from 150% to over 1,000%, with AT&T facing proposals near 1,050% under the new subscription structure. A Gartner Peer Community survey found 74% of IT leaders are now actively exploring VMware alternatives, and vSphere 7 reaches end-of-support in October 2025, which is compressing timelines further. If your organisation is in that 74%, this post is the architecture guide you need before you start moving workloads.
Why bare metal changes the calculus
The conversation about VMware alternatives usually starts with managed cloud alternatives, but for workloads that are latency-sensitive, IO-intensive, or subject to strict data-residency requirements, bare metal is the more honest answer. You get full CPU and memory access with no hypervisor tax from a shared layer above you, predictable NUMA topology, and direct NVMe access. You also get to choose your own hypervisor and own the upgrade cycle, which is precisely the autonomy that Broadcom’s new model removes.
The trade-off is operational responsibility. You are managing the host OS, the hypervisor, storage clustering, and HA fencing. That is not a reason to avoid bare metal; it is a reason to plan the architecture carefully before you migrate the first VM.
The two serious open-source hypervisor options
For enterprise workloads on dedicated hardware in 2025, the realistic shortlist is Proxmox VE and XCP-ng. Both are production-grade, both have active communities and commercial support paths, and both are genuinely open-source rather than open-core products with critical features paywalled. The choice between them is an architecture decision, not a preference.
Proxmox VE: KVM-native, storage-rich, growing fast
Proxmox VE combines KVM and LXC under a single web interface, using QEMU for virtualisation and Corosync for cluster communication. Its storage story is strong: native ZFS, LVM-thin with snapshots, iSCSI, NVMe-oF, and built-in Ceph integration. That last point matters significantly if you are building a hyperconverged cluster without a separate SAN. Proxmox VE 8.4, released in April 2025, adds live migration with NVIDIA vGPUs and an API for third-party backup solutions, which closes two gaps that previously required workarounds.
The licensing model is worth understanding precisely. Proxmox VE is AGPLv3 software: free to download, install, and run in production with no licence cost. What you pay for optionally is access to the enterprise update repository and vendor support. The Basic support tier runs approximately €370 per CPU socket per year with three support tickets included. The Community tier starts at €120 per socket per year. Those numbers are per socket, not per core, which is a meaningful structural difference from VMware’s model. Without a subscription, the no-subscription repository receives updates that have not passed the same testing pipeline as the enterprise repository, so production clusters should carry at least Community tier.
The built-in migration wizard can import VMware VMs, but it is still early-stage: VMs must be powered off, it connects to ESXi hosts directly rather than through vCenter, and VMs with snapshots require cleanup first. Plan your migration tooling separately rather than relying on the wizard for bulk moves.
XCP-ng: Xen-based, with stronger VMware import tooling
XCP-ng is the open-source Xen hypervisor packaged with the XAPI management toolkit, managed through Xen Orchestra. Its migration story is arguably more mature than Proxmox’s at this point: Xen Orchestra 6 includes an integrated V2V tool that supports streaming, agentless conversion from VMware, including VMFS6 and VSAN configurations, with warm migration support across all ESXi versions. If you have a large VMware estate and want to minimise downtime during the cut-over phase, that tooling is a genuine advantage.
The storage gap is real, however. XCP-ng lacks official Ceph and ZFS support, which pushes hyperconverged storage designs toward external solutions or third-party integrations. For workloads that can use traditional NAS or SAN backends, this is not a blocker. For teams planning a fully converged stack, it is a constraint worth pricing into the architecture.
The hypervisor is not the hard part of a VMware migration. The hard parts are storage architecture, HA fencing logic, and the operational tooling your team has built around vCenter over the last decade.
Architecture decisions before you touch a host
Regardless of which hypervisor you choose, four architecture decisions need answers before the first workload moves.
- Storage topology. Hyperconverged Ceph on Proxmox, shared NFS or iSCSI from a dedicated appliance, or local NVMe with replication at the VM level? Ceph on Proxmox needs at minimum three nodes and dedicated replication NICs. Local NVMe with PBS (Proxmox Backup Server) replication is simpler operationally but recovery time objectives are longer. The PBS Basic tier costs €1,120 per backup server per year, covering five support tickets and one business-day response.
- HA fencing strategy. Proxmox HA uses a quorum-based model: a majority of nodes must be reachable for the cluster to operate. In a three-node cluster, one node failure is tolerable; two is not. Size your cluster with fence quorum in mind, not just raw capacity.
- Network segmentation. Define separate VLANs or bonds for VM traffic, storage replication, cluster heartbeat, and IPMI/BMC access before you configure the first host. Retrofitting network segmentation onto a running cluster is painful.
- Migration sequencing. Tier your VMs by criticality and dependency. Start with stateless or easily reproduced workloads to build operational confidence, then move databases and clustered services last. Workloads with VMware snapshots need the snapshots collapsed before import regardless of which tool you use.
Choosing hardware for the new estate
Open-source hypervisors impose no artificial core minimums, but hardware selection still matters. For Proxmox with Ceph, the recommended minimum is three nodes with at least one dedicated NIC (25GbE preferred) for storage replication and a separate NIC for cluster heartbeat. NVMe drives should be on separate controllers from spinning disks if your workload mix includes both. For XCP-ng, the XAPI stack is less memory-hungry than vCenter, so you can run management functions on the same hosts without meaningful overhead.
We run bare metal at MUC1 in Munich specifically because the DACH finance and industrial workloads that land there demand predictable IO and strict residency. Those customers are among the ones currently stress-testing open-source hypervisor configurations on dedicated hardware, and the consistent finding is that the operational gap versus vSphere narrows quickly once the team has managed two or three patching cycles on the new stack.
What the migration actually looks like
A realistic migration timeline for a mid-sized VMware estate, say 50 to 200 VMs, runs eight to sixteen weeks when the architecture decisions above are made upfront. The phases are: hardware provisioning and hypervisor baseline (weeks one and two), storage and network validation (weeks two and three), pilot migration of non-critical VMs (weeks three through six), tooling and runbook development (parallel), and production cut-over in waves (weeks six through completion). The Broadcom late-renewal penalty, an extra 20% of the first-year subscription price applied retroactively if you miss your renewal date, creates a hard deadline that should anchor your project plan.
The technical lift is real but manageable. The teams that struggle are the ones who underestimate the operational tooling they have built around vCenter: custom alarm scripts, integration with ticketing systems, backup schedules tied to VMware snapshot APIs. Audit those dependencies before you start, not after the first production host is cut over.
The honest summary
Proxmox VE is the better default for new clusters where you control hardware selection and want a converged storage story. XCP-ng is worth serious consideration when the VMware estate is large and migration downtime is the primary constraint, because its V2V tooling is more mature today. Neither choice locks you in the way Broadcom’s bundle structure does, and both can be supported commercially at a fraction of what VMware subscriptions now cost. The architecture work is yours to do either way; the licensing argument for doing it has never been clearer.
