Proxmox VE or XCP-ng: which fits a VMware exit
Choose Proxmox VE if you want KVM virtual machines, LXC containers and software-defined storage on the same nodes, with Ceph or ZFS built in. Choose XCP-ng if you want the Xen hypervisor managed through Xen Orchestra and a commercial support contract from Vates. The decision turns on three questions: where your VM disks will live, which support terms and LTS windows you can accept, and how you will move machines off vSphere. Start with the storage design, because it sets the node count, network and hardware you need before any license or subscription conversation begins. A team that plans hyper-converged storage across several nodes will evaluate the two platforms differently from a team that keeps a separate SAN for its VMs.
Support terms are structured differently. Proxmox VE subscriptions are priced per CPU socket per year and differ in support level and enterprise repository access, while the software can run without one. Proxmox VE versions receive support for roughly as long as the matching Debian release has security support, and Proxmox VE 8 reached end of life in August 2026, so confirm which release line you will standardize on. 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 September 16, 2025. Vates sells support subscriptions that add SLAs, so request the written SLA, response times and escalation path before you choose an LTS line for production hosts.
Storage and migration determine most of the exit cost. Proxmox HA needs at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, so budget that hardware before you commit to a design. Proxmox nodes can use Ceph RBD, CephFS or ZFS, while XOSTOR on XCP-ng is a Vates add-on with its own per-host pricing, so confirm which storage model your target design requires. For migration, Xen Orchestra includes V2V, which uses warm migration over HTTP access to the ESXi API. The XCP-ng migration documentation states that ESXi 6.x hosts are not supported for V2V, so check your ESXi build first. Then review the Proxmox VE migration guide and run a pilot import of a non-production VM on each platform before you set a cutover date.
Which platform fits which VMware exit scenario
This table maps common VMware exit scenarios to the platform that tends to fit each one and the condition that decides it. Read each row as a starting question: if the condition in the cell describes your environment, that platform is the likelier fit. Neither platform is a universal answer, so confirm the conditions against your hardware, storage plan and support requirements before you choose.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small cluster with existing shared storage (NFS or iSCSI) | XCP-ng | Xen Orchestra and XAPI manage shared storage repositories directly, and the migration path from vSphere is documented with V2V warm migration over the ESXi API. |
| Small cluster with a few hosts and no shared storage yet | Proxmox VE | Local ZFS with storage replication works without a SAN, but Proxmox HA still needs at least three nodes, shared storage for guests and watchdog-based fencing. |
| Team wants Ceph or ZFS without a separate SAN | Proxmox VE | Ceph RBD and CephFS and ZFS are built into the platform, so hyper-converged storage is native. Confirm node count, network and disk layout before committing, because Ceph needs enough nodes and bandwidth to hold up under failure. |
| Team needs HA with automatic recovery of failed-node guests | Proxmox VE | Proxmox HA needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. Without those, do not plan on HA behavior. |
| Team needs a contracted vendor with SLAs and defined response times | Depends on tier | Proxmox support tiers set ticket counts and response times, while Vates commercial support subscriptions add SLAs. Compare the specific response commitments and escalation paths in both quotes before deciding. |
| Xen-experienced team already running XenServer or Citrix Hypervisor | XCP-ng | Existing operator skills, XAPI tooling and the documented upgrade path from XenServer and Citrix Hypervisor lower the learning curve. Confirm that the XCP-ng release line you plan to run is inside its support window. |
| Team wants to run LXC containers beside VMs on the same host | Proxmox VE | KVM and LXC are both first-class on one platform. LXC guests share the host kernel and are Linux-only, so keep workloads that need their own kernel in KVM virtual machines. |
| Team wants no per-socket licensing and a free core product | XCP-ng | Vates describes XCP-ng and Xen Orchestra as open source with no license fees, with commercial support adding SLAs. Support costs still recur, so treat the free core as a software decision, not a support decision. |
| Team that must run ESXi 6.x hosts during migration | Neither, verify first | XCP-ng documents that current Xen Orchestra versions do not support ESXi 6.x hosts for V2V. Confirm the ESXi version and the migration tool path for your hosts before choosing either platform. |
How Proxmox VE and XCP-ng are built and what that means for operations
Both platforms run guests on a KVM or Xen hypervisor and manage clusters from a central layer, but they split that work differently. The cards below compare where management runs, how nodes share state, how storage attaches and how failover is triggered, so you can see which component to watch during an outage.
Hypervisor and guest model
Proxmox VE runs KVM virtual machines and LXC containers on a Debian host, so the host kernel is shared by containers and Linux-only guests. XCP-ng is a type-1 Xen hypervisor booting on bare metal, with the dom0 control domain, the XAPI toolstack and QEMU for guest I/O. Operationally, a Proxmox host is a Linux server you patch with Debian tooling, while an XCP-ng host is a Xen appliance where dom0 and XAPI need their own patch and troubleshooting skills. Check which guest types you must run before choosing.
Cluster state and management layer
Every Proxmox VE node can perform all management tasks, and the Proxmox Cluster File System replicates configuration to all nodes in real time. XCP-ng groups hosts into a XAPI pool, and Xen Orchestra sits outside the hosts as the management layer for backups, migrations and the web UI. For day-two work, a Proxmox node can be used to manage the cluster if others fail, while an XCP-ng pool depends on Xen Orchestra being available to run most operations. Confirm where your team will host Xen Orchestra and how it is protected.
Local and network storage options
Proxmox VE supports local LVM, directory and ZFS storage, and network storage on iSCSI, NFS, CIFS, Ceph RBD, CephFS and Proxmox Backup Server. XCP-ng uses storage repositories managed through XAPI, and Vates sells XOSTOR hyperconverged storage as a paid add-on. The storage choice decides what a host failure costs you: local ZFS needs replication and accepts a data loss window, while shared storage keeps guests recoverable from another node. Ask each vendor which storage backend your array or hardware supports before you commit.
High availability and watchdog fencing
Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. The watchdog resets a failed node before its guests restart elsewhere, which prevents the same disk from being written by two hosts. Plan for a small cluster to lose quorum during maintenance, and test fencing on your hardware before relying on it. Confirm how XCP-ng pool HA is configured in your environment and what it requires for fencing and shared storage.
Upgrades and host lifecycle
Proxmox VE releases track Debian: Proxmox VE 9.2 is based on Debian 13.5 Trixie, and a Proxmox version is supported at least as long as its Debian release has security support. XCP-ng 8.3 LTS is supported until November 30, 2028, and XCP-ng 8.2 LTS support ended September 16, 2025. Operationally, a Proxmox upgrade is a Debian-based major release cycle, while XCP-ng upgrades follow LTS windows. Plan a rolling host upgrade for each cluster and confirm which release line your hardware drivers and storage need.
Capabilities side by side: hypervisor, storage, identity and migration
This table compares Proxmox VE and XCP-ng on the capabilities that usually decide a VMware replacement: hypervisor design, storage, high availability, management and migration. Read each row as a question to answer for your own environment, and treat blank or unconfirmed cells as items to verify with each vendor before you commit.
| Capability | Proxmox VE | XCP-ng |
|---|---|---|
| Hypervisor and guest types | KVM hypervisor running virtual machines, plus LXC containers on one platform | Xen-based type-1 hypervisor on bare metal with XAPI toolstack and QEMU for guest I/O |
| Container support | Native LXC containers managed alongside VMs | No |
| License | GNU AGPL v3 for Proxmox VE code; support is sold as subscriptions | GPL-2.0 for the xcp repository; open-source hypervisor and Xen Orchestra with paid support from Vates |
| Built-in software-defined storage | Ceph and ZFS included as local or hyper-converged options | XOSTOR hyperconverged storage is a paid Vates add-on, not included in the base platform |
| Supported network storage | iSCSI, NFS, CIFS, Ceph RBD, CephFS and Proxmox Backup Server | Confirm supported SR types for your array and protocol with Vates documentation |
| High availability requirements | At least three cluster nodes for reliable quorum, shared storage, redundant hardware and watchdog-based fencing | Confirm HA prerequisites, quorum and fencing design with Vates before sizing |
| Management interface | Built-in web UI on every cluster node with multi-master cluster management | Managed through Xen Orchestra, a separate management layer |
| Identity and RBAC depth | Confirm directory integration and role model against the Proxmox user management documentation | Confirm SSO, directory integration and role model with Vates for your version |
| V2V migration from ESXi | Migration guidance is documented for moving VMware workloads to Proxmox VE | Xen Orchestra includes V2V warm migration that needs only HTTP access to the ESXi API |
| ESXi version limit | Confirm supported source ESXi versions in the Proxmox migration guide for your source estate | ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V |
What the license and paid tiers actually cover on each platform
Proxmox VE's code is licensed under the GNU Affero General Public License version 3, and the administration guide introduction states the same license. The subscription is a support and repository agreement layered on software that can run without one. Subscriptions are priced per CPU socket per year, according to the Proxmox VE pricing page, and current terms should be confirmed there before budgeting.
- AGPL-3.0 code: The license applies to the Proxmox VE code, so teams that modify the platform or offer it to others should review their obligations with counsel.
- Per-socket tiers: Community is 120 euros with no support tickets, Basic is 370 euros with 3 tickets and a 1 business day response, Standard is 550 euros with 10 tickets and a 4-hour response, and Premium is 1,100 euros with unlimited tickets and a 2-hour response.
- Same features at every tier: All tiers carry the same software features, so the tiers differ only in support entitlements and enterprise repository access.
- Repository access: The enterprise repository requires a valid subscription key and is the recommended repository for production, while the no-subscription repository is described for testing and non-production use.
- Running without a subscription: The software can be used without a subscription, so the purchase decision centers on support levels and production repository access.
Check the socket count on every host you plan to run, including hosts you expect to add later, and confirm whether your change control rules accept the no-subscription repository for any production system.
The xcp repository is licensed GPL-2.0, and Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no limits and no license fees. Paid terms come from Vates, which sells VMS plans, per-host support and add-ons. The Vates pricing and support page lists the figures below, and they should be confirmed there because plan terms can change.
- Open-source core: Vates states that the hypervisor and Xen Orchestra have no license fees, and that commercial support subscriptions add SLAs.
- VMS plans: Essential is $2,000 per year and Essential+ is $4,000 per year, each for up to 3 hosts. Pro is $1,000 per host per year with a 3-host minimum, and Enterprise is $1,800 per host per year with a 4-host minimum and 24/7 support.
- XOSTOR as a separate add-on: Vates sells XOSTOR hyperconverged storage at $800 to $1,200 per host per year, so storage is priced apart from the support plan.
- Support scope: Ask which plan covers each host in a pool and whether Enterprise 24/7 coverage applies to every host you run.
- Flat versus per-host pricing: Essential and Essential+ are flat for up to three hosts, while Pro and Enterprise scale with host count, so the host count decides which line applies.
Confirm which plan fits each host in your pool, whether XOSTOR is part of your storage design, and the currency and terms your procurement team will accept.
Both platforms have open-source software with no core license fee, so the quote is mostly support, storage, implementation and staff time. Support is a recurring vendor charge, while migration, configuration and documentation are one-time work. The main cost drivers are CPU socket count on Proxmox, host count and plan choice on Vates, and whether you buy storage add-ons. DeployOpen plans and implements both platforms and publishes no price list; a quote follows the written scope.
- Pricing units: Proxmox counts CPU sockets per host, while Vates counts hosts or sells flat plans for up to three hosts. Ask each vendor to price your exact host and socket layout.
- Recurring versus one-time: Vendor subscriptions renew each year, while migration and configuration are one-time work. Ask for both lines separately.
- Storage charges: Proxmox supports Ceph and ZFS within its software, while XOSTOR is a separate per-host Vates charge. Ask what each design adds to the yearly total.
- Implementation scope: Request a written scope with deliverables, timelines and exclusions, since DeployOpen agrees scope in writing before work starts.
- Renewal and life cycle: Ask how long each release line receives support, and confirm current dates on each vendor's life cycle page.
Request both quotes from the same host list, socket counts, storage design and support hours so the totals are comparable.
How support windows and LTS releases change the upgrade plan
Proxmox VE and XCP-ng tie their support windows to different things: a Debian release on one side, a named LTS branch on the other. Those differences decide how often you must upgrade, how much change each upgrade carries, and what you pay to get help. Read each card, then ask for the dates and terms in writing before you commit.
Proxmox support follows Debian
Proxmox VE releases are supported at least as long as the matching Debian release receives Debian security support, which the Proxmox FAQ puts at roughly three years. Proxmox VE 8 on Debian 12 reached end of life in August 2026, so any fleet still on 8.x is already past its window. Plan the major upgrade as a recurring project, not a one-time event. Confirm with Proxmox which release will follow Proxmox VE 9.2 and how much notice you get before end of life.
XCP-ng 8.3 LTS runs longer
XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028. That gives a planned fleet a fixed target date, which makes budget and change windows easier to set. Within the window you still need to apply updates, so schedule them and test them on a non-production host first. Ask Vates whether the support date applies to all components of the platform and to Xen Orchestra, since your management layer also has to stay current.
Short LTS windows carry risk
XCP-ng 8.2 LTS support ended on September 16, 2025, which shows how quickly an LTS branch can leave you without vendor fixes. Teams that installed 8.2 and deferred upgrades had to move to a newer branch under time pressure. Before you select a version, check the published end date against your migration schedule and your change calendar. Treat the end date as the deadline for your upgrade, not the date you plan to start.
Support tier sets response terms
Proxmox subscriptions are priced per CPU socket and differ mainly in support: Basic allows 3 tickets with a 1 business day response, Standard allows 10 tickets with a 4-hour response, and Premium allows unlimited tickets with a 2-hour response. Vates sells SLA-backed support, and its Enterprise plan includes 24/7 support. Compare the response times, ticket limits, and escalation paths in writing. Ask whether a response time is a commitment or a target, and who handles hardware issues.
What drives the yearly cost on each platform
On Proxmox VE, the recurring licence line is a support subscription priced per CPU socket per year. The Proxmox VE pricing page lists Community at 120 euros (no support tickets), Basic at 370 euros (3 tickets, 1 business day response), Standard at 550 euros (10 tickets, 4-hour response) and Premium at 1,100 euros (unlimited tickets, 2-hour response) per socket per year. Those figures are per socket, so a three-node cluster with two sockets per node carries six socket charges, and the total grows with every socket you add. The software is the same at every tier, so the choice is about support entitlements and access to the enterprise repository, not features. If you run without a subscription, the no-subscription repository is described as suited to testing and non-production use, which should be reflected in your budget and change-control plan. On XCP-ng, the hypervisor and Xen Orchestra carry no licence fee, and Vates describes commercial support subscriptions as the way to add SLAs. Vates lists VMS plans at $2,000 per year (Essential) and $4,000 per year (Essential+) for up to 3 hosts, Pro at $1,000 per host per year with a 3-host minimum, and Enterprise at $1,800 per host per year with a 4-host minimum and 24/7 support. Your yearly total therefore moves with host count and with the minimum that applies to the plan you choose. A small cluster may pay for a plan minimum that is larger than its host count alone would suggest, so compare the flat tiers and per-host tiers at your real host count. If you want hyperconverged storage, XOSTOR is a separate add-on at $800 to $1,200 per host per year, according to the Vates pricing and support page. Storage hardware is the cost that most often changes the comparison. Proxmox can use Ceph or ZFS for shared or replicated storage, and Ceph needs enough nodes and network capacity to run its own cluster. XCP-ng's XOSTOR add-on is the equivalent decision on its side. Staff time recurs on both platforms: upgrades, patching, backup testing and cluster maintenance. The quote should state the socket or host count, the tier or plan, the support response terms and whether storage add-ons are included. Ask the vendor or partner to confirm which support hours and response times each option includes, and ask for the yearly total at your current and planned host counts.
Moving VMs off vSphere: what transfers, what gets rebuilt, and in what order
This sequence moves workloads from vSphere in controlled waves, so each platform choice, storage design and rollback point is proven on low-risk VMs before production systems depend on the new cluster.
Inventory VMs and their dependencies
Your infrastructure team lists every VM with its operating system, disk layout, network port groups, storage datastores, backup jobs, monitoring agents, DNS entries and identity bindings such as domain join or LDAP-based access. Mark which VMs depend on each other and which are licensed in ways that tie them to a platform. The step is done when every VM has an owner, a wave assignment candidate and a list of rebuilt items, reviewed with the application owners. Ask each owner which VMs cannot tolerate a planned outage window, because that answer shapes the wave plan later.
Pick the target and confirm its support window
Decide between Proxmox VE and XCP-ng with the architecture, storage and support requirements from your evaluation in hand. For XCP-ng, confirm the release line you will standardize on and its support end date in the XCP-ng releases documentation, which lists XCP-ng 8.3 LTS as supported until November 30, 2028. For Proxmox VE, confirm the release you will deploy and how long the matching Debian release receives security support, as described in the Proxmox VE FAQ. Record the support tier you intend to buy, because this step produces a dated decision record that procurement and the platform team can both sign.
Build the target cluster with storage and HA
Your platform engineers build the target cluster on the hardware you validated, configuring networks, the storage layer and the high availability design. For Proxmox VE, high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. For XCP-ng, confirm the storage option you use, whether that is local storage, network storage or a commercial add-on such as XOSTOR, and the host count that your Xen Orchestra deployment needs. The step is done when a test VM survives a controlled node failure and restores from a backup job you configured on the new platform.
Test migration on non-critical VMs
Migrate a small set of low-risk VMs first, using the import path for each platform. For XCP-ng, Xen Orchestra includes V2V, which uses warm migration: it replicates data while the source VM runs, then syncs changed blocks after shutdown, and needs only HTTP access to the ESXi API. Confirm the ESXi version of your source hosts, because the XCP-ng migration documentation states that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V. Record the cutover downtime, boot behavior, driver changes and guest network results for each test VM. The step is done when every test VM boots, passes its application checks and has a rollback path to the original vSphere copy.
Rebuild backup, monitoring and identity integration
Disk images move through the import path, but the surrounding services do not. Your backup administrators recreate backup jobs and retention policies on the target platform, verify restore tests and retire vSphere backup schedules only after the new jobs succeed. Monitoring teams reinstall agents, reconnect alert routing and rebuild dashboards, because metrics and alerts do not follow a disk image. Identity owners reconfigure directory binding, service accounts and role mappings. Network and storage definitions, including VLANs, firewall rules and datastore mappings, are recreated as platform objects. The step is done when each rebuilt service has a documented owner and a test alert or restore that proves it works.
Move workloads in waves with rollback points
Group VMs into waves by dependency and business criticality, starting with systems that have few upstream and downstream links. For each wave, take a verified backup of the source VM, schedule the cutover with its owner, run the migration, and keep the vSphere copy powered off but intact until the application passes acceptance checks. Do not decommission vSphere hosts until the final wave has run through a full backup restore cycle. The step is done when each wave has a signed acceptance record, a rollback point you can name, and a list of open issues, with no unresolved items blocking the next wave.
Decommission vSphere after the final wave
Once every workload runs on the target platform and the rebuilt backup, monitoring and identity services have produced clean results for the agreed observation period, your team removes vSphere licenses from service, archives configuration exports and destroys or repurposes the old hosts. Confirm with your compliance and records teams what evidence of the migration they require, such as change records, backup restore logs and access reviews. The step is done when no VM depends on vSphere, the archive is complete and the change record is closed. For the detailed migration steps and tooling, the next read is the Proxmox VE migration guide at Migrate to Proxmox VE if Proxmox VE is your target platform, or the XCP-ng migration documentation if XCP-ng is.
Where implementation projects on each platform usually run long
On Proxmox VE, implementation projects usually slip in three places: the storage and network design, the three-node high availability setup, and the subscription and repository decisions. Choosing between Ceph and ZFS replication is not a configuration toggle. Ceph needs a cluster network and enough nodes and disks to meet your failure targets, while ZFS replication accepts a data loss window between sync cycles. Your team needs to settle the network layout, disk layout and failure assumptions before the first node is racked. High availability depends on at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, as described in the Proxmox VE High Availability wiki. Fencing tests need a maintenance window and someone who can pull power or network on a node. Subscription and repository choices also affect the rollout, since the enterprise repository requires a valid subscription key and is the recommended repository for production.
On XCP-ng, the usual delays come from three areas: the Xen Orchestra deployment and backup configuration, V2V testing against your actual ESXi versions, and the scope of the support contract. Xen Orchestra is the management plane for hosts, backups and migrations, so its placement, authentication and backup jobs need design time. Migration testing is the most common source of surprise. Xen Orchestra's V2V tool uses warm migration and needs HTTP access to the ESXi API, and the XCP-ng migration documentation states that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V. If any of your hosts run that version, plan an upgrade path or a different import route before the schedule is set. Support scope matters too: confirm which Vates support tier covers the hypervisor, Xen Orchestra and any add-ons such as XOSTOR, and who handles each.
For either platform, ask for a written scope with deliverables, acceptance tests and dates before work starts. The scope should name the storage and network design, the HA and fencing test plan, the backup restore test, the V2V pilot VMs and the support tier that applies after handover. Ask who on your side owns hardware, network changes, identity integration and change approval, because those tasks, not the software install, usually set the pace. Ask DeployOpen to state which assumptions the schedule depends on, such as hardware lead times and access windows, and what happens if a test fails. Quotes follow from this written scope, so a vague scope produces a vague quote.
Questions buyers ask before choosing between Proxmox VE and XCP-ng
What does a yearly subscription cost for Proxmox VE and XCP-ng?
The software is free on both platforms, so the yearly figure is the support and subscription line, and it depends on how you count sockets and hosts. Proxmox VE is priced per CPU socket per year: the Proxmox VE pricing page lists Community at 120 euros (no support tickets), Basic at 370 euros (3 tickets, 1 business day response), Standard at 550 euros (10 tickets, 4-hour response) and Premium at 1,100 euros (unlimited tickets, 2-hour response). Vates lists VMS plans at $2,000 per year for Essential and $4,000 per year for Essential+ (up to 3 hosts), $1,000 per host per year for Pro with a 3-host minimum, and $1,800 per host per year for Enterprise with a 4-host minimum and 24/7 support, per its pricing page. Add-ons such as XOSTOR storage at $800 to $1,200 per host per year change the total. Ask both vendors for a quote that lists every host, socket and add-on you need, and check whether the support level you need is included.
How long does a migration from vSphere take?
The duration depends on your VM count, disk sizes, network path and how much change each workload can tolerate, so no single figure applies. XCP-ng's Xen Orchestra includes V2V, which uses warm migration: it replicates data while the source VM runs, then syncs changed blocks after shutdown, and it needs only HTTP access to the ESXi API, according to the XCP-ng migration documentation. Proxmox VE documents its own migration path in its Migrate to Proxmox VE guide. The factors that set the schedule are the total data to copy, the bandwidth between source and target, the number of cutover windows, application testing and rollback planning. Note that the XCP-ng migration documentation states ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V, so confirm your ESXi version first. A fixed-scope plan from DeployOpen would set the duration in writing after the environment is reviewed.
Can our own team run Proxmox VE or XCP-ng without outside help?
A team with Linux administration, storage and network skills can run either platform, but each needs its own competencies. Proxmox VE runs on Debian and manages KVM, LXC, LVM, ZFS and Ceph, so operators need Debian and storage administration, plus cluster quorum and fencing knowledge if they use high availability. XCP-ng needs Xen, XAPI and Xen Orchestra administration, and its storage add-ons follow Vates's own model. Both need backup testing, patch routines and documented restore procedures. Ask yourself whether your staff has run a three-node cluster with shared storage, and whether someone can respond to a failed node outside business hours. DeployOpen can plan, implement, document and support either platform inside your infrastructure through retainers, but the internal skills to operate it still need to exist.
Which platform fits a team that already runs Ceph or Xen?
If you already run Ceph, Proxmox VE is the closer fit, because it lists Ceph RBD and CephFS among its supported network storage types, so existing Ceph pools can be attached to a Proxmox cluster. Ceph itself provides object, block and file storage on a single RADOS cluster, and its Tentacle (v20) release was published November 18, 2025 with estimated end of life June 1, 2027, per the Ceph releases page. If you already run Xen or XenServer heritage, XCP-ng is the closer fit, since it began as an open source version of Citrix XenServer and documents upgrades from XenServer and Citrix Hypervisor. Confirm your Ceph release and Xen version against the vendor's compatibility notes before you commit, and test your current storage network under failover load.
What happens when the support window ends?
Each platform handles end of life differently, so check the window for the exact release you plan to run. Proxmox VE versions are supported at least as long as the matching Debian release has Debian security support, roughly three years, and Proxmox VE 8 on Debian 12 reached end of life in August 2026, according to the Proxmox VE FAQ. XCP-ng publishes LTS windows: 8.3 LTS was released October 7, 2024 and is supported until November 30, 2028, while 8.2 LTS support ended September 16, 2025, per the XCP-ng releases documentation. Plan an upgrade path before the date, not after it. Budget time for host reinstalls or in-place upgrades, retest backups and confirm that your support subscription still covers the release you run.
What does a fixed-scope DeployOpen implementation include?
A fixed-scope engagement covers the work listed in the written scope, with deliverables and timelines agreed before work starts. For a hypervisor project that typically means planning the target design, installing and hardening the hosts, configuring storage and networking, migrating agreed workloads, setting up backups, documenting the environment and handing over to your operators. DeployOpen does not publish a price list, so the quote follows from the written scope. To keep the quote accurate, you should supply an inventory of hosts, VMs, storage, network segments and licenses, your compliance and backup requirements, access to the target infrastructure, named technical contacts and a decision on the support tier you intend to buy. Ongoing support, upgrades and testing are available as retainers.
Which platform costs less to leave later?
Both platforms are open source on the software side, so exit cost comes from data format, tooling and staff knowledge rather than license terms. Proxmox VE is licensed under AGPL-3.0, and its storage can use LVM, ZFS, NFS, iSCSI, Ceph and Proxmox Backup Server. XCP-ng's xcp repository is GPL-2.0, and its Xen Orchestra management layer is a separate tool. Before choosing, ask how each platform exports VM disks, how your backups restore on a different hypervisor, and which storage type you would be locked into. Write these answers into your architecture record, and test one restore on the second platform during the pilot. The size of this cost depends on your VM count, automation and backup tooling.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so the Proxmox VE or XCP-ng decision is tested against your hardware, network and storage before anything is committed. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We confirm host count, CPU socket count and cluster size to frame the platform choice and the support tier needed
- We record which VMware features your workloads depend on, such as HA, shared storage and backup jobs
- We agree in writing whether storage will use Ceph, ZFS, iSCSI or NFS, and which vendor support level applies
How we build
- We stand up a proof-of-concept cluster or host pair in your environment to test networking, storage and fencing
- We configure identity integration, role-based access, backups and monitoring against your existing controls
- We run a migration pilot on non-critical VMs, measuring downtime and validating restored guest operating systems
How we hand over
- We document the cluster layout, storage design, upgrade path and recovery runbooks for your operations team
- We prepare configuration and evidence packs that your auditors can review, without issuing any audit opinion ourselves
- We walk your administrators through day-two tasks such as adding nodes, patching and restoring from backup
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- We track vendor life cycle dates for your chosen release line and plan upgrades ahead of end-of-support deadlines
- We confirm with the vendor which support entitlements, response times and repositories your subscription actually includes
