Proxmox VE vs XCP-ng: which to choose

Proxmox VE or XCP-ng: which to choose for a VMware exit

Teams leaving vSphere that must pick one hypervisor platform should start by deciding where storage lives, because that choice shapes everything else. Proxmox VE fits when you want one product that runs KVM virtual machines and LXC containers and also provides software-defined storage through Ceph and ZFS, with subscriptions priced per CPU socket and differing only in support level. XCP-ng fits when you want a Xen-based hypervisor managed through Xen Orchestra, backed by Vates, with a long-term support line such as 8.3 LTS, which is supported until November 30, 2028. Both are credible VMware exits, so the decision turns on four questions: how you will design storage, what support terms you can accept, which skills your team already has, and what migration tooling you can rely on from vSphere.

Storage design is usually the first fork. If you plan a hyperconverged cluster where compute and disks share hosts, Proxmox VE's built-in Ceph and ZFS integration keeps the stack in one management plane, but you then own Ceph's operational model. If you already run a external SAN or NFS array, XCP-ng's storage options may map more directly onto your existing design. Ask each vendor, in writing, which storage back ends are supported in your target configuration and which are tested by the vendor versus community-supported. Support terms are the second fork. Confirm the exact support tiers, response expectations and the LTS dates for the release you plan to deploy, because a platform that is cheap to license can still be expensive to run without the support level your change process requires.

Finally, weigh in-house skills and migration tooling against the plan. Linux and KVM administration, or Xen administration through Xen Orchestra, will drive the learning curve for your operators. Ask for a migration rehearsal on a non-production cluster that moves representative VMs from vSphere, measures downtime and confirms that drivers, boot firmware and network settings survive the move. Document the rollback path before cutover. Pricing for either platform should come from a quote built on your socket count, support level and storage design, and DeployOpen can prepare that scope and the migration plan as a fixed-scope engagement once those inputs are agreed.

Which platform fits which VMware exit scenario

This table maps common VMware exit scenarios to the platform that tends to fit each one, and names the condition that drives the choice. Read each row as a starting point for your own requirements, then confirm the details in the sections that follow. The main takeaway is that the right answer depends on storage design, management model, container needs and how long you want a support window to last.

Scenario	Better fit	Condition that makes it so
Small cluster that wants hyperconverged storage	Proxmox VE	Ceph and ZFS are included in the platform, so storage can be built on the same hosts that run VMs. Confirm the hardware, network and replication design with the vendor before committing to a Ceph layout.
Team that wants Xen with a separate management appliance	XCP-ng with Xen Orchestra	The team wants the Xen hypervisor and is comfortable running Xen Orchestra as a separate management layer. Confirm how Xen Orchestra is deployed and supported in your environment, since it sits outside the hypervisor hosts.
Site that wants containers alongside VMs	Proxmox VE	Proxmox VE runs LXC containers next to KVM virtual machines in one interface. Containers are only useful if the workloads can run as Linux containers. Workloads that need a full Windows or non-Linux guest still run as VMs on either platform.
Estate that needs a long LTS window	XCP-ng	XCP-ng 8.3 LTS is supported until November 30, 2028, according to the XCP-ng releases documentation. Compare this with the support terms of your chosen Proxmox VE subscription level and the release cadence you can absorb before deciding.
Estate that buys support per CPU socket	Proxmox VE	Proxmox VE subscriptions are priced per CPU socket and differ only in support level, according to proxmox.com. Count sockets across the cluster and confirm how the level of support maps to your response needs before you request a quote.
Team with an existing Xen or XenServer skill set	XCP-ng	Operators already familiar with Xen concepts such as pools and XenServer tooling will ramp up faster. Assess whether that familiarity outweighs the benefit of a single integrated stack with built-in storage.
Estate that needs integrated software-defined storage	Proxmox VE	Ceph and ZFS are part of the Proxmox VE platform. Ceph in particular needs enough nodes, drives and network capacity to run well, so confirm sizing and failure domains with the vendor and your own team.

How Proxmox VE and XCP-ng are built and what that means for operations

Both platforms replace VMware with open-source hypervisors, but they put storage, management and maintenance in different places. The build choices below determine who owns each layer after go-live, so check them against your team's skills before you commit.

KVM and LXC in one host stack

