Citrix Hypervisor 8.2 end of life: XenServer 8 or XCP-ng

Citrix Hypervisor 8.2 end of life: what hosts still running it must decide now

For hosts still on Citrix Hypervisor 8.2 CU1, the decision is whether to renew XenServer 8 Premium or move to XCP-ng 8.3 LTS. The short answer: if the aim is to stay on the Xen and XAPI lineage and avoid per-socket licensing, XCP-ng 8.3 LTS is the direct path, because the move is an in-place upgrade within the same toolstack. Proxmox VE is a different decision, since it changes the hypervisor to KVM and requires moving every VM. Citrix Hypervisor 8.2 CU1 reached end of life on June 25, 2025, so these pools no longer receive fixes, and a licensing renewal forces the choice now.

The licensing comparison comes down to what each side charges for the same pools. XenServer 8 Premium is licensed per socket, so the price rises with every socket you add to the pool. XCP-ng is GPL-2.0 licensed with no license fee for the hypervisor or Xen Orchestra, and Vates describes commercial support as an optional layer that adds SLAs. Vates prices its VMS plans per host, with a 3-host minimum on Pro and a 4-host minimum on Enterprise, according to its pricing page. Ask XenServer resellers for a written per-socket quote for your current socket count, and ask Vates for the plan that matches your host count and support hours, so both totals cover the same term.

Before you commit, confirm the version path and the support window. XCP-ng 8.2 LTS support ended September 16, 2025, so the target is 8.3 LTS, which is supported until November 30, 2028, according to the XCP-ng releases documentation. Inventory each pool's sockets, hardware, and backups, and check that your servers appear on the XCP-ng hardware compatibility list before scheduling any work. The step-by-step checks, including upgrading the pool master first and disabling HA, appear in the migration section of this page. Set a decision date and record who signs off on the license or support choice.

What an end-of-life hypervisor upgrade must satisfy

An upgrade away from Citrix Hypervisor 8.2 has to meet five requirements before it is safe to schedule. The cards cover a supported release, a maintained patch path, management and backup, storage and hardware fit, and a license cost the budget owner can explain.

A supported target release

The destination must be an XCP-ng release with a published end of support date that outlasts your planning horizon. XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028. XCP-ng 8.2 LTS support ended on September 16, 2025, so an 8.2 pool cannot be the destination. Check the releases page for the support window of any point release you plan to deploy, and confirm it in writing with your vendor before the change window is approved.

A maintained patch path

Once a host runs an unsupported release, security fixes stop reaching it, so the patch path matters as much as the first install. Record the current version and patch level of every host before you begin. Upgrade the pool master first so the remaining hosts follow a supported version. Confirm that each host can reach its update source after the upgrade, and document who approves patches once the pool is running the new release.

Management with backup and VM operations

Someone must run VM operations after the upgrade, so decide the management layer before the first host is touched. Xen Orchestra covers backup, VM operations and the V2V path for VMware workloads from ESXi 7 and later, and it is licensed AGPL-3.0. Confirm that backup jobs, snapshots and restores work on the upgraded hosts. Test a full restore of one VM from each backup job, and record the retention settings you actually use, not the ones you remember.

A licensing model the budget owner explains

XenServer 8 is licensed per socket, and Premium is the only licensed edition in this context. XCP-ng and Xen Orchestra carry no license fee, and Vates describes its commercial support subscriptions as the way to add SLAs. Vates lists 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. Request a written quote that states host count, support hours and response terms.

Storage and hardware fit

Decide whether the pool needs shared or hyperconverged storage before you commit to a support plan. Vates sells XOSTOR hyperconverged storage at $800 to $1,200 per host per year, a recurring cost that sits on top of host support. Confirm that the network, storage and HBA hardware in each host is supported by the target XCP-ng release, and confirm the boot firmware mode of each host before you boot any installation media.

XenServer 8 Premium or XCP-ng 8.3 LTS: how each path meets the constraint

XenServer 8 keeps the hypervisor, licensing and support with one vendor, which suits teams whose policy requires a single contract for the platform. Licensing is per physical CPU socket and only the Premium Edition is offered, so the annual cost follows the socket count of every host in the pool, including hosts you add later. Entitlements are served through the Citrix License Server, which you must keep reachable from the hosts. No XenServer price is given here, so request a written quote for your socket count and term.

Licensing model: cost scales with sockets, so a pool expansion or a hardware refresh changes the bill.
License Server: confirm how the server is deployed, what happens to running hosts if it is unreachable, and whether an offline option exists for your network.
Vendor support: support terms, response targets and any upgrade assistance from an end-of-life 8.2 CU1 host are set by the contract, so ask for them in writing.
Entitlement transfer: confirm whether your existing Citrix Hypervisor entitlements carry over and what paperwork the move requires.
Recurring charges: check whether renewals are annual and how a true-up is calculated if your socket count rises.

