Nutanix or XCP-ng: which fits your renewal and your operating model
If your Nutanix renewal is coming up, or a licensing review has put the subscription under scrutiny, the decision starts with one question: do you want one vendor-supported hyperconverged stack or a hypervisor without a license fee that your own team, or a partner, runs and supports. Nutanix fits teams that want compute, storage and management delivered and supported together under Prism. XCP-ng with Xen Orchestra fits teams that want a free, GPL-2.0 hypervisor they can operate themselves or with a support partner, with Vates support plans added per host where an SLA is required. Nutanix licenses Cloud Infrastructure on physical CPU cores as 1 to 5 year term subscriptions, so the cost recurs at each renewal. With XCP-ng, the software cost is zero, and the recurring spend is support, staff time and any storage add-on you choose.
The decision turns on four things. First, in-house skills: Prism hides much of the storage and cluster work that an XCP-ng team will do through Xen Orchestra, the XAPI toolstack and the command line, so count who on your staff can run host patching, pool maintenance and backup restores. Second, storage design: Nutanix bundles its own distributed storage, while XCP-ng needs a storage choice of its own, and Vates sells XOSTOR as a per-host add-on. Third, support requirements: if your auditors or your risk committee expect a single contractual party with a defined SLA, that favors a commercial subscription on either side. Fourth, migration scope: Xen Orchestra V2V can warm-migrate VMs from ESXi 7 and later, but Nutanix AHV exports go through OVA, and the BIOS or UEFI settings of each VM must be checked after import.
Before you negotiate, ask your Nutanix account team for the exact core count and term options for your renewal, and ask Vates for a written quote for the hosts, support tier and any XOSTOR add-on you would need. Then confirm the XCP-ng support window against your own timeline: XCP-ng 8.3 LTS is supported until November 30, 2028, according to the XCP-ng releases documentation, and your plan should name the upgrade path beyond that date. A short pilot with a few non-critical VMs will show whether your team is comfortable with the operating model before any production workload moves.
Which option fits which buyer situation
This table matches common buyer situations to the option that fits best, with the reason tied to supplied facts. Read each row as a starting point, then confirm the points marked for verification against your own hardware, contracts and skills before deciding.
| Buyer situation | Better fit | Reason |
|---|---|---|
| Renewal with a short runway | Nutanix AHV, or a planned XCP-ng pilot | Migrating a whole estate takes planning, so a short runway often favors renewing while piloting XCP-ng on spare hardware. Confirm the notice terms in your Nutanix agreement. |
| Want vendor-backed hyperconverged storage | Nutanix AHV, or XCP-ng with XOSTOR | XOSTOR is a Vates add-on priced per host per year, so it is a paid, vendor-backed storage layer. Nutanix storage is sold within NCI. Compare the support scope of each. |
| Strong Linux and Xen skills in house | XCP-ng with Xen Orchestra | XCP-ng is GPL-2.0 with no license fee, and Xen Orchestra is AGPL-3.0. Teams that already run Linux can operate the stack, with Vates support optional. |
| Multi-site estate | Nutanix AHV or a separate evaluation of multi-site tooling | Confirm how Xen Orchestra handles replication and disaster recovery across sites in your version, because the supplied facts do not cover it. Nutanix offers its own multi-site features, so verify them against your licensing tier. |
| Need for SLA-backed support | Nutanix AHV, or XCP-ng with a Vates support plan | Vates support plans add SLAs, and the Enterprise plan includes 24/7 support. Ask Vates for the written SLA and compare it with the Nutanix support terms in your contract. |
| Migration from VMware already underway | XCP-ng with Xen Orchestra V2V | Xen Orchestra V2V warm-migrates VMs from ESXi 7 and later, while ESXi 6.x is not supported. Confirm your ESXi version before choosing this path. |
Where your data sits under each model
When XCP-ng and Xen Orchestra run on hardware you own in your own data center, the physical boundary, the hypervisor, the management plane and the storage all sit under your control. Nothing in the stack phones home to a vendor by design, so the operator and the buyer are usually the same team. That gives you full control over where logs and backups are written, but it also means every control is yours to build and show.
- Identity: Your directory service and privileged accounts control access to Xen Orchestra and the XAPI hosts. You decide how administrator roles and break-glass accounts are defined and reviewed.
- Audit logging: Ship hypervisor, Xen Orchestra and firewall logs to a store you control, with retention set by your own policy.
- Encryption: Encryption at rest, backup encryption and key custody are configured by your team, including where keys are held.
- Compliance evidence: Your team produces configuration exports, access reviews and change records for the assessor.
- Vendor access: Support sessions are only as broad as you grant them.
Confirm with your security team which of these controls already exist in your environment and which must be added before the assessment window.
In colocation, you own the servers and the software, but the facility provider controls the building, power, cooling, physical access and parts of the network path. The division of responsibility is set by the colocation contract and the provider's own assurance reports, not by the hypervisor. Your hypervisor and management controls look much like on-premises, while physical controls move to the provider.
- Physical access: Request the provider's access logs, visitor procedures and escort rules, and confirm whether cage or rack locks are yours to hold.
- Network path: Confirm which cross-connects and shared fabrics carry management traffic and whether they are encrypted end to end.
- Identity and logging: Same as on-premises: directory integration, privileged access and log retention remain your responsibility.
- Evidence: Collect the facility's own attestation reports and match their scope against your assessment scope.
- Backups off site: Check where the backup copy lands and under which legal jurisdiction it sits.
Ask the provider which physical and environmental controls they will evidence in writing and whether their scope covers your rack, not only the facility as a whole.
When the cluster runs in a public cloud or a provider-managed environment, the provider operates the physical hosts, data center and often the underlying network. Your data still lives on infrastructure you do not control, so the shared responsibility split and the provider's contract terms decide who must produce each piece of evidence. Bare-metal hosting by a cloud provider sits between this tab and colocation, so read the contract for the exact boundary.
- Key custody: Decide whether keys are held in a provider key service, in your own key manager or in a hardware security module you operate.
- Identity: Federate administrator access from your own identity provider and restrict provider staff access where the contract allows it.
- Logging: Confirm whether hypervisor and provider-side logs are available to you and for how long.
- Data location: Ask for the regions where storage, backups and support access occur.
- Evidence: Obtain the provider's assurance reports and map the controls each one covers.
Confirm in writing which party holds each control, because a gap between the two contracts is where assessment findings usually appear. DeployOpen can prepare the evidence and configuration records your team needs, but an independent auditor issues the report.
Across all three models, the operator of the platform and the owner of the data are not always the same party, and auditors look for both to be accounted for. Evidence has to show that a control existed and operated over the assessment period, which is different from showing that a configuration was once correct. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
- Control mapping: Map each control to the party that operates it, your team, the facility or the provider.
- Operating evidence: Keep dated access reviews, backup restore tests and change records, not only screenshots of settings.
- Scope statements: Define which clusters, Xen Orchestra instances and backup targets are in scope.
- Gap list: Record controls that no party currently evidences and assign an owner.
- Auditor inputs: Give the auditor the scope and evidence package before fieldwork begins.
Ask your auditor which evidence formats they accept and for what period they will sample before you commit to a design.
How XOSTOR and Nutanix storage differ in practice
The main difference is who owns the storage design. Nutanix runs its distributed storage inside Nutanix Cloud Infrastructure, so the storage layer, the AHV hypervisor and Prism management arrive as one platform from one vendor. XOSTOR is a storage add-on for XCP-ng, sold by Vates, that you place on hosts you select. You choose the disks, the network used for replication and the layout of the storage repositories, and XCP-ng with Xen Orchestra manages them. Before you compare costs, ask Nutanix which storage features each of its Starter, Pro and Ultimate editions includes, because the storage terms sit alongside the per-core license and must be confirmed in writing for your configuration.
Failure handling is where the design choice shows up first. In a hyperconverged cluster, a failed node removes its local disks from service, and the platform must rebuild the affected data copies on the surviving nodes. Ask each vendor how many simultaneous host failures the cluster tolerates, how long a rebuild takes at your data volume and how VM availability is affected during the rebuild. For XOSTOR, confirm the replication layer, the minimum host count and the replication factor in the Vates pricing and support material and in the XCP-ng documentation. Vates lists XOSTOR at $800 to $1,200 per host per year, so the add-on cost recurs for every host in the pool. Run a host pull test during a pilot before you rely on either design.
Capacity growth and skills are the other two differences. Nutanix grows by adding nodes that carry both compute and storage, which keeps capacity planning simple but ties disk growth to CPU growth. With XCP-ng you can usually size compute and storage separately, but you must plan the storage repositories, disk layout and replication bandwidth yourself. Operators of a Prism-managed cluster need little Linux storage knowledge. A XOSTOR team needs Linux storage administration, replication troubleshooting and an understanding of how XAPI storage repositories behave. Choose the bundled Nutanix model if your team is small and wants one vendor for storage and support. Choose XOSTOR if you have storage engineers who want to control the design and can staff its operation.
What drives the total cost on each side
Nutanix and XCP-ng charge for different things, so the totals diverge in different places. The cards below separate licence, support, storage, hardware, staff and migration costs, and name what moves each one up or down.
Nutanix term subscriptions per core
Nutanix Cloud Infrastructure is sold as term subscriptions of 1 to 5 years, licensed on physical CPU cores and portable across supported hardware. Each renewal recurs, so the cost grows with core count and with every hardware refresh that adds cores. Ask which edition (Starter, Pro or Ultimate) the quote assumes, whether storage and security features are included, and how core counts are counted on your hosts.
XCP-ng licence cost of zero
The XCP-ng hypervisor and Xen Orchestra carry no licence fee, so the software line on the XCP-ng side is zero. Your costs shift to support, storage, hardware and people. Confirm with Vates which parts of the stack you intend to run without a support plan, and record that decision in the business case so the comparison stays fair.
Vates support per host
Vates sells support plans priced per host, and they are optional. Illustrative plans from its pricing page are 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. Ask which tier includes SLAs, response times and Xen Orchestra support, and whether the host count in the quote matches your planned cluster size.
XOSTOR add-on per host
XOSTOR is Vates' hyperconverged storage add-on, priced at $800 to $1,200 per host per year. Replacing Nutanix storage with XOSTOR therefore adds a recurring per-host line that you must compare with the storage share of your Nutanix renewal. Ask whether the XOSTOR price is bundled with support or billed separately, and how it scales when you add nodes.
Hardware reuse and refresh
Nutanix nodes can often be re-imaged with XCP-ng only after you confirm driver, firmware and storage controller support, so hardware reuse is a cost lever on both sides. Reused hosts avoid capital spend, but aging nodes raise failure and support risk. Ask your hardware vendor and Vates which controllers, NICs and firmware versions are supported before you size the new cluster.
Staff time and operations
Your platform team pays for the operating work: Xen Orchestra backups, XAPI administration, patching XCP-ng hosts and running storage. Nutanix bundles Prism management and vendor support into the subscription, so staff hours move from vendor escalation to in-house operation. Estimate hours per month for each side with your own team, and ask Vates what operational training and documentation it offers.
One-time migration effort
Migration from AHV to XCP-ng is a one-time cost covering OVA export, import, guest tool removal, storage repository planning and parallel running. Its size depends on VM count, disk sizes and how many workloads need a maintenance window. Ask for a written scope listing VMs in each wave, rollback steps and the period during which Nutanix and XCP-ng run side by side.
How a move from Nutanix AHV into XCP-ng runs
The sequence moves AHV workloads into XCP-ng in stages, so each VM is proven on the new platform before the Nutanix estate is retired and rollback stays possible until cutover is signed off.
Inventory VMs and size the target hosts
Export a list of every VM from Prism Central with its vCPU, memory, disk sizes, network attachments, boot firmware (BIOS or UEFI) and dependencies on Nutanix guest tools. Map each VM to an owner and a business tier, then size the XCP-ng pool against the total load plus headroom for one host failure. Ask the hardware vendor and Vates to confirm that the target nodes meet the XCP-ng 8.3 LTS requirements. The step is done when the inventory is signed off by the application owners and the sizing has been reviewed by someone who can challenge it.
Build the XCP-ng pool and Xen Orchestra
Install XCP-ng 8.3 LTS on the target hosts, join them into a pool and deploy Xen Orchestra, either from source or through the Vates appliance, depending on your support decision. Configure storage repositories and networks to match the VLAN and bond design from the inventory. Record which Xen Orchestra edition and support level you chose, because that decision drives who answers when a backup or migration fails. The step is done when a test VM boots on every host and Xen Orchestra can see all of them.
Pilot the move with a few low-risk VMs
Choose a small set of non-critical VMs that cover different operating systems and disk layouts, including at least one with UEFI firmware. Export each one as OVA from Prism Central, import it into XCP-ng and check boot, network, disk performance and the application's own health checks. Document every change needed, such as firmware settings, network device names or drivers. The step is done when the pilot VMs run in XCP-ng for an agreed observation period and the application owners accept the results in writing.
Import the production VMs with firmware checks
Repeat the OVA export and import in waves, starting with the least critical tier. For each VM, confirm that the firmware type set on import matches the firmware the guest was built with, since a mismatch is the most common reason a VM fails to boot. Remove Nutanix guest tools and any AHV-specific drivers from the guest once it boots, and install the XCP-ng guest tools. The step is done when each VM passes its boot, network and application checks and its guest tools status is recorded in the inventory.
Plan storage repositories and capacity
Decide which storage repository types the pool will use for VM disks and for backup targets, and map each VM to a repository based on performance and redundancy needs. Confirm that the Nutanix data copied during export fits the free capacity planned for the new pool, including room for snapshots and growth. Ask Vates to confirm how XOSTOR fits your design if you intend to use hyperconverged storage, since it is licensed separately. The step is done when a capacity table shows each repository, its expected use and its headroom.
Configure backups in Xen Orchestra and test restores
Set up backup jobs in Xen Orchestra for every migrated VM, with retention and a schedule that match the recovery objectives agreed with the application owners. Send backups to a target separate from the production storage. Run at least one full restore of a representative VM into an isolated network and confirm that it boots and passes its checks. The step is done when the restore test is documented and the backup jobs report success across a full cycle.
Cut over with a defined rollback path
Schedule each wave of cutover with the application owners, freeze changes to the source VM, take a final export and import, then start the XCP-ng copy and verify it. Keep the Nutanix copy powered off but intact until the business confirms that the workload is healthy, so you can restart it if a serious fault appears. Record the rollback steps, owner and decision point for each wave before it starts. The step is done when every wave has a signed acceptance and the Nutanix copies are archived under an agreed retention rule.
Use the V2V path only for ESXi sources
The XCP-ng migration documentation also covers Xen Orchestra V2V, which warm-migrates VMs from VMware ESXi by reading disks over the ESXi API. It does not apply to Nutanix AHV sources. Confirm the ESXi version on any VMware hosts you are consolidating, since the documentation states that ESXi 6.x hosts are not supported by current Xen Orchestra versions for V2V. The step is done when you have confirmed which source platform each VM comes from and which migration path applies to it.
Planning around the XCP-ng 8.3 LTS support window
XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, while 8.2 LTS support ended on September 16, 2025. The practical lesson from that sequence is that an LTS branch has a fixed end date, and a migration project that finishes on 8.3 LTS still has to plan the move to whatever branch follows. Put the November 30, 2028 date on the platform calendar next to your hardware refresh and your Nutanix renewal date, so the first upgrade decision is made well before the window closes. Check the current release list in the XCP-ng releases documentation when you set the calendar, because it is the authoritative source for end-of-life dates.
Before you commit a cluster to 8.3 LTS, ask Vates and your reseller in writing how they handle the following: whether a Vates support subscription covers in-place upgrades between LTS branches, whether patches for the branch are delivered to unsubscribed hosts, what the upgrade path looks like for hosts that run Xen Orchestra backups and XOSTOR storage, and whether any upgrade work is billed as a separate service. The answers change the total cost, so they belong in the quote, not in a footnote. Also ask how Xen Orchestra versions are paired with each XCP-ng branch, since the management layer and the hypervisor must be upgraded in a tested order.
Build the upgrade rehearsal into the migration plan. Run one non-production pool on 8.3 LTS, move a representative set of migrated VMs through a maintenance cycle, test a rolling host update with a live VM evacuation, and confirm that backup jobs restore correctly after the update. Record the outcome and the hours it took, because that record is your best input when you estimate the recurring effort of each upgrade cycle. Assign an owner for the calendar, the Vates contract review and the rehearsal, so that the support window is managed as an operational task and does not become an emergency in 2028.
Questions buyers ask before choosing XCP-ng over Nutanix
Is XCP-ng cheaper than Nutanix once support is counted?
XCP-ng itself carries no license fee, so the comparison turns on what you pay for the rest of the stack. Nutanix charges per physical core under term subscriptions, and storage is part of that licensing. On the XCP-ng side, the software is free, but you may buy Vates support per host, and XOSTOR storage is a separate add-on priced per host per year, according to Vates' pricing and support page. Build the comparison by component: subscriptions, support, storage, hardware, staff time and a one-time migration effort. Ask Nutanix for the per-core quote for your core count and term, and ask Vates for the plan that matches your host count, then compare the totals over the same number of years.
How long does a migration from Nutanix to XCP-ng take?
The duration depends mostly on the number of VMs, their disk sizes, the network path between clusters and how many workloads need a change window. Warm migration with Xen Orchestra's V2V tool keeps a source VM running while data replicates, so the outage is limited to the final sync, but that method is documented for VMware sources rather than Nutanix AHV exports. For AHV, the path usually runs through OVA export from Prism Central and import into XCP-ng. No duration figure is supplied for this path, so ask for a timeline in a written scope after an inventory of VMs, disks and dependencies. Pilot a few representative VMs first to measure real throughput on your network.
Can our team migrate to XCP-ng without outside help?
A team with Linux, Xen or XenServer experience and a test cluster can run the migration in-house, especially for a small number of non-critical VMs. Teams without that background tend to struggle with storage repository layout, network mapping, guest driver removal and backup policy in Xen Orchestra. Outside help is usually most useful for planning, pilot runs and the cutover rehearsal, and less so for routine operation. An engagement with DeployOpen is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Compare that against the internal hours your engineers would need to spend on the same tasks.
What skills does our staff need to run XCP-ng day to day?
Plan for administrators who can manage a Xen-based hypervisor, the XAPI toolstack and Xen Orchestra, which handles backups, replication and the management interface. Networking knowledge is needed for VLANs, bonds and storage networks, and storage knowledge is needed for choosing between local storage, NFS or iSCSI repositories and XOSTOR. Staff who already run Nutanix will need to relearn the operational model, because Prism is replaced by a different management stack. Ask for training or runbooks as deliverables in the scope, and confirm your team can perform restores, host patching and failure tests before the old platform is switched off.
Do we have to buy Vates support to run XCP-ng in production?
No. Vates describes the XCP-ng hypervisor and Xen Orchestra as open-source projects with no limits and no license fees, and commercial support subscriptions add SLAs, according to Vates' pricing and support page. The real question is whether your organization needs a contractual response commitment. Regulated buyers often do, because audit and continuity plans ask who responds and how fast. Support is priced per host with tiers that differ in SLA and hours, so confirm the plan that fits your host count, your required response times and whether 24/7 coverage is part of it. Independent support from a services partner is another option to price.
How do we move the data, and what should we confirm about Nutanix Move and OVA export?
Nutanix Move is free for Nutanix customers and migrates VMs to Nutanix AHV from VMware ESXi, Hyper-V and public clouds, according to Nutanix's Move 6.0 announcement. It does not move workloads off AHV to XCP-ng, so confirm with Nutanix whether any Move capability applies to your source and target. For the usual AHV exit, export VMs as OVA from Prism Central, then import them into XCP-ng. Confirm the BIOS or UEFI mode of each VM, remove Nutanix guest tools before cutover, test boot and network behavior on each imported VM, and verify backups in Xen Orchestra before you retire the source cluster.
Does XCP-ng 8.3 LTS give us a long enough support window?
XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, according to the XCP-ng releases documentation. That window is a planning input, not a guarantee, and it should be compared with your hardware refresh and audit cycle. The 8.2 LTS line ended support on September 16, 2025, which is a reminder to track end-of-life dates for every component. Ask Vates or your support provider how patches reach production, and schedule a yearly review of the release calendar so upgrades are planned before support ends.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including XCP-ng with Xen Orchestra. For Nutanix vs XCP-ng, we start with the decision and the environment you already run, then build only what the written scope agrees to.
How we scope
- We review your current Nutanix node count, Prism Central footprint and VM inventory before agreeing any scope.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope can cover a comparison workshop, a pilot XCP-ng cluster, or a full migration plan with cutover steps.
How we build
- We install and configure XCP-ng hosts, Xen Orchestra and backup targets inside your own data center or cloud account.
- We test V2V warm migration of selected VMs from your ESXi or exported sources, recording boot, network and driver results.
- We design storage repositories, and where required, XOSTOR storage, and check them against your failure and capacity needs.
How we hand over
- You receive architecture diagrams, runbooks, backup and restore procedures and a record of the tests performed.
- Migration checklists cover OVA export from Prism Central, BIOS or UEFI settings, and removal of Nutanix guest tools.
- Knowledge transfer sessions give your operations staff the Xen Orchestra and XCP-ng administration tasks they will own.
How we support
- Ongoing support, upgrades and testing are available as retainers after handover.
- We can plan upgrade work around the XCP-ng 8.3 LTS support window, which runs until November 30, 2028.
- Ask any proposal to state which Vates support tier, if any, is included, since support is a separate purchase from the software.