Proxmox VE combines the KVM hypervisor for full virtual machines with LXC for system containers in a single platform. Operationally, your team runs both workload types under one management plane, so it must govern container templates and kernel-sharing boundaries alongside VM images. Confirm which workloads you intend to run as containers, since a container shares the host kernel and does not carry its own guest OS. Plan patch windows for the host because a host reboot affects both VMs and containers.

Software-defined storage built in

Proxmox VE includes software-defined storage options, including Ceph and ZFS, so storage can live on the same nodes that run your workloads. This removes a separate SAN from the design, but it moves storage failure modes, replication settings and rebuild behavior onto your operations team. Ceph and ZFS design details, including pool layout, redundancy level and network sizing, must be confirmed in your own environment before you size hardware. Ask for a written storage design that names the failure scenarios you tested.

Xen hypervisor from XenServer lineage

XCP-ng is a Xen-based virtualization platform that began as an open source version of Citrix XenServer. Teams familiar with the XenServer model will recognize its pool and host concepts, which keeps the migration mental model closer to the platform you may be leaving. Confirm that your guest operating systems, drivers and backup agents are supported on Xen before you plan the cutover. Inventory any appliance or tool that expects a VMware or KVM management interface.

Xen Orchestra as a separate management layer

XCP-ng is managed through Xen Orchestra, which is a separate component from the hypervisor host. Your team must deploy, patch, back up and secure the Xen Orchestra instance in addition to the hosts it manages. Plan for its availability, since losing the management layer does not stop running VMs but does limit administration until it is restored. Ask the vendor which Xen Orchestra edition covers the features you need, and confirm how its access controls integrate with your identity provider.

Vates as the commercial backer

XCP-ng is backed by Vates, which means the project's direction, support and commercial terms depend on that company. Ask Vates to describe the support levels, response expectations and escalation path for your entitlement in writing. Compare that with the per-socket subscription model that Proxmox VE uses for its Enterprise Repository, because the two models set different expectations for patch access and vendor contact. Confirm the terms before you assume any level of coverage.

Release lines and LTS windows

XCP-ng publishes LTS releases with defined end-of-support dates, so your upgrade planning must follow those windows. XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, while 8.2 LTS support ended September 16, 2025. Proxmox VE releases follow its own roadmap, with Proxmox VE 9.2 released on May 21, 2026. Map each platform's support dates against your planned refresh cycle, and confirm how long your chosen subscription level covers the version you deploy.

Proxmox VE vs XCP-ng feature and support comparison

This table compares Proxmox VE and XCP-ng on hypervisor design, containers, built-in storage, management, licensing, support and release windows. Read each row as a question to settle with the vendor where the facts leave a gap, because a row marked as a point to confirm affects contract terms and architecture decisions.

Capability	Proxmox VE	XCP-ng
Hypervisor	KVM for full virtual machines, combined with LXC containers on one host	Xen hypervisor, managed through Xen Orchestra
Container support	LXC containers run alongside KVM virtual machines in the same management plane	Xen-based virtualization focused on virtual machines, so confirm any container requirement with Vates
Built-in software-defined storage	Ceph and ZFS are included in the platform	No Ceph or ZFS built in, so confirm which storage options Xen Orchestra and XCP-ng support in your design
Management interface	Integrated web interface on each cluster node	Managed through Xen Orchestra, a separate management layer
License	GNU Affero General Public License version 3 (AGPL-3.0)	xcp repository licensed GPL-2.0; confirm licensing of Xen Orchestra separately
Support model	Subscriptions priced per CPU socket, differing in support level, with access to the Enterprise Repository	Backed by Vates; confirm support tiers and terms directly with the vendor
LTS or release window	Release cadence per the Proxmox VE roadmap; confirm support length for your version	XCP-ng 8.3 LTS released October 7, 2024, supported until November 30, 2028
Most recent version named in the facts	Proxmox VE 9.2, based on Debian 13.5 Trixie, released May 21, 2026	XCP-ng 8.3 LTS, the LTS line named in the facts; confirm the current release with Vates

What Proxmox VE and XCP-ng licensing and editions include

Proxmox VE subscriptions are priced per CPU socket, according to proxmox.com. Each subscription includes access to the Enterprise Repository, and the tiers differ only in the level of support you receive. The platform code itself is licensed under the GNU Affero General Public License version 3, which is documented in the Proxmox VE FAQ, so the core software is not gated behind a feature edition.