Before committing, ask the vendor to confirm the end-of-life date for XenServer 8 in writing.

How an in-place upgrade to XCP-ng 8.3 LTS keeps VMs running

An in-place upgrade works because XCP-ng documents upgrades from XenServer and Citrix Hypervisor, and because the two products share the Xen hypervisor and the XAPI toolstack. The pool members, their storage repositories and their VM definitions carry across the change, so the work is replacing the control stack on each host rather than rebuilding the environment and re-importing guests. That is the main reason this route usually involves less change than a move to a different hypervisor. Confirm the supported upgrade paths for your exact current version in the XCP-ng migration documentation before scheduling anything.

The order of operations matters more than the individual steps. The pool master goes first, because the other hosts depend on it for pool control, and the remaining members follow once the master is running the new release. Before any host is touched, high availability and clustering must be disabled so the pool does not try to restart or fence VMs while hosts are rebooting. Plan for the pool to be in a degraded state during the window, and check that every host has been evacuated of workloads that cannot tolerate a restart. The ISO and firmware mode also deserve attention: the installer must boot in the same firmware mode (UEFI or legacy BIOS) that the existing host uses, or the upgrade will fail at boot.

Downtime comes from three places: host reboots, VM shutdowns for guests that cannot be live-moved during the change, and the time spent verifying each host before the next one is taken out. Reboots are fixed by the number of hosts, so a pool with more members has more windows to manage. Guest shutdowns depend on each VM's tolerance and on whether the storage and network configuration is consistent across hosts before the change. Ask your vendor or partner to confirm, for your hardware, whether any driver or firmware updates are needed before the upgrade and what a rollback looks like if a host fails to return. Your change plan should name the owner of each host, the backup that exists for every VM, and the criteria for stopping the upgrade partway through.

How to upgrade hosts safely before the next maintenance window

This sequence moves each XenServer or Citrix Hypervisor pool to a supported XCP-ng release with the VMs, pool metadata and management tooling intact, and it leaves a documented rollback point at every stage. Your team confirms each step against the XCP-ng migration documentation and its own environment before the change window opens.

Inventory hosts, pools and versions
Record every pool, its master, each host's current XenServer or Citrix Hypervisor build, CPU and memory, storage repositories, network bonds and the VMs running on each host. Note which hosts are still on 8.2 CU1 and which VMs use features such as GPU passthrough or vGPU, since those need checking later. Confirm the inventory with the pool owners and the XCP-ng migration documentation. The output is a signed-off inventory that lists the upgrade order.
Back up VMs and pool metadata
Take a full backup of every VM that must survive the change, and export the pool metadata so the configuration can be rebuilt if an upgrade fails. Store the copies outside the pool, and test at least one restore on a separate host before relying on them. Your backup tool and retention rules come from your own policy, so confirm them with the backup owner. The output is a restore test log and a documented rollback path for each pool.
Confirm hardware and firmware compatibility
Check each server model, BIOS or UEFI firmware version, network and storage controller, and any add-in cards against the XCP-ng hardware and release notes for the target version. Confirm the boot mode in use, because the installer must boot in the same firmware mode as the original install. Ask your hardware vendor for firmware advice where a driver is unclear. The output is a compatibility sheet with a clear yes, no or needs-action status for each host.
Rehearse the upgrade on a test pool
Build a test pool from hardware or nested hosts that mirror production, and run the full upgrade path there, including the pool master first, followed by the remaining hosts. Load representative VMs, then record any errors, driver issues or storage path changes. Repeat the rehearsal until the steps run without manual fixes. The output is a tested runbook with the exact commands and checks used in production.
Upgrade the pool master first
Disable high availability and clustering on the pool before the move, then evacuate the master and upgrade it first, following the order in the runbook. Confirm that the master rejoins the pool, that storage repositories reattach, and that the XAPI toolstack reports the expected version. Keep the other hosts running their current release until the master is stable. The output is a healthy master with a verified pool state before any other host changes.
Upgrade remaining hosts and restore clustering
Move the remaining hosts one at a time, evacuating VMs with live migration where the hardware and storage allow it, and checking each host before the next one starts. Re-enable high availability and clustering only after every host runs the target release and the pool reports no errors. Confirm the settings match the inventory from the first step. The output is a fully upgraded pool with HA and clustering restored and documented.
Validate VMs and management tooling
Start or check each VM against its pre-change record, then test application access, network paths, storage performance and backup jobs. Confirm that Xen Orchestra, XenCenter or any other management and monitoring tool connects to the upgraded pool and reports correct inventory, metrics and backup status. Record any VM that needs tool or driver updates. The output is a signed validation report that the service owners accept before the change is closed.

