Which hypervisor fits a Hyper-V estate: Hyper-V or XCP-ng?
Hyper-V stays the better fit for many estates, and the decision is less about hypervisor features than about what your organization already owns. If most workloads are Windows Server applications, your team runs Windows administration daily, and you hold Windows Server Datacenter licenses with System Center entitlements, the hypervisor itself may cost you little extra. Its guest licensing, management tooling and Active Directory integration already sit inside your existing Microsoft agreements. Moving away makes sense only when the per-core renewal is the main pressure and you can plan the Windows guest licenses that still apply after a change of host platform.
XCP-ng with Xen Orchestra fits better when operations lean toward Linux, when per-core licensing is the main cost driver, and when your team is willing to learn Xen tooling. XCP-ng is a type-1 hypervisor built on the Xen hypervisor and the XAPI toolstack, and Xen Orchestra provides the web management, backup and V2V migration features. Vates describes both projects as open source with no license fees, while its commercial support subscriptions add SLAs. Confirm with Vates which support tier matches your uptime commitments, and confirm that your Windows guests will run with the drivers and tools your standard build requires.
The decision turns on four questions: the workload mix, which Microsoft entitlements you already pay for, which backup tool you rely on, and what support you must contractually receive. List the Windows and Linux guests by count and criticality, then check whether your backup product supports XCP-ng or Xen Orchestra backups before committing. Ask your Microsoft account team which licenses remain payable if you retire Hyper-V hosts, and request written support terms from Vates for the hosts and the management layer. Those answers will usually settle the choice before any performance testing begins.
Which platform fits which estate
This table maps common estate shapes to the platform that usually fits better, with the condition that would change the answer. Read each row against your own workloads, skills and support requirements rather than treating any single row as a verdict. The main takeaway is that Hyper-V stays the simpler choice where Windows management is central, while XCP-ng fits teams that want an open hypervisor with Linux-centred operations and a paid support option.
| Scenario | Better fit | Why |
|---|---|---|
| Mostly Windows workloads with SQL Server and Active Directory | Hyper-V (stay, or plan a deliberate move) | Windows guests, Active Directory and SQL Server licensing are tied to Windows Server and SQL Server, and staff already manage them. Moving to XCP-ng changes the host but not the guest licensing, so the case must rest on host cost and control. |
| Mostly Linux services | XCP-ng with Xen Orchestra | Linux guests run on XCP-ng without Windows-specific tooling, and Xen Orchestra provides a web interface and backup features. Confirm driver and guest tool support for your specific distributions and versions. |
| Mixed Windows and Linux estate | XCP-ng with Xen Orchestra, if Linux operations already lead | A single Xen-based platform can host both, but Windows administrators will need to learn a new management model. If Windows administration dominates, keeping Hyper-V for Windows hosts may reduce risk during transition. |
| Regulated environment needing a contracted vendor SLA | Either platform, with a paid support contract in place | Open-source code does not come with an SLA by itself. Vates sells commercial support subscriptions that add SLAs, and Microsoft provides support for Hyper-V under its Windows Server terms. Ask each vendor for the written support scope, response times and escalation path. |
| Small cluster with limited in-house skills | Depends on existing skills, with a support plan weighed against it | A small cluster needs staff who can patch, back up and recover hosts. Compare the time your team already spends on Hyper-V with the training and support needed for XCP-ng, and consider a fixed-scope implementation partner for the first build. |
| Estate with many Hyper-V checkpoints and replicas | Hyper-V until migration plans are tested | Checkpoints, replication and backup jobs need to be mapped and proven on the new platform before cutover. Confirm how each existing job will be replaced and tested before retiring Hyper-V hosts. |
| Organization with a strong Linux and Kubernetes platform team | XCP-ng, or Harvester if Kubernetes is the target | Teams already running Linux automation can extend it to hypervisor operations. Harvester is a different model built on Kubernetes, so it fits better where containers and VMs share one platform. |
How hosting model, data control and compliance change
Both platforms run on-premises or in a private cloud that your organization controls. Hyper-V is a role on Windows Server, so the hosts, the management layer and the guest operating systems usually sit in the same Windows administrative estate. XCP-ng is a type-1 hypervisor that boots on bare metal and is managed through Xen Orchestra, which can run as an appliance or from source in your own environment. Neither platform requires a vendor-hosted control plane, which keeps the hosting boundary within your data center or cloud accounts.
- Control plane location: Hyper-V management runs through Windows Server tools and, where used, System Center. Xen Orchestra runs inside your network, so confirm where its appliance or build host will sit.
- Private cloud fit: Both support clustered, on-premises deployments. Confirm host count, network design and storage architecture against your recovery targets.
- Edge and remote sites: Check how each platform handles remote or branch hosts, including connectivity loss and local management access.
- Vendor dependence: Hyper-V depends on the Windows Server lifecycle. XCP-ng depends on its release train, where 8.3 LTS is the current long-term release line.
- Support boundary: Vates sells commercial support for XCP-ng and Xen Orchestra. Confirm whether your support model requires a subscription.
Confirm the exact hosting topology, including where the management appliance runs, before you describe the target design to auditors.
The data path changes most during migration. Hyper-V stores virtual disks as VHD or VHDX files on local volumes, Cluster Shared Volumes or SMB shares. XCP-ng stores disks in storage repositories that depend on the storage type you select. Backups also move: Hyper-V workloads often use Windows Server Backup, Veeam or another agent-based product, while XCP-ng environments commonly use Xen Orchestra backup jobs. Your residency commitments apply to every copy, including snapshots, replicas and offsite backup targets.
- Virtual disk location: Map where each VHDX or VHD file lives today and where its XCP-ng storage repository will sit, including any storage repository tied to a specific host.
- Backup targets: List every backup destination, such as a local repository, NAS, object store or remote site, and confirm the jurisdiction of each.
- Replication paths: Hyper-V Replica and any replication to a second site must be re-designed for XCP-ng, so document where replicated data travels.
- Retention and deletion: Confirm how long backups persist, how they are encrypted and how deletion is evidenced.
- Migration staging: During conversion, temporary copies of disks exist. Record where those files reside and when they are removed.
Ask your storage and backup teams to produce a data flow diagram that covers production, backup, replica and migration copies before approval.
Hyper-V hosts usually join an Active Directory domain. Administrators authenticate with domain accounts, role-based access comes from Windows security groups, and Group Policy governs host configuration. XCP-ng and Xen Orchestra do not use Windows domain membership for their management layer. Access control for the hypervisor and the management console is handled separately, so you must plan how administrator identity, MFA and audit logging will be provided. Guest VM identity is a separate question and depends on the guest operating system, not on the hypervisor.
- Administrator authentication: Decide whether Xen Orchestra accounts are local, connected to a directory service or federated through an identity provider, and confirm the supported options with Vates.
- Role separation: Map existing Active Directory groups to Xen Orchestra roles and remove standing privileged access where possible.
- Multi-factor authentication: Confirm how MFA is enforced for console, SSH and API access to hosts and the management layer.
- Audit trails: Hyper-V events flow into Windows event logs. XCP-ng and Xen Orchestra logs need a forwarding path into your SIEM.
- Host access: Document how hosts are reached for maintenance, including break-glass accounts and their storage.
Verify these identity options against current Xen Orchestra and XCP-ng documentation, since the exact integration features depend on the release you deploy.
Compliance teams need evidence that controls operate, regardless of platform. Changing hypervisors affects access control, change management, logging, backup, encryption and asset inventory records, so existing evidence for Hyper-V cannot simply be reused. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence set with your assessor before you build.
- Control mapping: Map each relevant control in your framework to the new configuration, such as access management, logging, backup and encryption, and refer to controls by their IDs and titles.
- Configuration baselines: Record hardened settings for hosts, the management layer and storage, and keep them under version control.
- Change and access records: Retain approvals, privileged session records and role assignments for the audit period.
- Backup and restore tests: Keep dated restore test results, since assessors frequently request them.
- Assessor alignment: Confirm with your auditor which evidence formats they accept and which period they will sample.
Before the migration starts, ask your assessor to confirm the evidence list in writing, so the new platform does not create gaps in an active assessment cycle.
How Windows Server licensing compares with Vates support plans
Hyper-V carries no separate hypervisor fee because it ships inside Windows Server, so the hypervisor cost is tied to the Windows Server edition and core count you license for each host. Datacenter and Standard are both licensed per core, and the exact core minimums and any System Center or client access license (CAL) requirements should be confirmed with your Microsoft licensing partner or the current Microsoft licensing documentation against your own host and management design. XCP-ng and Xen Orchestra have no license fee. The cost decision on the XCP-ng side is whether you buy commercial support from Vates, and that is optional. Ask your procurement team to model both the Windows Server core licensing you would retire and the support spend you would add, rather than comparing list prices alone.
Vates publishes its support tiers on its pricing and support page. VMS Essential is listed at $2,000 per year and Essential+ at $4,000 per year, both covering up to 3 hosts. Pro is listed 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. XOSTOR, the hyperconverged storage add-on, is listed at $800 to $1,200 per host per year. These are recurring subscription costs, so the total depends on host count, the tier you pick and whether you need XOSTOR at all. Confirm current figures, what each tier includes in SLAs and response times, and whether support covers Xen Orchestra as well as the hypervisor before you sign.
Windows guest licensing does not change when the hypervisor changes. Every Windows Server or Windows client VM you run on XCP-ng still needs its own valid license, so moving off Hyper-V reduces host-level licensing only. Check any Windows Server licenses tied to Software Assurance or existing agreements, and confirm with your licensing advisor which rights you lose or keep when the host platform is no longer Windows. Also budget for internal effort: the time to learn Xen Orchestra, build backup jobs and keep the support subscription aligned with your host count is an operating cost that does not appear on either price list.
What drives the cost of each side
Both sides charge for different things, and the bill moves with cores, hosts, support tier and the Windows guests you keep. Work through each driver on both sides with the same host count and workload so the quotes can be compared line by line.
Core and socket counting
Windows Server licensing is counted per physical core, with a minimum per host, so core density on each host drives the Windows side directly. XCP-ng subscriptions from Vates are priced per host, and Vates Pro and Enterprise tiers carry host minimums of their own. Ask the vendor how each licensing unit applies to your current hosts, including any minimum core count per processor, and model the bill at your planned core count rather than today's.
Host count and cluster size
Live migration, failover and backup targets all need enough hosts to be useful, so cluster size often sets the minimum spend. On the Vates side, a per-host subscription grows with each node, while Essential and Essential+ cover a fixed number of hosts. Ask for the price at your current host count and at the count your growth plan requires, and confirm whether spare hosts for maintenance are billed.
Support tier and SLA
Both platforms run without a support contract, but production teams usually buy one. Vates plans differ in response commitments, with Enterprise adding 24/7 support, and Microsoft support depends on your Windows Server and System Center agreements. Ask each vendor which severity levels, response times and escalation paths are included, and whether the price covers hosts you add during the term.
Windows guest licensing
Windows Server licenses on the Hyper-V side cover the Windows guests you run, so moving the hypervisor does not remove that cost. On XCP-ng, Windows guests still need valid licenses, and the Windows Server or client licensing you already hold usually follows the guest rather than the host. Ask your licensing advisor which guest licenses transfer, how Software Assurance or subscription terms apply, and whether any license depends on running on Microsoft hardware.
Backup and storage add-ons
Hyper-V backup typically runs through Windows Server Backup, Microsoft Data Protection Manager or a third-party product, each with its own license. On XCP-ng, backup runs through Xen Orchestra, and shared or hyperconverged storage such as XOSTOR is a separate per-host add-on priced at $800 to $1,200 per host per year on Vates's pricing page. Ask for every storage and backup component as a separate line, and confirm whether replication targets need their own licenses.
Staff skills and migration effort
Most of the cost sits in people time: rebuilding Hyper-V management habits in Xen Orchestra, retraining on XAPI and Xen concepts, and converting Windows guests with drivers and boot settings. Teams strong in PowerShell and Active Directory will need time to learn a Linux-based hypervisor and its tooling, and that effort recurs as staff change. Ask any implementation partner to price the migration as a fixed scope, and budget for training, parallel running and the cutover window separately.
What a move from Hyper-V to XCP-ng involves
The sequence turns a Hyper-V estate into an XCP-ng pool managed through Xen Orchestra, with each workload moved and checked before the Hyper-V hosts are retired. Most of the effort sits in inventory, storage design and validating clustered workloads, not in the conversion itself.
Inventory VMs and their dependencies
Build a list of every VM on each Hyper-V host, including its generation, disks, checkpoints, network adapters, attached ISOs, backup jobs and the applications or other VMs it depends on. Owners of each workload should confirm the business priority and the acceptable outage window. The output is a signed-off migration register that shows which VMs are Windows or Linux, which are clustered and which need a licensing check before they move.
Plan clusters and storage layout
Decide how many XCP-ng hosts the pool needs, what network layout carries management, VM and storage traffic, and which storage repository types will hold VM disks. Check the hardware against the XCP-ng documentation and the Vates pricing and support page, which lists XOSTOR as a paid add-on, before buying hosts. The output is a written architecture with host counts, network mapping and a storage decision that the team can defend.
Build the XCP-ng pool and Xen Orchestra
Install XCP-ng 8.3 LTS on the new hosts, join them into a pool and deploy Xen Orchestra for management, backup and replication. Confirm the 8.3 LTS support dates and the install steps for your version in the XCP-ng releases documentation before you start. The output is a healthy pool where live migration works between hosts and a test VM boots and moves without errors.
Export and convert Hyper-V disks
Merge or remove Hyper-V checkpoints, export each VM, and convert VHDX disks to dynamic VHD files that XCP-ng can read. Follow the migration docs for the required VHD naming rules and make sure the staging location has enough free space for the converted copies. The output is a set of VHD files named to the rules, with a checksum or size record for each disk so the import can be verified later.
Import disks and install guest tools
Import the converted disks into the XCP-ng storage repositories, create the VM definitions with matching CPU, memory and network settings, and remove Hyper-V integration services from each guest. Then install the XCP-ng guest tools and confirm the drivers load. For Windows guests, check the boot mode and disk controller settings against the migration documentation. The output is a VM that boots on XCP-ng with working networking, storage and console access.
Validate each workload before cutover
Start each imported VM in an isolated network, then check application functions, login, time sync, backups and monitoring against the list from the first step. Record the test results, the owner's sign-off and any remediation. The output is a validation record per workload that shows it is ready for production traffic.
Cut over clustered workloads in order
Move dependent services in the order set out in the migration register, starting with low-risk and stateless systems and finishing with clustered databases, file services and domain controllers. Keep Hyper-V copies powered off but intact until the owner accepts the result. Confirm the step-by-step order for clustered and stateful services with your application vendors, because each one has its own failover requirements. The output is every production workload running on XCP-ng with a documented rollback path until acceptance.
Retire the Hyper-V hosts
After a defined stability period agreed with the owners, remove the Hyper-V roles, update backup and monitoring jobs that still point at the old hosts, and reclaim or decommission the hardware. Keep the Windows Server licences and System Center terms under review with procurement, since they may still cover guests or other hosts. The output is a closed Hyper-V estate, an updated configuration inventory and a decommissioning record for audit evidence.
Questions buyers ask before choosing XCP-ng over Hyper-V
What does it cost to move from Hyper-V to XCP-ng?
The cost splits into three parts: the software you stop paying for, the software you start paying for, and the one-time labor to migrate. XCP-ng and Xen Orchestra have no license fees, so the recurring question is whether you buy Vates support. Vates lists VMS plans at $2,000 per year for Essential, $4,000 per year for Essential+ for 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. Ask Vates which tier matches your host count and whether XOSTOR storage is needed at $800 to $1,200 per host per year. On the Microsoft side, the Windows Server host licenses you stop renewing and any System Center spend are the offsetting savings. Your quote should list migration labor, training, and recurring support separately.
How long does a Hyper-V to XCP-ng migration take?
The duration depends on the number of VMs, the size of their disks, how many hosts are involved, and how much of the estate is clustered or production-critical. Those factors set the schedule, so ask for a timeline in the written scope rather than a generic figure. Plan for a pilot group of low-risk VMs first, then the clustered workloads in a planned order. Disk conversion and the time to install guest tools on each Windows VM add up, especially across many machines. Confirm with your provider which phases are included, what cutover windows you need, and how rollback is handled if a VM fails to boot after conversion.
Can our team migrate to XCP-ng without an outside partner?
Yes, many teams do this in-house, but the work requires people who can handle Hyper-V export, disk conversion, XCP-ng pool design, storage repository layout and Xen Orchestra administration. The XCP-ng documentation covers imports from Hyper-V, and the migration guide describes the conversion steps, so a capable Windows and virtualization team can follow it. The question is whether they have time and a test environment. An external team can be engaged for a fixed scope covering planning, implementation, backup configuration, documentation and handover, or as an ongoing retainer. Compare the internal effort you would pull from production work against a written scope before deciding.
What skills does our staff need to run XCP-ng after the move?
Your staff need Linux administration for the dom0 control domain, familiarity with the XAPI toolstack and Xen Orchestra, and enough networking and storage knowledge to design pools and storage repositories. Windows administrators keep their guest skills, but they will manage hypervisor tasks through a different console. The XCP-ng documentation describes XCP-ng as a type-1 hypervisor that combines Xen, dom0, XAPI and QEMU, which is the mental model your operators must learn. Plan for training in backups, patching, and live migration within the pool. Check which of these skills already exist in your team before you commit to a schedule.
Does XCP-ng support Windows guests, and what Windows licensing still applies?
XCP-ng runs Windows guests, but the hypervisor change does not remove your Windows licensing obligations. Windows Server guests still need valid licenses under Microsoft's terms, and the hypervisor licensing you stop paying for is only one part of the bill. Guest tools must be installed after conversion, and your team should confirm current driver and tool requirements for each Windows version in the XCP-ng documentation. Before you cancel any Windows Server or System Center subscription, check with Microsoft or your licensing advisor which guest rights you keep, how existing per-core licenses apply to VMs on other hypervisors, and whether any software is tied to Hyper-V.
How does Xen Orchestra V2V handle Hyper-V sources?
Xen Orchestra V2V is built for VMware, not Hyper-V. V2V warm-migrates VMs from ESXi 7 and later, replicating data while the source VM runs and then syncing changed blocks after shutdown, and it needs HTTP access to the ESXi API. It reads disks from VMFS, NFS or vSAN datastores. The XCP-ng migration documentation describes Hyper-V imports as a separate path, so Hyper-V VMs are moved by exporting and converting their disks rather than through the V2V workflow. Confirm the current Hyper-V import steps in the documentation for your XCP-ng version, and test a representative VM before you plan the full cutover.
Which fits better, XCP-ng or Hyper-V, for a mostly Windows estate?
For a mostly Windows estate, the decision turns on how deeply your operations depend on Windows Server, Active Directory, System Center and Hyper-V-specific tooling. Hyper-V stays in the Windows Server stack, which keeps management consistent for Windows administrators. XCP-ng suits teams that want an open-source, Linux-based hypervisor with a separate management layer, or that already run Xen or XenServer. If most workloads are Windows, test the Windows guest tooling, backup agents and monitoring against XCP-ng before committing. For a mostly Linux estate, XCP-ng fits more naturally. Run a short proof of concept with your own VMs and document the results before choosing.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Hyper-V to XCP-ng decision, that means working from your actual Windows and Linux estate, your licensing position and your data residency needs before recommending a path.
How we scope
- Inventory Hyper-V hosts, clusters, VM configuration versions, checkpoints and guest operating systems before any design work starts.
- Agree the written scope for pools, live migration, backup, replication and storage, with deliverables and timelines confirmed in writing.
- Define which workloads move to XCP-ng, which stay on Windows Server, and which need a proof-of-concept first.
How we build
- Deploy XCP-ng 8.3 LTS hosts and a Xen Orchestra instance in your own cloud accounts, data centers or air-gapped networks.
- Set up pools, storage repositories, networking and backup jobs, then test live migration and restore against your own workloads.
- Test V2V warm migration from ESXi where relevant, and conversion of Hyper-V VHDX disks with the guest tools removed beforehand.
How we hand over
- Deliver runbooks for host, pool, storage and backup operations, plus the configuration and hardening baseline used.
- Document migration records per VM, including disk conversions, guest tool changes, network mappings and rollback steps.
- Train your administrators on Xen Orchestra and XAPI operations so routine changes stay with your own team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan upgrades around the XCP-ng 8.3 LTS support window, which runs to November 30, 2028, and confirm the vendor's current policy.
- Where you buy Vates commercial support, we help you map its SLA terms to your own operating procedures and escalation paths.