Pricing unit: cost scales with the number of CPU sockets across your Proxmox nodes, not with virtual machine count or storage capacity.
Enterprise Repository: subscriptions include access to the tested, stable update channel, which is the repository most production teams use.
Support level: the tiers differ in support depth only, so you do not choose a different feature set when you upgrade.
Release cadence: Proxmox VE 9.2, based on Debian 13.5 Trixie, was released on May 21, 2026, per the Proxmox VE FAQ and roadmap.
Recurring cost: the subscription is an annual charge per socket, so plan it into operating budgets alongside hardware and staff time.

Confirm the current per-socket price, the support response terms and any minimum term with Proxmox directly, since the quote follows your socket count and tier.

What drives the running cost of each platform

Running cost for Proxmox VE and XCP-ng comes from four places: the support contract, the hardware and storage layout, the staff hours spent on upgrades and storage work, and any migration help you buy. Each one splits differently between one-time and recurring spend, so price them as separate lines in a written quote.

Subscription and support fees

Proxmox VE subscriptions are priced per CPU socket, include the Enterprise Repository, and differ only in support level, so the recurring fee scales with host sockets, not with VM count. XCP-ng support is provided through Vates, and the fee depends on the support tier and host count you contract. Ask each vendor whether the quote covers every host in a cluster, including spares and future expansion, and whether it renews annually or on a multi-year term.

Hardware and storage layout

Proxmox VE can build software-defined storage with Ceph or ZFS on the same hosts that run VMs, so hyper-converged designs need more RAM, CPU and disks per node. XCP-ng typically pairs with external storage arrays or shared storage you already own. Compare the one-time purchase of nodes and drives with the recurring power, rack space and replacement parts. Ask each vendor for the minimum node count and drive layout it recommends for your redundancy target.

Staff time for upgrades

Proxmox VE and XCP-ng both need routine host and cluster upgrades, and the release cadence sets how often your team does that work. XCP-ng 8.3 LTS is supported until November 30, 2028, which lets a team plan upgrades around a fixed window. Estimate the hours for rolling upgrades, testing and rollback per cycle, and ask whether either vendor's support fee includes engineering help for upgrade problems.

Storage operations and skills

Running Ceph inside Proxmox VE adds recurring work: monitoring placement groups, replacing failed OSDs, and planning capacity. Ceph Squid (v19) has an estimated end of life of October 31, 2026, so any cluster on that release needs a planned move, which is staff time. If you run external storage with XCP-ng, the cost moves to the storage vendor's support contract. Ask who on your team owns storage recovery and whether training is included in the quote.

Migration tooling and services

Moving workloads off vSphere is mostly a one-time cost: conversion tools, downtime windows, network re-addressing and validation of restored VMs. Proxmox VE and XCP-ng each have their own import paths, and the effort depends on your VM count, guest operating systems and backup format. Services can be quoted separately from the platform subscription. Ask for a written scope listing which VMs move, the rollback plan, and who performs the cutover and acceptance tests.

Moving a vSphere estate to Proxmox VE or XCP-ng in order

This sequence moves workloads from vSphere to either platform with a tested backup path, a sized storage design and a clear record of what was rebuilt rather than carried over, so the decommission decision rests on evidence.

