When teams leave vSphere but want something that feels like vSphere, a central management plane, pools, live migration, and a commercial support option, XCP-ng is the usual answer alongside Proxmox. XCP-ng is an open-source, Xen-based hypervisor backed by Vates, managed through Xen Orchestra (XO), which plays the role vCenter does. This guide covers the mapping and the migration mechanics.
Why XCP-ng rather than Proxmox
Both remove license cost. The practical difference is operational shape: Proxmox is per-node web UIs over a KVM hypervisor; XCP-ng separates the hypervisor from a single central console (Xen Orchestra) that manages every pool, which many vSphere admins find more familiar. Vates sells support and the turnkey XOA appliance, so there is a clear commercial safety net. The hypervisor is Xen (HVM guests) rather than KVM, a difference that rarely matters for ordinary Linux and Windows VMs.
What comes with the switch
You gain centralized management, live migration, HA, and a strong built-in backup engine (full/incremental, continuous replication, backup to S3) at no license cost. You give up VMware’s mature partner ecosystem and the deep NSX/vSAN/SRM integrations. As with any open platform, you take on more operational ownership unless you buy Vates support.
Architecture mapping
- vCenter → Xen Orchestra. One console manages all pools.
- Cluster → XCP-ng pool, with a pool master coordinating members.
- vSphere HA → XCP-ng HA, which requires shared storage for the heartbeat.
- DRS → the load-balancing plugin in Xen Orchestra (manual or scheduled).
- vSAN → XOSTOR (LINSTOR-based hyper-converged storage) or conventional shared storage.
- VMFS datastores → Storage Repositories (SRs): local LVM, NFS, iSCSI/HBA, or XOSTOR.
- Distributed vSwitch / port groups → XCP-ng networks with VLAN tags.
Moving VMs with Xen Orchestra
The standout feature is Xen Orchestra’s built-in VMware import (V2V). Connect XO to vCenter or a standalone ESXi host and it lists the VMs for direct import into an SR. Crucially it supports warm migration: XO copies the VM while it runs, then takes a short final delta sync at cutover, which keeps downtime to minutes rather than the length of a full disk copy. For one-off cases you can also import from disk or an exported appliance.
Post-import, the steps that matter: remove VMware Tools before or right after the move, install xe-guest-utilities (the XCP-ng guest tools) so the platform sees the IP and can do clean shutdowns, confirm the guest boots as HVM, match UEFI vs BIOS firmware to the source, and re-check the NIC and static IP.
Backup and DR, included
Don’t bolt on a separate backup product on day one, Xen Orchestra already does scheduled full/incremental backups, continuous replication to a second pool or site, and backup to S3-compatible object storage. Re-baseline backups during the pilot and keep the old VMware backups read-only until their retention ages out.
Where the mapping runs out
A handful of vSphere features have no direct XCP-ng equivalent and need a decision before you commit:
- NSX and the distributed firewall. XCP-ng networks carry VLAN tags, but the NSX overlay and distributed firewall do not import. Recreate segmentation with pool networks plus guest or perimeter firewalls, and validate east-west traffic on the pilot.
- vSAN storage policies. Resilience on XCP-ng comes from your SR choice (shared array, or XOSTOR for hyper-converged) rather than per-VM SPBM policies, so translate the intent of each policy into a storage design.
- Fault Tolerance. XCP-ng provides HA restart, not lockstep FT. Zero-RPO workloads need application-level clustering.
- VMware-certified Citrix or ISV stacks. If an application specifically certifies against vSphere, confirm its stance on XCP-ng before cutover.
What to confirm on each VM
Confirm the same items on every migrated VM so the runbook stays dependable:
- The guest boots as HVM on the correct firmware (UEFI vs BIOS matched to the source).
- xe-guest-utilities is installed and XO shows the guest IP; a clean shutdown from XO works.
- VMware Tools has been removed so no stale drivers linger.
- The VM landed on the intended network with the right VLAN tag, static IP, gateway, and DNS.
- The VM sits on a shared SR if it needs HA or live migration.
- A backup runs in XO and a test restore boots successfully.
- HA is enabled where required and a live migration between pool members succeeds.
Rolling it out wave by wave
Pilot a handful of low-risk VMs end to end: warm-import, install guest tools, validate, run a backup/restore, then test HA by failing a pool member. Capture the runbook and timings, then migrate wave by wave, pool by pool. Keep source VMs intact through a hypercare window so rollback is immediate.
Where this leaves you
XCP-ng + Xen Orchestra gives vSphere refugees the centralized, vCenter-like experience without the subscription, plus a strong native backup story and warm V2V that minimizes downtime. The risks are operational, not technical, plan your SR/storage model, install guest tools, and validate HA before decommissioning. Model your savings with the calculator above and confirm them against a Vates or partner quote.