Migrate from Nutanix to XCP-ng

How to migrate from Nutanix to XCP-ng without a big-bang cutover

If a renewal, a licensing change, a residency requirement or lock-in is pushing you off Nutanix AHV, XCP-ng with Xen Orchestra is a workable target, and the move is best done virtual machine by virtual machine with a parallel run, not in one weekend. Platform engineering usually leads the work, with a migration partner helping on the import path, the guest cleanup and the backup design. Your own team keeps ownership of the workloads, the change windows and the rollback decisions.

On effort and risk, the short answer is that the hard part is planning, not the copy. Each VM needs its own cutover plan that covers its firmware mode, its guest tools, its network mapping, its storage location and its backup policy. Nutanix Move migrates VMs to AHV from VMware ESXi, Hyper-V and public clouds, so it does not move workloads to XCP-ng. Expect to use the OVA export from Prism Central and the import path in XCP-ng, and confirm each step against the XCP-ng migration documentation before you schedule anything in production.

Start by sorting the estate into groups: low-risk test VMs first, then stateless services, then databases and line-of-business systems last. For each group, confirm the original BIOS or UEFI setting, remove Nutanix guest tools, and run a restore test from a Xen Orchestra backup before the production cutover. Keep the Nutanix source VM powered off but intact until the copy has run cleanly for an agreed period. Ask your partner to put the cutover plan, rollback steps and sign-off roles in writing before work starts, so the parallel run ends on a decision rather than on drift.

Which Nutanix capabilities map cleanly to XCP-ng and Xen Orchestra?

This table maps the main Nutanix AHV capabilities to their closest XCP-ng and Xen Orchestra equivalents and marks each as clean, needs rework or gap. Use it to decide which parts of your current operating model carry over directly and which need redesign before cutover. Treat every mapping as a starting point to verify in your own lab, especially HA, storage and replication behavior.

Nutanix capability	XCP-ng and Xen Orchestra equivalent	Status	Feature to confirm
Prism management (VM lifecycle, cluster views)	Xen Orchestra web UI and XAPI-based pool management	Needs rework	Confirm which admin tasks, dashboards and user roles your team uses daily in Prism
AHV VM lifecycle (create, clone, power, migrate)	XCP-ng VM operations managed through Xen Orchestra, including live migration between pool hosts	Clean	Test live migration with your guest OS and driver set in a non-production pool
Nutanix storage containers	XCP-ng storage repositories (SRs) defined per pool, such as NFS, iSCSI or XOSTOR	Needs rework	Confirm SR types, sizing and how XOSTOR replication compares with your container settings
Snapshots and VM protection	Xen Orchestra snapshots and backup jobs, including scheduled and retention-based policies	Needs rework	Confirm retention rules, quiesce behavior and restore tests against your current protection policies
Networking (AHV virtual switches, VLANs)	XCP-ng networks and bonds configured in XAPI and managed in Xen Orchestra	Needs rework	Map VLAN tags, bonding modes and any Flow-based microsegmentation to firewall rules outside the hypervisor
Guest tools and drivers	Nutanix guest tools removed before export; XCP-ng guest tools and Xen PV drivers installed as needed	Needs rework	Follow XCP-ng guidance to remove hypervisor-specific tools and agents before migration
Prism Central reporting and analytics	Xen Orchestra dashboards, health views and API access; no direct equivalent to Prism Central analytics confirmed	Gap	Identify which reports and capacity analytics you need and plan external monitoring or exports
High availability and automated failover	XCP-ng pool HA behavior configured in XAPI and Xen Orchestra	Needs rework	Verify HA restart timing, fencing and failure scenarios in your own environment before relying on them

Which VM data, images and integrations need rebuilding after the move?

A move from Nutanix AHV to XCP-ng carries more than disk images. Each VM brings configuration, guest software, backup policy and links to other systems, and each of these either travels with the export or must be recreated by hand. The cards below separate those items so the team can assign an owner and a check to each before cutover.