Inventory VMs, disks and dependencies
The platform team, with application owners, lists every VM, its vCPU and memory allocation, disk sizes and layout, snapshots, attached devices, network segments and external dependencies such as DNS, licensing servers and databases. Vendor-specific features in use, including vSphere-only functions like distributed switching or certain VM templates, are flagged because they will not carry over unchanged. The step is done when every workload has an owner, a migration method and a documented dependency list. Confirm current import tooling and supported guest formats with the Proxmox VE and XCP-ng documentation before choosing methods.
Choose the target storage design
Decide between Proxmox VE with Ceph or ZFS and XCP-ng storage repositories, based on the inventory's capacity, performance and failure-domain needs. Ceph needs at least three nodes in a typical replicated design, and its storage types (block, file and object on one RADOS cluster) matter if other services need object storage. Ceph Squid (v19) reaches estimated end of life October 31, 2026, and Tentacle (v20) is estimated to end June 1, 2027, so confirm the Ceph version that Proxmox VE ships before committing. The output is a written storage decision with capacity, redundancy and expansion assumptions for the people who will operate it.
Build a pilot cluster
A small cluster on the target platform, sized for two or three non-critical VMs, is built with the chosen storage, network bonding and management access. The team validates live migration, node failure behavior, storage rebuild and update procedures on the actual hardware. Plan to confirm which configurations the vendor documents as supported, especially for shared storage and HA. The step closes when a node can be pulled from the pilot and the workloads recover as expected, with the results recorded.
Test backup and restore end to end
Backup tooling is tested before any production VM moves. Proxmox VE uses its own backup jobs, while XCP-ng relies on Xen Orchestra for backup and replication, so the team restores a sample of VMs from the new platform and from existing vSphere backups into the pilot. Restore time, consistency of application data and retention behavior are measured against recovery objectives set by the business. The step is done when restores succeed for each workload class and the runbook is updated. Backup jobs are rebuilt on the target, so this step also defines the new retention schedule.
Migrate workloads in waves
Workloads move in groups ordered by dependency and risk, starting with low-impact systems. Disks and VM configuration are converted or imported, while guest operating system drivers, network identifiers and license bindings are checked and adjusted. Each wave ends with functional testing by the application owner, not only a boot check. The output is a per-wave record of what moved, what was changed and what was rolled back if needed. Keep vSphere copies running until the wave is accepted.
Rebuild management, monitoring and identity
Some items never transfer. vCenter-level roles, alarms, dashboards, directory bindings, backup schedules and monitoring agents are rebuilt on the target platform. The team reconnects identity sources, maps administrator roles to the new management plane and points monitoring at the new hosts. Confirm supported identity integration and role models with the platform documentation. The step is complete when administrators, monitoring alerts and backup reports all function without reliance on vSphere.
Decommission vSphere after acceptance
Once every wave is accepted and a full restore cycle has run on the new platform, the vSphere environment is retired. Licenses, support contracts and hardware are released in an order agreed with procurement, and final backups of retired systems are kept under the retention policy. The step is done when the decommission record lists every system retired, where its final data is stored, and who approved it.

Where VMware exit projects with these platforms usually run long

Most delays in a VMware exit come from decisions made early and revisited late. Storage design and cluster sizing top the list. On Proxmox VE, the choice between local ZFS replication and a shared Ceph pool changes how hosts are built, how many nodes a quorum needs and how live migration behaves, so the decision should be made before the first VM moves. On XCP-ng, the storage repository type and the pool layout under Xen Orchestra carry the same weight. Ask each vendor or your own storage team to confirm the supported layouts for your hardware, then size the cluster for a failed node during your peak month, not for average load. Ceph itself has its own release calendar, so check the lifecycle of the Ceph release you plan to run against your hardware refresh plan.

Network and VLAN mapping is the second common source of slippage. Every VMware port group has to be recreated as a Linux bridge or VLAN-aware bridge on Proxmox VE, or as a network object in XCP-ng, and each VM's NIC has to land on the right segment before cutover. Teams often discover late that storage, management and migration traffic share a physical uplink they assumed was separate. Backup and restore validation is the third. A backup job that completes is not proof of recoverability. Schedule restore tests for representative VMs, including a database and a domain controller, and record how long each restore takes. The restore test also shows whether your backup product supports the target hypervisor, which should be confirmed in writing before the pilot.

Identity and access integration and staff training usually finish last and push the schedule. Administrators need roles, realm or directory binding and audit logging mapped to your existing identity provider, and those mappings should be tested with a pilot group rather than shared administrator accounts. Operations staff also need hands-on time with live migration, snapshot behavior, and cluster recovery. Every one of these streams needs a named owner who signs off on decisions, a test environment that mirrors production networking and storage, and a pilot window long enough to run restores and one failure drill. Timelines depend on estate size, VM count, storage volume and scope, and these are agreed in writing in a fixed-scope engagement. This page does not estimate a duration. Ask for a written scope that lists each of these streams with its owner and exit criteria before accepting any schedule.

Questions buyers ask before hiring help for a Proxmox VE or XCP-ng migration

What does a Proxmox VE or XCP-ng migration project cost, and what drives the price?

The cost is set by the written scope, not by a list price. DeployOpen does not publish a price list, and a quote follows from the agreed scope, so the number of hosts, virtual machines, storage backends and integrations drives the figure most. Costs fall into four groups: the design and discovery work, the migration waves themselves, testing and cutover, and documentation with handover. Platform licensing is a separate line. Proxmox VE subscriptions are priced per CPU socket and include the Enterprise Repository, differing only in support level, and XCP-ng support terms come from Vates, so ask each vendor for current terms. When you request a quote, ask for the scope and deliverables in writing, which hosts and workloads are in and out, who pays for licenses versus services, and which items recur, such as subscriptions and retainers.