Questions buyers ask before choosing XenServer 8 or XCP-ng

Can we run XCP-ng without a support contract?

Yes. Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no limits and no license fees, so the software itself carries no license cost. A commercial support subscription is optional and adds SLAs and vendor support. The trade-off is that your team carries the troubleshooting, patch testing and upgrade planning that a support contract would otherwise share. Before you commit, confirm with your own engineers that they can own incident response for the pool, and decide whether an external partner or a Vates plan covers the gaps. Check the XCP-ng releases documentation for the support window of the branch you plan to run.

What does an in-place upgrade need from our internal team?

The team needs people who can administer XenServer pools, plan a maintenance window and validate workloads after each host changes. In practice that means someone who knows the pool master, the HA and clustering settings, the storage repositories and the backup jobs, plus someone who can run application tests after reboot. Work through the XCP-ng migration documentation before scheduling, and record the xapi versions, firmware mode and network layout of every host. Ownership should be named in writing: one person for the pool, one for application owners, and one for rollback decisions.

How long does the upgrade take, and what drives that time?

The supplied facts do not give a duration, so treat any number you hear as an estimate that needs testing in your environment. The main drivers are the number of hosts, how many VMs must be stopped or moved to keep downtime low, the storage type, and how many application teams must sign off. A pool with clean backups, documented configuration and a lab rehearsal moves faster than one where configuration is discovered during the change window. Ask any provider for a written plan that lists the steps per host, the rollback point for each stage and the workloads that need downtime, then compare that plan against your own change calendar.

Do we need a consultant for the move?

Not always. A team with Xen or XenServer experience and time for rehearsal can upgrade a small pool alone. A consultant is worth considering when the pool is large, when the team has not run Xen before, when the change window is tight, or when auditors will ask for evidence of testing and rollback. DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. You can also ask for a scoped rehearsal on a non-production pool first, which gives you a concrete estimate before you commit to the full pool.

What does a Vates support plan add to XCP-ng?

A Vates plan adds commercial support, which the Vates pricing and support page describes as the layer that brings SLAs on top of the free software. The published plans differ by host count and support level. Vates lists Essential at $2,000 per year and Essential+ at $4,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. Add-ons such as XOSTOR storage are priced at $800 to $1,200 per host per year. Confirm current rates on the Vates pricing and support page before you budget, because these figures are the ones supplied for this page.

How do we compare a per-host plan with a per-socket license?

Start by counting the units each model charges for. XenServer Premium is licensed per socket and managed through the Citrix License Server, so the license bill rises with socket count across every host in the pool. Vates plans are priced per host, with Essential and Essential+ quoted as flat yearly amounts for up to 3 hosts, so the comparison depends on host count and socket density. Put both numbers on one sheet for three years, including renewals, add-ons and the staff time for upgrades. Then ask each vendor for a written quote tied to your exact host and socket counts, and note which costs are one-time (the move, testing, training) and which recur (licenses, support, storage add-ons).

What should we do with hosts on ESXi 6.x or unsupported hardware?

These are separate problems and should be handled separately. The XCP-ng migration documentation states that current Xen Orchestra versions do not support ESXi 6.x hosts for V2V, so VMs on those hosts need another route, such as exporting disks and importing them, or rebuilding the workload on the target platform. For hardware, confirm compatibility with the XCP-ng hardware compatibility guidance and the current release notes before buying or reusing servers. Hosts that cannot run the target version should be retired or moved to a different workload plan. Record each exception in your change log so auditors can see the decision and the owner.

Evidence to keep for the upgrade and the audit trail

An upgrade from Citrix Hypervisor 8.2 leaves a trail that auditors and internal reviewers will ask about: what ran where, how it was protected, what changed and what was verified afterward. The six records below connect those questions so the same evidence answers both the upgrade review and later assessments. DeployOpen can prepare this evidence, but independent auditors and certification bodies issue any assessment or attestation.

Pre-upgrade inventory and version record

Record every pool, host, and VM before any change, including the Citrix Hypervisor 8.2 build on each host, the XAPI version, storage repositories, network bonds, and the VM list with its power state and assigned owner. Capture the pool master and the order in which hosts will be upgraded. Without this baseline, a later question such as whether a VM was present before the upgrade cannot be answered from records. Ask your team to export the inventory from the existing management tools and store it with a timestamp outside the hosts being changed.

Backup and restore test results

A backup only counts as evidence once a restore has been tested. Keep the backup job definitions, the backup completion logs, and the results of at least one restore per VM class (for example, a Windows server, a Linux database host, and a VM with multiple disks) into a test environment. Note the restore time and whether the application started correctly. Record who performed the test and when, so the record can be reproduced if an auditor asks for it.