VM disks exported as OVA

The OVA export from Prism Central carries the virtual disks and a descriptor file, which is the starting point for every VM that moves. Confirm the Prism Central version your team uses and whether its export produces the disk format your Xen Orchestra import path expects. Keep a copy of each source OVA until the imported VM has booted, passed application checks and been backed up on XCP-ng.

VM configuration: CPU, memory, NICs and disks

CPU count, memory, NIC count, MAC addresses and disk order are not all carried over by a plain disk import, so each VM needs a configuration review after import. Record the source values from Prism Central before export and compare them with the XCP-ng VM settings. Check that virtual NICs map to the correct XCP-ng networks and that disks attach in the boot order the guest expects.

Firmware mode: BIOS or UEFI

The OVA import method does not record whether a VM ran in BIOS or UEFI mode, so a VM can fail to boot after import if the setting is wrong. Find the firmware mode of each source VM in Prism Central, then set it manually in the Xen Orchestra advanced options. Test boot for each firmware type on a sample VM before moving the rest of the estate.

Nutanix guest tools and agents

Nutanix guest tools and other hypervisor-specific agents should be removed from a VM before it moves, because they expect AHV drivers and services that will not be present on XCP-ng. Confirm which tools are installed on each Windows and Linux guest and whether the removal steps match your OS versions. Install the XCP-ng guest tools after the move, then confirm the VM reports its IP address and accepts clean shutdown from Xen Orchestra.

Backup jobs and retention

Backup schedules, retention rules and restore points in the Nutanix environment do not move with the VM, so each protected VM needs a new job in Xen Orchestra. Define the schedule, retention count and destination storage for each job before cutover, and run at least one test restore from the new backups. Confirm the retention requirements your audit or contract sets, since they decide how long the old Nutanix backups must remain readable.

Monitoring, CMDB and DNS dependencies

Monitoring agents, CMDB records and DNS entries refer to VMs by name, IP address or hypervisor, so they break or go stale when VMs move. Update monitoring targets, asset records and any hard-coded addresses or hostnames that point to the moved VMs. Ask your identity and DNS owners to confirm which services depend on these records, and test name resolution and authentication from each dependent system after cutover.

Why the OVA import needs a BIOS or UEFI check and guest tool removal

The OVA import method does not carry over whether a VM ran in BIOS or UEFI mode, according to the XCP-ng documentation. Before you export anything from Prism Central, record the firmware type of each VM so it is written down somewhere you can find after the import. When the VM lands in XCP-ng, open its advanced options in Xen Orchestra and set the boot firmware manually to match the original. A VM that was built as UEFI and imported as BIOS (or the reverse) can fail to boot with a blank console or a boot loader error, and the failure looks like a storage or disk problem when it is really a firmware mismatch. Build this check into the import runbook as a required step for every VM, not as something to fix only when a boot fails.

XCP-ng also advises removing hypervisor-specific tools and agents from a VM before migrating it. For AHV workloads, that means the Nutanix guest tools (NGT) and any other Nutanix-installed agents, uninstalled while the VM still runs on Nutanix so the removal is clean. Leaving them in place can cause boot and driver problems on the new hypervisor, because the software expects virtual hardware and services that are no longer present. Removing them before cutover also means the VM's first boot on XCP-ng is not competing with stale services. Confirm the exact package names and uninstall steps for your guest operating systems against the current Nutanix documentation for your NGT version, and keep a list of what you removed for each VM.

Test boot on a copy before you touch production. Import a cloned or exported copy of one representative VM per operating system, set the firmware to match the source, confirm it boots, and check that network interfaces and storage come up with the expected drivers. Then repeat the test for one VM with a complex disk layout. Only after these copies boot cleanly should you schedule the production cutover. Keep the original Nutanix VM intact until the imported one has been validated, so you have a rollback path.

What the Nutanix to XCP-ng migration sequence looks like, step by step

