Most hypervisor migrations mean a format conversion and a lot of validation. This one is unusual: XCP-ng is a community fork of the very platform you are already running. When Citrix (now Cloud Software Group) tightened XenServer licensing and tiering, the Vates-led XCP-ng project picked up the open-source Xen/XAPI base that XenServer is built on and continued it without the per-socket subscription. Because the underlying toolstack (XAPI), the disk format (VHD), and the management API are shared lineage, you are moving between close cousins rather than across an architectural gap.
Why teams are leaving XenServer
The driver is commercial, not technical. Cloud Software Group’s repricing and the move to subscription tiers raised costs and put previously-included features (and the free edition’s limits) behind paid plans. XCP-ng offers the same Xen-based virtualization with no license fee, optional commercial support from Vates, and Xen Orchestra as the management plane in place of XenCenter.
The management plane: Xen Orchestra
The first thing to stand up is Xen Orchestra (XO), it is both your XenCenter replacement and your migration tool. You can deploy it from the Vates appliance or build XO from sources. Once XO can see both your existing XenServer pool and a new XCP-ng host/pool, you have two clean migration routes.
Route 1, warm migration (minimal downtime)
XO can perform a warm migration of a running VM from the XenServer pool to the XCP-ng pool: it copies the disks while the VM runs, then does a brief final sync and cutover. This is the lowest-disruption path and the reason most teams treat XenServer → XCP-ng as a near-live move rather than an outage. Migrate a small, low-risk VM first, validate it end to end, then move workloads in scheduled waves.
Route 2, XVA export/import (offline, portable)
For air-gapped pools or where you would rather not connect both pools at once, export each VM to an XVA file and import it onto XCP-ng:
xe vm-export vm=<name-or-uuid> filename=/mnt/export/<name>.xva
# then on the XCP-ng host:
xe vm-import filename=/mnt/export/<name>.xvaIt is slower and needs staging storage, but it is completely decoupled and trivially auditable.
The details that actually bite
- Guest tools: replace Citrix VM Tools with XCP-ng guest tools inside each VM after migration, don’t leave the Citrix tools installed, as stale drivers cause the usual networking/disk quirks.
- Storage repositories: re-create or re-attach your SRs on XCP-ng (local LVM/EXT, NFS, iSCSI). Shared SRs make warm migration and HA far smoother, design this before you move workloads.
- Networking: map XenServer networks/VLANs to the XCP-ng pool’s networks up front so VMs land on the right bridges.
- Pool sizing: stand up the XCP-ng pool with enough headroom to receive waves; you can later repurpose the freed XenServer hosts into the XCP-ng pool once they’re empty.
Don’t skip validation just because it’s close
Because the platforms are so close, the temptation is to skip validation. Don’t. Confirm the same items on every migrated VM so a shared-lineage assumption never hides a real problem:
- The VM boots to a login prompt on the correct firmware (UEFI vs BIOS matched to the source).
- Citrix VM Tools has been removed and XCP-ng guest tools are installed and reporting the IP into Xen Orchestra.
- The VM landed on the right XCP-ng network with the correct VLAN tag, static IP, gateway, and DNS.
- The VM sits on a shared SR if it needs HA or live migration between pool members.
- A backup runs in Xen Orchestra and a test restore boots successfully.
- HA is enabled where required and a live migration across pool members succeeds.
Cutting over, and backing out
The near-live nature of this migration makes rollback simple, but only if you preserve the source. Warm migration copies the VM rather than moving it, so the original stays on the XenServer pool until you delete it. Keep each migrated VM’s source powered off but intact through a hypercare window, so if validation fails you simply power the original back on and no data is lost. Cut over one wave at a time and update DNS, monitoring, and backup jobs to point at the XCP-ng copy only after acceptance. Once a wave is stable and the source has aged out of its hypercare window, you can wipe the freed XenServer hosts and join them to the XCP-ng pool to grow capacity, which turns the old estate into headroom for the next wave.
What leaving Citrix costs you
You are leaving Citrix’s commercial support and certifications. If you run Citrix products that specifically certify against Citrix Hypervisor (some Citrix VDI stacks historically did), confirm their stance on XCP-ng before committing. Vates sells production support for XCP-ng and Xen Orchestra if you want an SLA and a vendor to call; many run it community-supported.
The short version
XenServer → XCP-ng is among the lowest-friction hypervisor migrations precisely because XCP-ng is a fork of the same platform: shared XAPI, VHD disks, and Xen Orchestra warm migration mean most VMs move with minimal downtime. Stand up XO and a properly-sized XCP-ng pool with shared storage first, pilot one VM, then move in waves, swapping Citrix tools for XCP-ng guest tools as you go. Confirm any Citrix-specific certification needs before you decommission, and model the removed per-socket subscription against optional Vates support in the calculator above.