Change records for each host and pool

Each host and pool upgrade needs its own change record: the target XCP-ng 8.3 LTS image, the approver, the maintenance window, the steps taken, and any rollback decision. Keep the disabled state of HA and clustering before and after each step, and note when VMs were migrated off a host. Separate records per host make it possible to show that the pool master was upgraded first and that no host was returned to service with an unverified state.

Post-upgrade validation of VM state

Compare the post-upgrade VM list against the baseline inventory and confirm that every VM starts, has its expected network and storage attachments, and passes an application-level check set by its owner. Record any VM that required a driver change, a guest tools update, or a configuration correction. Keep the comparison output with the change record so it is clear which VMs were verified, by whom, and against which test.

Support lifecycle record for the chosen release

Document the support dates for the release you choose and the dates of the release you are leaving. 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. Keep a copy of the lifecycle page with its retrieval date and assign an owner for the next review. This record shows that the platform was chosen with its end of support in view, which is a common question in risk reviews.

License and subscription documentation

Keep the record of what support or subscription terms apply to each host, including any Vates support plan, its billing basis per host or per pool, and the term and renewal date. If the platform is run with no commercial support, record that decision and who accepted the risk. Also keep records of any XOSTOR storage add-on, since storage licensing is tracked separately. Ask Vates for the written terms that apply to your environment and file them with the change records.

What to confirm with Citrix and Vates before you commit

Before you commit to either path, put the open questions to each vendor in writing and treat their answers, not this page, as the basis for the decision. With Citrix, ask for the current XenServer 8 Premium terms for your socket count, the renewal price and term, and the exact date when your existing entitlement ends. Ask whether the edition you need requires a Citrix License Server on your network, how it is licensed and what happens to running hosts if the license lapses. Confirm whether any entitlement or upgrade path from your current Citrix Hypervisor subscription applies, and whether your support contract still covers the hosts you plan to keep. With Vates, the questions are about scope. Ask which Vates VMS plan matches your host count and whether the plan is priced per host, per pool or as a flat tier, since the difference changes cost as you grow. Confirm the minimum host count for each plan, what the SLA and support hours cover, and whether the plan includes upgrade assistance for the move to the target XCP-ng release. If you run shared storage, ask whether XOSTOR is needed, which hosts it would apply to, and whether it is priced separately per host per year. Request the written scope of every item.

Hardware support deserves its own written answer. Ask Vates and your hardware vendor to confirm, for the target XCP-ng release, which server models, storage controllers, network cards and firmware levels are supported, and whether your current boot mode and firmware settings need changes. Ask for the end-of-support dates for the release you plan to run, and which step your upgrade path requires if you are not on the latest supported point release. Also ask whether the vendor has tested your hardware generation with your management tooling and backup software. Finally, ask each vendor to state in writing what they do not cover. Typical gaps include migration labor, validation of virtual machines after the move, and training for your operations staff. Keep the quotes as separate line items so you can compare the cost of each path on equal terms. The decision you need to make is which quote, with its written scope, carries less risk for your environment.

How DeployOpen works on this

DeployOpen plans and implements XenServer to XCP-ng upgrades inside your own infrastructure, starting from a written scope that covers each host still on Citrix Hypervisor 8.2. The work is fixed-scope, so pool layout, checks, cutover sequence and deliverables are agreed in writing before any host is touched.

How we scope

Inventory every pool, host, xapi version and firmware mode still running Citrix Hypervisor 8.2 CU1, which reached end of life on June 25, 2025.
Record which hosts are candidates for XenServer 8 Premium licensing and which are candidates for in-place upgrade to XCP-ng 8.3 LTS, with the reasons for each.
Agree in writing which VMs, storage repositories, HA settings and backup jobs are in scope, and what the deliverables and timeline look like.

How we build

Test the upgrade path on a non-production pool first, confirming boot behavior in the original firmware mode before any production host changes.
Sequence the upgrade with the pool master first, with HA and clustering disabled during the change window, and verify each host before moving on.
Plan VM moves to keep downtime low, and check Xen Orchestra management, backup and monitoring against your existing runbooks.

How we hand over

Deliver written runbooks covering the upgrade steps, rollback points, pool configuration and the checks that confirmed each host.
Document the final state of licensing, management tooling and support entitlements so your team knows what is recurring and who provides it.
Walk your operations staff through the handover so they can run routine patching and host maintenance without DeployOpen on call.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Confirm with Vates which commercial support plan, if any, you want for SLAs, since XCP-ng and Xen Orchestra are open source and support is a separate purchase.
Plan the next XCP-ng LTS upgrade window early, since XCP-ng 8.3 LTS is supported until November 30, 2028.