The sequence moves workloads from Nutanix AHV to XCP-ng in controlled waves, so each stage proves one thing before the team commits the next workloads and decommissions Nutanix clusters.

Build the workload inventory
The infrastructure team lists every VM on the Nutanix clusters, along with its owner, application dependencies, boot firmware (BIOS or UEFI), disk layout, network attachments, Nutanix guest tools, and backup and recovery targets. Application owners confirm which workloads are tied to a license, a vendor appliance or a fixed maintenance window. The step is done when every VM has a row in the inventory and each row names an owner who has signed off. Ask your Nutanix account team and your application vendors which workloads they will support on a new hypervisor, since that answer shapes the wave order.
Prove the path with a pilot VM
The team picks one low-risk, non-production VM that represents the common case, exports it as OVA from Prism Central, and imports it into XCP-ng with Xen Orchestra. The team checks the firmware setting in the advanced options, removes the Nutanix guest tools before export or after import as the XCP-ng documentation advises, installs the Xen guest tools, and runs the application's own test suite. The step is done when the pilot VM boots reliably, its network and storage work, and the application owner confirms the functional tests pass. Record each manual change so the cutover runbooks can repeat it exactly.
Design storage repositories and backups
Before moving production data, the team plans storage repositories on XCP-ng hosts, decides between local storage, NFS or other supported shared storage, and reviews whether XOSTOR fits the hardware. Xen Orchestra backup jobs are configured against the new repositories, and a restore test is run for the pilot VM and at least one VM with a database. The step is done when a restore from a Xen Orchestra backup has been completed and verified by the application owner, and the team has a written recovery procedure. Confirm storage capacity and replication requirements in your own environment, since these depend on your hardware and retention policy.
Run the parallel production wave
Each production wave runs in parallel with Nutanix for a defined period. The team migrates a group of workloads, keeps the source VMs powered off or read-only as the runbook specifies, and monitors performance, backups and alerting on the XCP-ng side. Xen Orchestra's V2V tool can warm-migrate VMs from ESXi 7 and later, but Nutanix VMs follow the OVA path described above. The step is done when each workload in the wave passes its acceptance tests, a Xen Orchestra backup has run successfully, and the operations team accepts the new monitoring baseline.
Execute cutover per workload
For each workload, the team follows a written cutover runbook that lists the change window, the final export, the import steps, the firmware and driver checks, DNS or load balancer changes, rollback criteria and the named approver. Cutover is scheduled per workload or per dependency group, so a database and the applications that depend on it move together. The step is done when the application owner signs the cutover record and the rollback window has closed without a fallback to Nutanix. Keep the Nutanix copy until that window closes.
Decommission Nutanix clusters with a record
After the last workload is confirmed running on XCP-ng, the team removes VMs from the Nutanix clusters, retains the source backups required by policy, and revokes Prism Central access and service accounts. The team then cancels or lets lapse the Nutanix subscription terms according to the contract, and updates the asset register. The step is done when a decommission record lists each cluster, the date of data destruction or archive, the retained backup location, and the approvals from security and finance. Plan the order of waves around application dependencies and your Nutanix renewal date, and confirm the notice terms with Nutanix before setting the final date.

How to plan XCP-ng storage repositories and Xen Orchestra backups

Plan the storage repositories (SRs) before the first VM moves, because they decide how much room the migration needs and how well the target survives a host failure. Size each SR for the migrated disks plus working space for the import, since OVA files exported from Prism Central must land somewhere before they are converted into XCP-ng disks, and keep spare capacity for snapshots and backup staging. The main choice is between local storage, shared storage and XOSTOR. Local SRs are simple and fast but tie each VM to its host, shared SRs allow live migration and restart on another host but depend on an external array, and XOSTOR provides hyperconverged replicated storage on the hosts themselves. Let the availability design you need drive this choice, not the storage you happen to have on hand.

