Which fits XenServer renewals better: XenServer 8 or XCP-ng?
If your XenServer Premium renewal is priced per socket and you are weighing it against XCP-ng, the first question is whether the license fee buys something your team needs. XenServer 8 Premium fits when the organization already has a working Citrix support relationship, when administrators are trained on XenCenter and would lose time switching tools, and when per-socket licensing is already in the budget and approved through procurement. In those cases the renewal is a known cost with a known support path, and the migration risk is hard to justify on its own. Confirm the current license terms, the number of sockets per host, and whether the Citrix License Server setup still matches your pools before you sign anything.
XCP-ng fits when the goal is to remove the license fee while keeping the same Xen and XAPI foundation, since both products grew from that code. The trade-off is that you choose a support model. Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no license fees, and offers commercial support subscriptions that add SLAs, with pricing that depends on the plan, host count and add-ons such as XOSTOR. Ask Vates for a written quote that states what the support tier covers, how hosts are counted, and what happens to pricing as you add hosts. Teams that already run Xen Orchestra for backup or VMware to Vates migration may find the management side familiar, and the Vates pricing and support page is the right place to compare plans against your renewal quote.
The decision turns on four things: the support model you are willing to buy, the host count and how fast it will grow, the storage design (local disks, shared storage or a hyperconverged add-on), and the skills already on your team. Put the XenServer renewal and an XCP-ng support quote side by side for the same host count and the same three-year horizon, and add the one-time costs of testing and migration to both. A small pool with stable hosts and a trained XenCenter team often favors renewal, while a larger estate that wants to stop paying per socket and can accept a support contract usually favors XCP-ng. Whichever you pick, put the decision in writing with the host list, socket counts and owner.
Which XenServer or XCP-ng path fits your renewal, hardware and team
This table matches common XenServer situations to the path that usually fits best, with the reason tied to licensing, support and management. Read each row against your own socket count, host count, in-house skills and change window, then confirm the cost and support terms in writing before you decide.
| Scenario | Better fit | Reason |
|---|---|---|
| Renewal with a fixed socket count and no plan to buy paid support | XCP-ng | XCP-ng has no license fee, so the per-socket Premium cost and the Citrix License Server dependency fall away. Support is optional and bought separately from Vates. |
| Small pool that needs a vendor SLA | XCP-ng with a Vates plan | Vates lists Essential and Essential+ plans priced per year for up to 3 hosts, and Pro and Enterprise plans priced per host. Compare these with your current support quote before choosing a tier. |
| Large estate where per-host support costs grow quickly | Compare Vates plan types with XenServer renewal | Per-host Vates plans add cost with each host, while the Vates pricing page lists the minimum host counts for each tier. Model host count against both quotes. |
| Team already runs Xen Orchestra for backup and monitoring | XCP-ng | Xen Orchestra is the management, API and backup layer for XCP-ng, so existing runbooks, backup jobs and skills carry over with less retraining. |
| Team that relies on XenCenter and Citrix tooling | XenServer 8 or XCP-ng after a runbook review | XenCenter workflows must be mapped to Xen Orchestra before a move. Confirm which scripts, integrations and reports depend on XenCenter. |
| Host estate that must stay in place on current hardware | XCP-ng, after checking hardware support | XCP-ng and XenServer share the Xen and XAPI base, so the same hosts usually remain the target. Confirm driver, firmware and boot mode support in your hardware compatibility review. |
| Team that will self-support with no paid plan | XCP-ng, using community support and internal runbooks | No license or subscription fee applies. Your team carries patching, upgrades and incident response, so budget for staff time and tested runbooks. |
| Hosts still on Citrix Hypervisor 8.2 that need a path before the end of support | XCP-ng 8.3 LTS | XCP-ng 8.3 LTS is supported until November 30, 2028 according to the XCP-ng releases documentation, which gives a defined support window for an in-place upgrade. |
How per-socket Premium licensing compares with XCP-ng support plans
XenServer Premium is licensed per CPU socket, and the entitlements are tracked through the Citrix License Server that your hosts check in with. Each socket on each host counts, so the licence cost grows as you add hardware, and the exact current price for your socket count and edition has to come from a vendor quote. Ask the vendor to itemize the per-socket Premium licences, any License Server or support terms, and whether renewals change the rate. Those three items decide most of the recurring spend in a XenServer comparison.
XCP-ng takes a different approach. The hypervisor and Xen Orchestra, the management and backup tool from Vates, are open source with no license fee for the software itself. What you pay for is optional commercial support from Vates, which adds SLAs and is sold under plans that Vates prices per host or per pool, depending on the plan. Before you compare totals, decide which support level your operations team needs, whether you want a plan at all, and how many hosts and pools the quote will cover. The Vates pricing and support page lists the current plan structure.
Support lifecycles matter as much as the price. 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, so any pool still on 8.2 needs a planned upgrade. For XenServer 8, confirm the end-of-life and security update dates in writing with the vendor, since these determine how long your current licences and patch cadence remain valid. Put both lifecycle dates into the same timeline before you sign a renewal.
How XenServer 8 and XCP-ng compare on management, updates and support
This table compares XenServer 8 and XCP-ng across the areas that drive a renewal decision: licensing, management tooling, support, lifecycle, backup, storage and migration. Read each row as a starting point, then confirm feature parity for your exact XenServer version and hardware in your own environment before committing.
| Capability | XenServer 8 | XCP-ng 8.3 LTS |
|---|---|---|
| Hypervisor base | Xen hypervisor, dom0 control domain and XAPI toolstack | Xen hypervisor, dom0 control domain and XAPI toolstack, with QEMU for guest I/O, booted on bare metal |
| Licensing model | Per-socket subscription, with Premium Edition required for full features and the Citrix License Server to manage entitlements | No license fee for the hypervisor or Xen Orchestra under the open-source licenses; paid Vates support plans are optional |
| Management interface | XenCenter on Windows, the native Citrix management console | Xen Orchestra web interface, plus XCP-ng Center for local host tasks; confirm the tooling your team needs |
| Commercial support | Provided by Citrix under its support agreement; confirm terms and escalation path with your account team | Vates support subscriptions add SLAs; Vates pricing lists per-host plans such as Pro and Enterprise, so confirm the tier matches your host count |
| Lifecycle | Confirm current support dates for your XenServer 8 release with Citrix before planning | XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, per the XCP-ng releases documentation |
| Backup and disaster recovery | Depends on the tools and licenses you already use; confirm which Premium features and third-party products cover your recovery goals | Xen Orchestra provides backup and replication jobs; confirm the job types, retention options and restore tests your recovery objectives need |
| Storage add-ons | Storage options depend on your SAN, NFS or hardware vendor; confirm supported configurations | XOSTOR hyperconverged storage from Vates is priced at $800 to $1,200 per host per year, per the Vates pricing and support page |
| Migration tooling | Pool upgrades and VM moves are handled within XenServer and Citrix tooling; confirm the supported paths for your version | Xen Orchestra V2V warm-migrates VMs from ESXi 7 and later, while ESXi 6.x hosts are not supported for V2V, per the XCP-ng migration documentation |
Where the data sits and who controls the hypervisor
Moving from XenServer to XCP-ng changes less about where workloads run than about who holds the keys, the patch path and the audit trail. The cards below cover the decisions that stay with your team on either platform and the checks to run before you commit.
Data location and hosting
XCP-ng runs on hardware you choose, in your own data center or your own cloud accounts, and VM disks, backups and management data stay where you put them. Xen Orchestra can be deployed on your own servers as well. Confirm where the Xen Orchestra appliance, its database and its backup repositories sit, and whether any telemetry or license check leaves your network in your chosen configuration.
Patch sources and update control
Updates for XCP-ng come from the project's repositories, and your team decides when hosts are patched and which versions are staged in a pool. Under XenServer, Citrix updates are tied to an entitlement and a support relationship. Confirm with Vates which repositories are available without a commercial plan, and document how you will test and approve updates before they reach production pools.
Identity and access integration
Access to XCP-ng hosts and Xen Orchestra should flow through roles that your identity provider can govern, not through shared root passwords on each host. Check how the Xen Orchestra web interface and API accounts are created, how administrator groups are mapped, and how privileged sessions are logged. Pair this with a documented break-glass procedure for the case where the identity service is unavailable.
Audit evidence for compliance readiness
Auditors will ask who changed a pool, when a patch was applied and which backups were restored. XCP-ng and Xen Orchestra give you logs and configuration you can export, but you must decide how long to keep them and where they are stored. DeployOpen can prepare the controls, runbooks and evidence collection for a compliance assessment. It does not issue audit reports or certifications, which remain the work of an independent auditor or certification body.
Vendor relationship and support scope
Running XCP-ng without a commercial plan leaves you responsible for your own troubleshooting, with community channels and documentation as first resort. Vates support plans add SLAs and vendor-backed response. Ask Vates to state in writing what support covers, which hosts and pools fall under it, and how escalations and security advisories are delivered, so your risk owner can record the decision.
Exit path and data portability
Your hypervisor choice should not trap your VMs. Keep backups in a format you can restore elsewhere and confirm that exported disks can be read by another hypervisor. Xen Orchestra's V2V feature migrates from ESXi, so the same tooling is useful if you ever change platform again. Document the steps to export each VM and test one restore to a second environment before you rely on the exit path.
Managing pools with XenCenter or Xen Orchestra
If your team runs XenServer 8 pools today, XenCenter is the Windows console you already know. XCP-ng shares the same XAPI control plane, so pools, hosts and VMs keep their meaning, but the console you use day to day may change. XCP-ng is documented as managed through Xen Orchestra, so confirm with Vates whether your existing XenCenter workflows remain in scope before you depend on them.
- Pool and host tasks: Pool joins, master upgrades and VM lifecycle steps are the ones your runbooks already describe. Map each step to its Xen Orchestra equivalent during a pilot.
- Patching order: Host update order and rolling maintenance are the procedures most likely to need new runbooks. Confirm the update path in the XCP-ng releases documentation.
- Licensing checks: Premium license assignment and License Server checks no longer apply after the move, so remove them from monthly checklists.
- Access and audit: Role assignments and audit exports must be recreated in the new console. Confirm what the chosen tool records and how long it keeps it.
- Scripts and scheduled tasks: Identify which XenCenter-driven jobs have a working equivalent before cutover.
Before cutover, check that every routine task on your list has a tested replacement in the console your team will use.
Xen Orchestra is the management, API and backup tool from Vates, and it is the usual front end for XCP-ng. It is AGPL-3.0 licensed and runs as a service you host yourself, inside your own infrastructure. Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no license fees, while its commercial support subscriptions add SLAs.
- One browser console: Hosts, pools, storage and VMs are managed from a single web interface, so administrators do not need a Windows client.
- Backup scheduling: Backup jobs, retention and replication are set in Xen Orchestra. Document the schedule, retention period and restore test for each pool before go-live, and confirm the current options in the project documentation.
- Its own footprint: Xen Orchestra is a separate service with its own host, updates, TLS certificates and access control. Plan for those as part of operations.
- Support choice: Self-supported use and Vates subscriptions, priced per host or per pool, are different commitments. Ask for written scope on who responds to incidents and within what window.
- Upgrade cadence: Track Xen Orchestra and XCP-ng releases together, and test each upgrade on a staging pool first.
Before you commit, confirm which backup targets and retention settings your recovery objectives require, then run a full restore test.
Xen Orchestra includes V2V (VMware to Vates), which moves VMs from ESXi to XCP-ng using warm migration. Data is replicated while the source VM keeps running, and changed blocks are synced after shutdown, which keeps the final outage short. The tool needs only HTTP access to the ESXi API, so the migration path does not depend on installing software on the ESXi hosts. The XCP-ng migration documentation describes the supported paths.
- Supported hosts: Current Xen Orchestra versions support ESXi 7 and later. ESXi 6.x hosts are not supported for V2V, so those VMs need an upgrade of the source host or a different migration method.
- Datastore types: Disks can be read from VMFS, NFS or vSAN datastores. Confirm the datastore type behind each VM and the network path to it before scheduling.
- Cutover window: Warm replication limits downtime to the final sync after shutdown. Measure the actual window with a pilot VM before you set a change window.
- Network access: The Xen Orchestra server must reach the ESXi API and the datastore network. Firewall rules are a common reason migrations stall.
- Guest verification: Check boot settings, network mappings and guest tools on each imported VM, and record the results for your change records.
Before scheduling production moves, pilot one VM per operating system family and confirm the Xen Orchestra build and documentation version you tested.
Xen Orchestra is described as the XCP-ng management, API and backup tool, so platform teams can automate pool, VM and backup tasks instead of clicking through the web interface. The API is a good fit for infrastructure as code and for feeding status into monitoring. Confirm the exact endpoints and object model in the project documentation and repository before you build on them, since those details are not covered here.
- Infrastructure as code: Keep scripts that create or change VMs in version control, and test them against a lab pool before they touch production.
- Backup and reporting: Pull backup job status into your monitoring stack so failed jobs raise alerts. Confirm which objects and fields the API exposes for this.
- Credentials: Create dedicated service accounts with the minimum rights each job needs, rotate their tokens, and store them in your secrets manager.
- Version pinning: Pin the Xen Orchestra and XCP-ng versions in your pipelines, and promote upgrades only after a staging pool passes your tests.
- Audit trail: Log each API call in the calling system, because the audit record you need may differ from what the server keeps.
Before building automation, review the Xen Orchestra repository and confirm with Vates which API calls your scripts depend on and how they behave across upgrades.
What drives the cost of each side beyond the license line
On the XenServer side, the license line is only the start. XenServer 8 Premium is licensed per socket, so the recurring figure grows with every socket you add to a pool, and the Citrix License Server must be reachable and maintained for licenses to be issued and tracked. Ask your reseller or the vendor for the socket count you are billed on, the edition covered by your renewal, and whether the License Server runs on infrastructure you must patch and back up. Renewal terms set the next year's total, so confirm the term, any price escalation rules and whether vendor support is bundled or sold separately. A lapsed support entitlement changes what you can get on the next hotfix or incident. A hardware refresh that raises socket counts also moves the license total, even when the software version stays the same.
On the XCP-ng side, the hypervisor and Xen Orchestra carry no license fee, but support is a choice you make. Vates lists Essential at $2,000 per year 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, so the cheapest plan depends on your host count. As an illustrative four-host pool, Pro would total $4,000 per year and Enterprise $7,200 per year before add-ons. The Vates pricing and support page also lists XOSTOR hyperconverged storage at $800 to $1,200 per host per year if you need it. Without a plan, the effort stays with you: patching the XCP-ng 8.3 LTS hosts, updating Xen Orchestra, testing backups and running monitoring. Estimate that staffing with your own team or a partner, and confirm exactly what community channels cover before you rely on them.
Separate one-time work from recurring operations before comparing totals. One-time items include the pool upgrade or rebuild, warm V2V migrations from ESXi 7 and later (current Xen Orchestra versions do not support V2V from ESXi 6.x), validation of each migrated VM and the cutover runbook. Recurring items include license renewals on the XenServer side, Vates subscriptions and XOSTOR fees on the XCP-ng side, and staff hours for patching, restore tests and monitoring on both. When requesting a quote, ask for one-time and annual lines separately, the socket or host count each line is based on, the hours and response times the support tier covers, who performs patching and restores, and what changes at renewal. DeployOpen plans and implements work under a fixed scope agreed in writing and offers retainers for ongoing support. It does not publish prices, so a quote follows from your written scope.
What an in-place move from XenServer to XCP-ng involves
The sequence moves a XenServer pool onto XCP-ng with backups and tested restores in place before any production workload is cut over. Each step ends with a check that tells the team whether to continue.
Confirm the upgrade path in the documentation
The platform team reads the XCP-ng migration documentation and the XCP-ng releases page to confirm which XenServer or Citrix Hypervisor versions can upgrade to XCP-ng 8.3 LTS, which xapi versions are required, and which steps the documentation marks as mandatory. The team records the current XenServer build of every host and compares it against the documented path. The step is done when the team has a written upgrade path that names each host version, the target release and the owner who signed off. Confirm each step against current documentation before work starts, since the sequence and prerequisites change between releases.
Back up VMs and pool configuration
The storage or backup administrator exports the pool configuration and takes a verified backup of every VM that must survive the move, including VM metadata, networks, storage repository definitions and any HA or clustering settings. The team checks that backups are readable by performing a test restore on a separate host or in an isolated network. The step is done when every production VM has a backup that has been restored at least once in a test environment and the configuration export is stored off the pool.
Deploy Xen Orchestra for management and backup
The virtualization engineer installs Xen Orchestra from the sources recommended by Vates, connects it to the existing XenServer pool and confirms that inventory, performance graphs and backup jobs work. Xen Orchestra is open source, so its cost is in the server, the time to deploy it and the team's skill with it, rather than a per-host license. Running it before the upgrade gives the team a second management path, a backup job history and a way to watch the pool during the changes that follow. The step is done when Xen Orchestra lists every host and VM, and a backup job completes successfully against each storage repository.
Upgrade or rebuild the pool master first
The engineer takes the pool master out of production scheduling, disables HA and clustering as the documentation requires, and either upgrades the master in place to XCP-ng 8.3 LTS or rebuilds it on fresh hardware and rejoins it to the pool. Because the master holds the pool database and coordinates the other hosts, it goes first. The change window, rollback plan and firmware mode of the installation media should be confirmed in the documentation before the change. The step is done when the master boots on XCP-ng, reports the expected version, and the pool database and storage repositories are visible and healthy.
Rejoin and upgrade the remaining hosts
The engineer moves one host at a time out of the pool, upgrades it or rebuilds it, and rejoins it to the upgraded master. Each host has its VMs evacuated or stopped according to the plan, so that capacity remains for the workloads that stay running. Teams with mixed hardware or NIC drivers should test network and storage paths on one host before repeating the work on others. The step is done when every host is on the same XCP-ng version, every host reports healthy in Xen Orchestra, and the pool has passed its network and storage checks.
Test restores and failover on the upgraded pool
The operations team restores a sample of VMs from the backups taken earlier onto the upgraded pool, boots them in an isolated network, and checks application function, network connectivity and storage access. Where HA was in use, the team re-enables it only after the test confirms the expected behavior. The findings go into a written runbook. The step is done when the sample restores boot and pass application checks, and the team has signed off on the restore procedure for production use.
Cut over workloads in agreed waves
The change owner moves production workloads back onto the upgraded pool in waves that the application owners approved, starting with lower-risk systems. Each wave has a rollback point defined in advance, a named contact for each application and a monitoring check that runs after the move. The team keeps the backups in place until the agreed stabilization period ends. The step is done when every planned workload runs on XCP-ng, the post-cutover checks pass for each wave, and the retired XenServer media and licenses are removed from the change record.
What buyers ask before choosing XCP-ng or hiring help
What does moving from XenServer to XCP-ng actually cost, and which parts are one-time?
The switch has two cost groups. XCP-ng itself carries no license fee, so the recurring cost you can remove is the per-socket XenServer Premium license and its renewal. The one-time costs are planning, the upgrade and migration work, testing, and any hardware or storage changes. Recurring costs are optional Vates support subscriptions, which Vates prices per host or per pool on its pricing page, plus any storage add-ons such as XOSTOR, which Vates lists at $800 to $1,200 per host per year. Operations staff time and backup tooling recur too. Ask any partner for a quote that separates one-time work from annual items and states which Vates plan it assumes. The cost driver is host count and socket count, so compare your current renewal line by line against that breakdown.
How long does a XenServer pool migration to XCP-ng take?
The duration depends mainly on pool size, the number of VMs, their disk sizes, how much downtime each workload tolerates, and whether storage is shared. The XCP-ng migration documentation describes an upgrade path from XenServer and Citrix Hypervisor, and the usual sequence is to upgrade the pool master first, then the other hosts, with HA and clustering disabled during the work. Every VM move adds time, and warm migrations keep downtime short but still need a final sync window. Other drivers include the xapi version currently in use, how many hosts you can take out of service at once, and how much testing you require before cutover. No fixed duration is given here. Ask for a schedule in the written scope that lists these variables and the rollback point for each host.
Can our team migrate XenServer to XCP-ng without outside help?
Yes, many teams do the upgrade in-house, provided they have Linux and Xen administration skills, a tested backup of every VM, and a non-production pool to rehearse on. The documented path covers the upgrade and the migration tooling, and Xen Orchestra can manage the resulting environment. Outside help is most useful when the pool is large, when VMs have complex networking or storage, when the change window is tight, or when no one on staff has run a pool upgrade before. A fixed-scope engagement sets out what the partner does and what your staff does, so you can decide which parts to keep. Ask any provider to name who performs each step and what handover documentation you receive.
What does the migration need from our staff?
Expect to commit named people for the length of the project, not only for the cutover. Typically you need someone who owns the hypervisor and storage, someone who owns each application affected by a VM move, and someone who can approve change windows and rollback decisions. Staff also need to inventory VMs, document dependencies, confirm backup restores, and sign off on test results. Operations teams will need to learn Xen Orchestra for day-to-day management and backup jobs. Ask the provider for a RACI-style list in the scope and for a training or handover plan that covers both the platform and the runbooks you will keep.
Is XCP-ng supported for production workloads?
XCP-ng is widely deployed as a production hypervisor, and its current long-term support release is 8.3 LTS, released on October 7, 2024 and supported until November 30, 2028. The 8.2 LTS line reached end of support on September 16, 2025, so any plan should target 8.3 LTS. Support in the open-source sense comes from the community and documentation, while Vates offers commercial support subscriptions that add SLAs and 24/7 coverage on its higher plans. Confirm the exact support tier you need before go-live, check the release notes for each patch level, and make sure your backup and recovery tests cover the post-migration environment.
Does DeployOpen offer fixed-scope XCP-ng implementation?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work begins. Work can cover the pool upgrade, migration planning and execution, backup design, documentation, and handover, and ongoing support or upgrades can run as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope document to list the hosts, VMs, storage, and acceptance tests included, and to name what is excluded.
What should we check before deciding between XenServer and XCP-ng?
Start with your current licence position and renewal date, the number of sockets and hosts, and whether you depend on any XenServer-only feature or third-party tool. Then check your VM inventory, the storage type, backup jobs, and the xapi version on each host. Confirm your Xen Orchestra plan and whether you need the XOSTOR add-on. Finally, decide who will run the platform after go-live. These checks show whether the migration is a licensing decision alone or also a skills and tooling decision. Ask any partner to review them in writing before quoting.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For XenServer vs XCP-ng, we start with your pool inventory, licensing position and management workflows, then agree a written scope before any work begins.
How we scope
- We inventory XenServer pools, hosts, sockets, license server use and current Xen versions before recommending a path.
- The written scope names which pools move to XCP-ng 8.3 LTS, which stay put, and what is excluded.
- We agree in writing how Xen Orchestra, backup and storage are covered before any work starts.
- Engagements are fixed-scope, with scope, deliverables and timelines confirmed in writing before work begins.
How we build
- We build a test pool on the target hardware and rehearse the upgrade or rebuild steps before production.
- We configure Xen Orchestra, role-based access, backup jobs and monitoring in your own cloud or data center.
- We test VM moves with warm migration where the source supports it, and record downtime observed for each workload.
- We validate HA, networking and storage behavior against the rollback steps agreed in the scope.
How we hand over
- You receive runbooks for pool upgrades, host maintenance, backup restores and Xen Orchestra administration.
- We document the license position, support subscription choices and the decisions behind each design.
- We run knowledge transfer sessions with your administrators so operations stay in your team.
- Evidence for change records and compliance assessments is delivered, though audit opinions come from independent auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover patch cycles for XCP-ng and Xen Orchestra, aligned to the support lifecycle you confirm with Vates.
- We can run periodic restore tests and review backup coverage as the estate changes.
- Confirm the SLA, response times and retainer terms in the written quote, since these vary by agreement.