How long does a vSphere to Proxmox VE or XCP-ng migration take?

The timeline depends on the size and dependency map of your estate, not on the platform alone. The main variables are how many virtual machines have hard dependencies, how much storage has to be moved or rebuilt, whether you need Ceph or ZFS designed in from the start, how many network segments and identity integrations must be recreated, and how many change windows your business allows. Ask for a timeline tied to phases with named entry and exit criteria, and ask what the plan assumes about rollback and parallel running. DeployOpen agrees timelines in the written scope before work starts, so any duration you receive should trace back to those inputs rather than a generic estimate.

What does the migration require from our own staff?

Expect your team to supply knowledge of the current environment and to own final decisions. Typically that means a named owner for the vSphere estate, people who understand each application's dependencies and maintenance windows, the network and storage administrators who can grant access and approve changes, and someone who can sign off on acceptance tests. Your team also needs to decide what happens after handover, including who patches hosts, who responds to alerts and who approves upgrades. Ask the provider to list these client responsibilities in the scope so that delays caused by missing inputs are visible and agreed up front.

Can our team migrate to Proxmox VE or XCP-ng without outside help?

Many teams with strong Linux, virtualization and storage skills can complete a small migration in-house, and the vendor documentation covers the core steps. The harder questions are the ones that determine risk: how to plan storage for Ceph or ZFS, how to handle backups and restore testing, how to keep recovery objectives intact during cutover, and how to document controls for an audit. If your team lacks recent hands-on time with these platforms, a fixed-scope engagement can cover the parts you choose to outsource, such as design review, hardening, or migration waves, while your staff keeps operational knowledge. DeployOpen implements, hardens, backs up, documents and supports self-hosted platforms inside your own infrastructure, and it prepares evidence for compliance assessments without issuing audit reports.

How do LTS windows affect upgrade planning for XCP-ng and Proxmox VE?

The support window determines when you must move, so put dates into the plan from day one. XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, while XCP-ng 8.2 LTS support ended on September 16, 2025, which shows how quickly a branch can leave support. Proxmox VE 9.2, based on Debian 13.5 Trixie, was released on May 21, 2026, and its support depends on the subscription level you choose. Ask each vendor for the full life cycle of the version you will deploy, and ask whether upgrades are in-place or require rebuilds. Build the upgrade cadence into the fixed scope or retainer, because it recurs for the life of the platform.

How should we choose between Proxmox per-socket subscriptions and XCP-ng support?

Compare what each option includes, not only the headline price. Proxmox VE subscriptions are priced per CPU socket, include the Enterprise Repository, and differ only in support level, so your socket count and the support tier you need set the recurring cost. XCP-ng support is provided through Vates, so compare the terms, response commitments and what is covered, and confirm them directly with the vendor. Then compare the parts that sit outside licensing: the engineering effort to run each stack, the storage model you need, and whether you want Ceph or ZFS built in. Ask for both quotes in the same format, with recurring and one-time costs listed separately, so the comparison reflects your real environment.

How DeployOpen helps choose, implement and migrate without favoring either platform

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. We run the same method for Proxmox VE and XCP-ng, so the platform choice follows your requirements rather than our preference.

How we scope

We write down your VMware workloads, host counts, storage needs and HA expectations before recommending either platform.
Fixed-scope agreements list the Proxmox VE or XCP-ng deliverables, migration waves and acceptance criteria in writing before work starts.
We confirm current support terms, LTS windows and subscription tiers with each vendor so the scope reflects dates you can plan around.

How we build

We design cluster layout, storage pools and network segmentation for either Proxmox VE with Ceph or ZFS, or XCP-ng with Xen Orchestra.
We configure identity integration, role-based access, backup jobs and monitoring hooks to match your existing security baseline.
We test live migration from vSphere on pilot workloads, record rollback steps and verify performance against the agreed acceptance criteria.

How we hand over

You receive architecture documentation, runbooks for patching, upgrades and failover, and the configuration files your team needs to maintain.
Evidence packs for compliance readiness list controls, configuration baselines and test results, prepared for your independent auditor to assess.
Knowledge transfer sessions walk your administrators through day-two tasks so your team can operate the platform after handover.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover, scoped separately from the build.
Retainers can cover vendor release tracking, such as the XCP-ng LTS or Proxmox VE upgrade windows, and the testing that follows each change.
Before signing, ask us which support terms and response commitments apply, since these are set in the written agreement rather than in this page.

Proxmox VE vs XCP-ng