XOSTOR is a paid add-on. Vates lists XOSTOR hyperconverged storage at $800 to $1,200 per host per year, according to its pricing and support page, so the recurring cost scales with host count and should be included in any comparison with Nutanix storage, which is licensed separately from compute. Ask Vates for the exact per-host figure that applies to your host count and support tier, and confirm whether XOSTOR support is covered by the same plan. Shared storage and local SRs carry no Vates storage fee, but the array or disks you choose carry their own cost.

Define Xen Orchestra backup jobs and run a restore test before the first production VM is migrated. Create a backup job for each SR or VM group, set the retention you need, and restore a migrated test VM to a separate network to confirm that it boots, that its disks are complete and that its firmware setting is correct. Confirm the current backup options, retention settings, replication and remote targets against the Xen Orchestra documentation, because these features change between releases. Record the restore time you measure, since it sets the realistic recovery expectation for your team and is the figure you should bring to any availability discussion.

What drives Nutanix to XCP-ng migration cost and duration, and how to keep each down

This table lists the main drivers of effort when moving Nutanix AHV workloads to XCP-ng with Xen Orchestra, with the reason each one changes the work and one way to reduce it. Software licensing is usually the smaller line item, so read the rows as the places where schedule and labor build up.

Driver	Why it changes effort	How to keep it down
VM count and size	Each VM needs an OVA export from Prism Central, an import, validation and a cutover window, so effort grows with the number of machines and the size of their disks.	Group VMs into waves by size and criticality, and start with small, low-risk workloads to build a repeatable runbook.
Mix of operating systems and firmware types	OVA import does not carry BIOS or UEFI mode, so each VM must be checked and set manually in Xen Orchestra advanced options. Mixed guest OS versions add driver and boot testing.	Inventory firmware mode and OS version for every VM before the first import, and standardize on a short list of supported guest images.
Application dependencies and change windows	Multi-tier applications must move together, and database or licensing tie-ins can force longer outages and more coordination with application owners.	Map dependencies per application, agree cutover order and rollback steps in writing, and align windows with existing change calendars.
Storage and network redesign	Nutanix storage does not map directly to XCP-ng storage repositories, so SR layout, network bridges and VLAN mapping must be designed and tested.	Document current storage and network paths, plan SR types and sizes in advance, and test VM network connectivity in a pilot before production waves.
Number of hosts and clusters	Each host needs XCP-ng installation, pool membership, network and storage configuration, and patching. More pools mean more management and more failure modes to test.	Build a standard host image and build script, then deploy hosts in parallel. Keep pool design simple unless isolation is required.
Staff skills in Xen and XAPI	Teams familiar with Prism and AHV need time to learn Xen Orchestra, XAPI concepts, pool operations and troubleshooting, which can slow the first waves.	Train operators on Xen Orchestra and XAPI before the pilot, and pair them with experienced engineers during the first production waves. Ask the implementation partner for a written knowledge transfer plan.
Backup rebuild	Backup jobs, retention rules, restore testing and offsite copies configured for Nutanix must be recreated and proven on Xen Orchestra. Restore tests take time.	Design backup policies before cutover, run restore tests on migrated VMs, and keep Nutanix backups readable until restores are verified.
Support plan choice	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, while Essential and Essential+ are priced per plan for up to 3 hosts (per Vates pricing and support page). The plan affects response times and how much internal effort is needed during cutover.	Match the plan to the support hours your change windows need, and confirm the SLA terms in writing before choosing a tier. Ask Vates and your implementation partner to confirm current prices.

What usually goes wrong in a Nutanix to XCP-ng move, and how to prevent it

Most failed Nutanix to XCP-ng moves do not fail in the hypervisor. They fail at the edges: firmware modes, leftover guest tools, network mapping, backups nobody has restored, and applications tied to addresses or hardware. Each card below names one failure and a check the team can run in a pilot before any production cutover.

VM boots in the wrong firmware

The OVA import path does not record whether a VM ran in BIOS or UEFI mode on AHV, so a VM can fail to boot after import even though its disks arrived intact. Record the firmware mode of every VM from Prism Central before export, then set the matching boot mode manually in Xen Orchestra's advanced options. Confirm in the pilot that each test VM boots on its first attempt in the mode recorded in your inventory.

Leftover Nutanix guest tools

Nutanix guest tools and other hypervisor-specific agents can cause driver conflicts, failed services or boot faults once the VM runs on Xen. XCP-ng documentation advises removing these tools before the move, and the removal has to happen while the VM can still boot. Build a list of agents and drivers per OS template, uninstall them on a copy, and check that the copy starts and reports its network and disks correctly on XCP-ng.

Missed network and VLAN mapping

AHV networks and their VLAN tags do not carry over automatically, so a migrated VM can start with no connectivity or land on the wrong segment. Export a table of every AHV network, its VLAN ID and the VMs attached to it, then map each one to a XCP-ng network before the first import. Confirm that the pilot VM reaches its gateway, DNS and the required peers on the correct VLAN.

Untested backups

A backup schedule in Xen Orchestra proves little until a restore has been run on the target. Teams often switch backups over at cutover and discover missing jobs, wrong retention or unreadable archives during an incident. Set up backup jobs for the pilot VMs, restore one to an isolated network, and boot it. Only treat a backup as ready after a full restore has been tested.

Hardcoded IPs and hardware-bound licenses

Applications that embed IP addresses, hostnames or hardware identifiers can fail when the VM moves, even when the VM itself boots. Some licensed software also ties activation to hardware or virtual device identity, so a changed virtual NIC or disk controller may trigger a re-activation. Inventory each application's dependencies and license model with its vendor before migration, and confirm in the pilot that services start, connect and keep their licenses.

Under-sized storage repositories

Storage repositories sized for the existing data often run short once conversion, snapshots, backup staging and growth are added. Plan capacity for the largest VM in the wave, the temporary copy needed during import, and the backup target separately from production storage. Ask the storage vendor or Vates how the chosen repository type behaves under those loads, and confirm the free space margin during the pilot.

How the move differs for a small estate, a multi-cluster estate and a regulated environment

A small estate usually means one site, one Nutanix cluster and a limited number of VMs that the platform team can name from memory. The work is mostly sequential: export each VM as OVA from Prism Central, import it into XCP-ng through Xen Orchestra, correct the firmware setting, remove Nutanix guest tools, and test the result. Because the number of workloads is small, the storage repository plan and the backup design can stay simple, but they still need to be written down.

Export and import: Each VM is handled by hand, so a checklist per VM (source name, export path, firmware mode, network mapping) is usually enough.
Firmware check: The OVA import does not carry BIOS or UEFI mode, so confirm the original setting for every VM and set it in Xen Orchestra's advanced options before first boot.
Guest tools: Remove Nutanix guest tools inside each guest before cutover, and record which VMs were cleaned.
Storage repository: Plan one or two storage repositories with enough space for the largest export and its imported copy.
Backups: Configure Xen Orchestra backup jobs and run one restore test before retiring the Nutanix copy.

Ask a partner to scope the VM inventory, the number of test rounds and whether the work is a fixed-scope project or a one-off migration with handover. Confirm the Xen Orchestra version and the XCP-ng release line you plan to run.

What buyers ask before moving from Nutanix to XCP-ng

What does a Nutanix to XCP-ng migration cost, and what are the components?

The software itself has no license fee, so the cost is made up of support, hardware, storage, and the one-time migration and operations work. XCP-ng and Xen Orchestra are free to run under open-source licenses. Vates sells optional support: its Essential plan is listed at $2,000 per year for up to 3 hosts, 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, according to the Vates pricing and support page. XOSTOR hyperconverged storage is an extra at $800 to $1,200 per host per year. Ask for a written quote that separates support, storage, hardware, and migration labor, and confirm whether your existing Nutanix hardware meets the XCP-ng hardware requirements.

How long does a Nutanix to XCP-ng migration take?

The timeline depends on the number of VMs, their disk sizes, how many can move in parallel, and how much testing each workload needs. Stateful database and application servers usually take the longest because they need validated downtime windows. Warm migration with Xen Orchestra V2V can reduce the outage for VMs that come from VMware, but Nutanix AHV VMs usually go through OVA export and import, so plan downtime per VM. Confirm your window with a written scope, and tie the cutover to your Nutanix renewal date so you do not pay for an extra term.

Can our team migrate from Nutanix to XCP-ng without outside help?

Yes, a team with Linux, virtualization, and storage experience can run the migration in-house, using XCP-ng documentation and Xen Orchestra. The main risks are the steps that are easy to miss: the BIOS or UEFI setting, removing Nutanix guest tools, network mapping, and backup verification. A fixed-scope engagement from DeployOpen can plan, implement, and document the migration in your own infrastructure, or cover specific parts such as storage repository design and backup setup. Agree the scope and deliverables in writing before work starts.

What skills does our staff need to run XCP-ng after the move?

Your staff need to operate a Xen-based hypervisor, the XAPI toolstack, storage repositories, and Xen Orchestra for management and backup. Teams that already run Linux servers and know virtual machine lifecycle tasks usually need focused training on XCP-ng pool operations, patching, and restore testing. Nutanix Prism operators will need to learn Xen Orchestra's interface and its backup jobs. Ask your provider for a handover plan with runbooks and training for the specific operations your team will perform.

Are Xen Orchestra and XCP-ng free to run in production?

XCP-ng is licensed under GPL-2.0 and Xen Orchestra under AGPL-3.0, so you can run both without a license fee. Vates describes the hypervisor and Xen Orchestra as open-source projects with no limits and no license fees, and adds that commercial support subscriptions bring SLAs. Support is optional, but it is the part of the budget that most often gets missed. Confirm the support model you need for your change windows and incident response before the migration date.

Can Nutanix Move be used to migrate VMs to XCP-ng?

Nutanix Move is designed to migrate VMs to Nutanix AHV from VMware ESXi, Hyper-V, and public clouds, so it is not the tool for moving VMs off AHV. For this path, the usual method is exporting VMs as OVA from Prism Central, then importing them into XCP-ng through Xen Orchestra, after checking the firmware mode and removing Nutanix guest tools. Confirm the current export options in your Prism Central version with Nutanix before you plan the migration.

Is XCP-ng supported long enough to plan a migration around it?

Yes, 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. XCP-ng 8.2 LTS support ended on September 16, 2025, so new deployments should start on 8.3 LTS. Check the release notes and the support window before each planned upgrade, and make sure your Nutanix renewal and XCP-ng cutover fit inside your change calendar.

How DeployOpen scopes, runs and supports a Nutanix to XCP-ng migration

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including XCP-ng with Xen Orchestra for teams leaving Nutanix AHV. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every AHV cluster, VM, network and storage container that the written scope covers before any export begins.
Record each VM's firmware mode, guest tools and agents, so BIOS or UEFI settings and removals are planned per VM.
Agree in writing which workloads move, which stay on Nutanix during overlap, and the cutover order and rollback steps.

How we build

Set up XCP-ng hosts, storage repositories and networks, then connect them to Xen Orchestra in your environment.
Run pilot OVA imports from Prism Central, verify boot mode, drivers and network mapping, and document each adjustment.
Configure Xen Orchestra backup jobs and restore tests so recovery is proven on migrated VMs before production cutover.

How we hand over

Deliver runbooks for export, import, guest tool removal and post-migration checks, written for your operations team.
Document the storage repository layout, backup schedules, retention settings and restore procedures used in your environment.
Provide a cutover record listing each VM, its migration date, verification results and any open items for your team to confirm.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
Plan XCP-ng version upgrades and patch windows against the published support dates, confirmed with you before each change.
Ask Vates directly about commercial support plans and SLAs for your hosts, since support terms sit outside DeployOpen's scope.