How migrating from XenServer to XCP-ng works in practice
If your renewal, per-socket license change or Citrix Hypervisor end-of-life decision is forcing a move, the good news is that XCP-ng shares XenServer's Xen and XAPI base, so the move is usually an upgrade of the pool plus VM-level work, not a rebuild of every guest. Most teams run it as an internal platform team task with an implementation partner for planning, the pool upgrade sequence and testing. The effort and risk concentrate in three areas: upgrading the pool master first and then the other hosts in a controlled order, confirming that backups and restore tests work before anything changes, and checking storage repositories and networking so that VM disks and VLANs survive the change. Guest operating systems and application configuration generally stay as they are.
Before scheduling anything, confirm the exact XenServer or Citrix Hypervisor version in each pool and check it against the XCP-ng documentation on upgrades from XenServer and Citrix Hypervisor, including the supported upgrade paths and the XAPI version compatibility notes. Boot the XCP-ng ISO in the same firmware mode (UEFI or legacy BIOS) the original hosts use, and record the current state of High Availability and pool clustering, since both are disabled for the upgrade window and need to be re-enabled and tested afterwards. Ask your implementation partner to document a rollback point for each host. Ask Vates or your partner what support plan covers the pool during the change, because the commercial support tier defines who answers when a host fails to rejoin the pool.
Downtime depends mostly on how VMs are moved, not on the hypervisor version. Live migration within a pool keeps workloads running during host-by-host upgrades when storage and CPU compatibility allow it. Where it does not, plan a scheduled window for each VM group and test the restart order against your application dependencies. Xen Orchestra provides the management and backup layer for this work, and its backup jobs are the safety net you should verify before the first host is touched. Finally, have the change owner sign off each pool separately, so a problem on one pool does not stop the others. Illustrative example: a three-host pool might be upgraded one host at a time with its VMs evacuated first, which keeps the remaining hosts carrying the load.
Which XenServer capabilities carry over to XCP-ng and which need rework
This table maps the main XenServer capabilities to their XCP-ng and Xen Orchestra equivalents and marks each as clean, needs rework or gap. Because XCP-ng shares the Xen and XAPI base, most pool and VM operations carry over, but the management console and licensing steps change. Confirm feature parity against the XCP-ng documentation for the exact target version before you plan the cutover.
| Capability | XenServer or XenCenter today | XCP-ng and Xen Orchestra equivalent and status |
|---|---|---|
| Pool management | Pool master, pool join and XAPI pool operations from XenCenter | Clean: XCP-ng pools use the same XAPI model. Upgrade the pool master first, then the other hosts. |
| VM operations through XAPI | Start, stop, migrate and snapshot VMs through XenCenter or XAPI scripts | Clean: XAPI calls and xe commands carry over. Review custom scripts and confirm version-specific arguments against the XCP-ng docs. |
| Storage repositories | SRs on local, NFS, iSCSI or Fibre Channel storage | Needs rework: existing SRs are reattached after upgrade. Check multipath, drivers and any Citrix-specific storage add-ons. |
| Networking | Management, VM and storage networks configured in XenServer | Needs rework: verify network names, bonds and VLAN tags after the upgrade and re-test traffic paths. |
| High availability | HA configured on the pool with heartbeat SR | Needs rework: disable HA before the upgrade and re-enable and test it after all hosts are on the target version. |
| Backup | XenServer VM snapshots and third-party backup agents | Needs rework: Xen Orchestra provides its own backup jobs. Existing backup tooling and retention policies must be rebuilt and restore-tested. |
| XenCenter console | Daily administration through XenCenter on Windows | Gap: XenCenter does not manage XCP-ng. Operators move their workflows to Xen Orchestra and train staff on it. |
| Licensing checks | Citrix License Server and per-socket Premium entitlements | Clean for removal: the license server and its checks are not needed on XCP-ng. Remove them from runbooks and monitoring. |
The migration sequence from inventory to decommission
This sequence moves XenServer or Citrix Hypervisor pools to XCP-ng in an order that keeps each pool recoverable at every stage. Each step ends with a written output that the next step depends on.
Inventory hosts, pools, versions and storage
The infrastructure team records every pool, host, xapi version, storage repository and VM in a single spreadsheet or configuration management record. For each VM, note the firmware mode (BIOS or UEFI), the guest operating system, attached ISOs, and any dependency on vGPU, USB passthrough or SR types that XCP-ng must also support. Confirm the current XenServer or Citrix Hypervisor version on each host against the upgrade path in the XCP-ng migration documentation. The output is a signed-off inventory that lists which pools and VMs are in scope, and which need special handling before any change is made.
Validate backups and restore a test VM
Before any change, the operations team confirms that current backups of every critical VM are complete and can be restored. Restore at least one representative VM from each storage repository to an isolated network, boot it, and check its application data. Record backup job IDs, retention settings and the restore time observed in your own environment. The output is a documented restore test with a rollback point for each pool, so the team knows the exact state to return to if an upgrade fails.
Build a pilot pool on XCP-ng
Install XCP-ng on spare hardware that matches one production pool, following the XCP-ng installation guide. Boot the installation ISO in the same firmware mode the original VMs use, because a mismatch between the installer and the guest or host firmware can leave systems unbootable. Connect the pilot to a test storage repository and manage it with Xen Orchestra. Move two or three non-critical VMs and test them against the inventory. The output is a pilot pool with a documented sequence of commands, network and storage settings, and a list of issues that must be resolved before production work begins.
Upgrade the pool master first
In each production pool, upgrade the pool master before any other host, because the master coordinates the pool metadata that every other host depends on. Disable high availability and clustering first, so the upgrade does not trigger unexpected fencing or failover. Evacuate VMs from the master if your design requires it, then run the upgrade and verify that the pool reports healthy status and that the management interface responds. The output is a pool master running the target XCP-ng release with a verified connection to all storage repositories.
Upgrade the remaining hosts in turn
After the master is stable, upgrade the other hosts one at a time. Move running VMs off each host before its upgrade, using live migration where the storage and network layout allow it, and keep enough capacity elsewhere in the pool to absorb the moved workloads. Check each host's status, network bonds and storage paths before returning it to service. The output is a pool where every host runs the same XCP-ng release and every VM has been started and tested at least once after the change.
Re-enable HA and clustering after validation
Once all hosts run the target release, re-enable high availability and any clustered storage configuration. Confirm the heartbeat storage and the fencing settings against your design, and test a controlled host failure in a maintenance window if your operating model requires it. Keep the change record of which settings were changed and when. The output is a pool with high availability active, a documented test result, and a restored failover behavior that matches the design in the inventory.
Move remaining VMs to keep downtime low
For VMs that were not moved during the host upgrades, plan the move in waves grouped by application owner. Use live migration where the guest and storage allow it, and use Xen Orchestra backup and replication for VMs that need a planned cutover. Confirm each VM's DNS, licensing and monitoring entries after its move, and keep the source copy until the application owner signs off. The output is a register showing each VM, its new host, its cutover time and its owner's acceptance.
Decommission the Citrix License Server
After the last XenServer or Citrix Hypervisor host has been removed from service, shut down the Citrix License Server and remove any licensing dependency from the change record. Confirm with your licensing contact that the entitlements are closed according to the terms you hold, and archive the license files and renewal records for audit purposes. Remove firewall rules, DNS entries and monitoring checks that referred to the license server. The output is a closed decommission record that confirms no XenServer host or license server remains in production.
What data and integrations move, and what you rebuild
A XenServer to XCP-ng upgrade keeps the Xen and XAPI model, so pool objects and VM disks have a documented path. Everything around the pool, from Xen Orchestra jobs to scripts and monitoring hooks, sits outside that path and needs an explicit decision before cutover.
VM disks and metadata
Upgrading in place keeps the VM disks on their storage repositories and carries the VM records through the XAPI database. Confirm that each VM boots after the pool upgrade, and check its UEFI or BIOS firmware setting, because a firmware mismatch is a common cause of boot failure after moving between hosts. Record VM names, UUIDs, tags, memory and vCPU settings before you start, so you can compare them afterward. Any VM you rebuild from an exported image needs its disks re-attached and its boot order checked by hand.
Storage repositories
Storage repositories hold the disks, and their type decides how much work the move involves. Local, NFS, iSCSI and other SR types that the upgrade path supports should stay attached and visible after the pool master is upgraded. Ask your storage vendor and your XenServer administrator to confirm that each SR type is supported on the target XCP-ng version. Note any SR that uses a vendor plugin, since those plugins may need a separate check.
Network configuration
Pool networks, bonds, VLAN tags and management interfaces need to match after the upgrade. Write down the name, MTU and VLAN of every network and the management IP of every host, then compare them against the upgraded pool. A management network change on a single host can cut it off from the pool, so verify it from the console before you move on to the next host. Confirm firewall rules for Xen Orchestra and any external hosts that reach the pool API.
Backup jobs and retention
Backup jobs defined in Xen Orchestra are configuration, not VM data, so they do not carry over by themselves in every case. Export the schedules, retention rules, target remotes and encryption settings before the upgrade. After cutover, run one full backup and one restore test to a scratch VM to prove the chain still works. Keep at least one backup copy that predates the upgrade until the new backups are verified.
Xen Orchestra configuration
Xen Orchestra stores users, roles, groups, remotes, proxies and LDAP or SSO settings, and these are the items most often left out of a move plan. Export or document each one, and confirm that the Xen Orchestra version you run supports the XCP-ng version in the pool. Re-check API tokens and any scheduled tasks that call the API, because their credentials and endpoints may change with the new pool master.
Scripts, monitoring and licensing hooks
Provisioning scripts, monitoring agents, CMDB feeds and Citrix License Server checks often call XAPI, the pool master address or license endpoints directly. Inventory every script, cron job and monitoring check that touches the pool, and confirm each one against your own environment. Remove any dependency on the Citrix License Server, since XCP-ng does not use it. Test each integration on a non-production pool first.
How to move VMs with low downtime during the cutover
The practical way to keep downtime low is to decide, before any VM moves, which guests can tolerate a planned stop and which cannot, then sequence the moves in waves that start with the least critical workloads. Use a pilot VM first: pick a non-production guest with a representative disk layout and network configuration, move it between pools, and confirm that it boots, reaches its dependencies and passes the application owner's acceptance test. The pilot tells you how long the cutover actually takes on your hardware, which is a better input than any estimate. Record the steps as a runbook so the second wave repeats the first without improvisation.
For each wave, take a rollback point before the move. Shut down the guest cleanly, keep the source disk and configuration untouched until the target has run through the agreed validation window, and only then retire the source copy. Keep the source pool powered and attached during this window so that reverting is a matter of starting the original VM rather than restoring from backup. Confirm with each application owner which services must be quiesced, which database or queue must drain first, and which dependent systems need a maintenance notice. Validate this sequencing against the XCP-ng migration documentation and your own change process, and confirm with your application owners before the schedule is published.
Keep the hypervisor work separate from the guest moves. Complete the pool master upgrade and the HA and clustering changes described elsewhere on this page before the first guest moves, so that the pools you move into are stable and no failover event can start during a cutover. Ask your implementation partner or Vates for written confirmation of which Xen Orchestra features are needed for each move path, and test any warm migration on the pilot VM first, because the outcome depends on your ESXi or XenServer source version, storage type and network path. Ask for the rollback procedure in writing as part of the scope, not as an afterthought.
How the migration differs by pool size and starting version
A single pool with a few hosts is the simplest case, and its main constraint is that every host shares one control plane. Because the pool master coordinates the others, the upgrade order is fixed: the pool master moves first, then the remaining hosts, with VMs evacuated or stopped as each host is taken out of service. Many teams can finish this in one planned window, but that depends on how many VMs need to move and how much data they hold, so confirm it in a test run on your own hardware.
- Pool master first: Upgrade the master before any member host, following the XCP-ng migration documentation, and confirm the pool is healthy before continuing.
- Disable HA and clustering: Turn off high availability for the duration of the work so the pool does not try to restart VMs during host reboots.
- One rehearsal: Run the full sequence on a spare host or a copy of the pool, since a single pool gives you few chances to recover from a surprise.
- Fewer windows: A small pool usually needs one primary window, plus a short follow-up for Xen Orchestra checks and backup validation.
- Rollback path: Keep a tested restore for VM data and configuration before the first host is touched.
Before the window, ask your implementation partner or Vates to confirm the exact versions in your pool and which VMs need a warm or cold move.",
An estate with several pools behaves like a program rather than a single change. Each pool has its own master, HA configuration, storage repositories and network design, so the work repeats per pool, and the order in which pools move matters more than in a single-pool case. Pools that share storage or network dependencies need to be sequenced together, and pools hosting critical workloads should go last, once the process has been proven.
- Pool ranking: Group pools by business criticality and dependency, and move low-impact pools first to build confidence in the runbook.
- Per-pool runbooks: Record the pool master, version, storage type and HA settings for each pool, so each window follows its own checklist.
- Shared dependencies: Identify shared NFS or iSCSI storage, backup targets and monitoring that span pools, and plan their changes separately.
- Maintenance calendar: Expect one window per pool or per group of pools, and agree on freeze periods with application owners ahead of time.
- Management layer: Confirm that Xen Orchestra can see every pool before the first move, so backup jobs and reporting stay consistent across the estate.
Ask your partner for a written sequence that lists pool order, dependencies and the number of windows, and confirm it with each application owner.",
Hosts still running Citrix Hypervisor 8.2 CU1 need a supported upgrade path before anything else. Citrix Hypervisor 8.2 CU1 reached end of life on June 25, 2025, so the first decision is whether to move to XCP-ng 8.3 LTS in place or to re-platform the hosts. The XCP-ng documentation describes upgrades from XenServer and Citrix Hypervisor, which makes the in-place path a realistic first option to test, but the checks before the upgrade carry most of the risk.
- Version checks first: Confirm the exact Citrix Hypervisor build, driver levels and hardware compatibility before scheduling any work.
- Upgrade the master: Follow the documented order and confirm the pool master is stable on the new version before touching members.
- Extra test cycle: Plan a dedicated test pass for legacy guest tools and drivers, since older builds are the most likely source of surprises.
- Backups before upgrade: Take and verify full VM backups and pool metadata exports, because the upgrade changes the platform under running guests.
- Windows count: Expect at least one additional window for the upgrade itself on top of any VM moves.
Ask the upgrade plan to state, in writing, the rollback method for each host and who approves the decision to continue after the first host.",
Some organizations run XenServer or XCP-ng alongside VMware, Hyper-V, KVM or other platforms. In that case the migration is one part of a broader inventory, and the main risk is that the same application may depend on tooling or network paths in more than one place. XCP-ng documents imports from Hyper-V, KVM and VirtualBox, and Xen Orchestra's V2V feature covers VMware sources, so the source hypervisor determines which path applies to each workload.
- Source-based paths: Group workloads by source hypervisor and choose the import method for each group, rather than forcing one tool across all of them.
- Network and identity dependencies: Confirm that VLANs, DNS, certificates and directory integration work the same on both sides before moving a dependent group.
- Shared monitoring and backup: Decide early whether backup and monitoring will cover both platforms during the transition, and test restores on each.
- Testing per source: Run separate validation for each source platform, since guest drivers and disk formats differ.
- Window planning: Multiple sources usually mean more windows, so combine moves that share a dependency into the same window.
Before committing, confirm with Vates or your partner which source versions the import tools support, because support depends on the source release.
What usually goes wrong in a XenServer to XCP-ng move
Most failed XenServer to XCP-ng moves do not fail in the hypervisor itself. They fail in pool state, firmware choices, and backups nobody restored. The cards below cover the six points where teams most often lose time or data, with the check to run before each change.
Mismatched xapi versions across hosts
A pool that mixes hosts on different XAPI and XCP-ng builds can refuse live operations or behave inconsistently during the upgrade window. Before touching anything, record the version on every host in the pool and confirm the upgrade order and the target release notes for each step. Confirm the exact supported mixed-version rules with the XCP-ng release documentation for your starting version, because they differ between XenServer and XCP-ng releases. Treat any host that reports a different build as a blocker until it is aligned.
Booting install media in the wrong firmware mode
If the installer boots in a different firmware mode from the one the original host used, the disk layout and boot entries may not match what the host expects, and recovery can take hours. Check whether each host currently boots in legacy BIOS or UEFI, and set the same mode on the installer and in the host configuration. Test the boot path on one spare host before you start the first production upgrade. Keep the firmware setting in the change record so a reviewer can verify it.
Upgrading a non-master host first
In a XenServer pool, the pool master coordinates the other hosts, so upgrading a member first can leave the pool split, with the master unable to manage a host on a different build. The safe order is to upgrade the pool master first, confirm the pool is healthy, and then move each member in turn. Write the host order down before the window opens. Check that VM placement is clear of any host you plan to reboot, because each reboot interrupts the VMs running on it.
HA and clustering left enabled
High availability and clustering actively restart and fence hosts. If they stay on during a rolling upgrade, a reboot can trigger an unplanned failover, or a fencing action can power off a host mid-upgrade. Disable HA and any clustering features before the first reboot, and confirm the disabled state on the pool before each host goes down. Re-enable them only after the pool reports every host healthy on the target build, and record the time you re-enabled them.
Storage repository incompatibilities
Storage repositories created on one platform version or with a driver the target build does not support can fail to attach after the move, leaving VMs unreachable. Inventory every SR type, including NFS, iSCSI, local LVM and any hyperconverged storage add-on, and confirm each one attaches on a test host running the target build. Keep a copy of the SR configuration and the multipath settings so they can be reapplied. Ask Vates which storage options are covered by your support plan before you rely on them.
Untested backups before the change
A backup that has never been restored is a hope, not a recovery plan. Before the first host changes, restore at least one representative VM from the backup set into an isolated network, boot it, and check its data and application services. Confirm the backup covers VM metadata and pool configuration, not only disk images. Keep the restored test result with the change record so the rollback path is proven before it is needed.
What drives cost and duration, and how to keep each down
This table lists the factors that change the cost and duration of a XenServer to XCP-ng move, and what each one costs to keep under control. Read each row as a lever: the cost component, whether it is paid once or recurs, and the step that reduces it. Vates support plans are the only recurring licence-type cost in the XCP-ng model, so the table separates them from one-time migration work.
| Cost driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Pool count and size | Each pool needs its own upgrade, rollback plan and pool master sequencing, so more pools multiply the change windows. | Group pools by criticality, upgrade lower-risk pools first, and confirm the pool master order before any work starts. |
| Storage type | Shared SR types, local storage and any XOSTOR hyperconverged storage each need separate validation and may need data movement. | Inventory every storage repository now, and confirm with Vates whether XOSTOR is required before pricing a per-host add-on. |
| Number of VMs and firmware modes | VMs booted in BIOS and UEFI modes need checks before and after the ISO boot, and each VM adds a move task and a test. | Export a VM inventory with firmware mode, guest OS and disk layout, then group VMs into waves by similarity. |
| Integration count | Backup jobs, monitoring, identity, DNS, and automation tools tied to XAPI or the XenCenter workflow must be re-pointed or retested. | List every system that calls the XAPI or Xen Orchestra API and assign an owner for each before the pilot. |
| Testing depth | A pilot pool and a full rehearsal of pool master upgrade, HA and clustering changes reduce the risk of rework during production windows. | Agree a pilot scope in writing and define pass criteria for boot, network, storage and backup restore. |
| Training | Operators new to Xen Orchestra, XCP-ng patching and the XAPI command set need time before they run changes alone. | Plan hands-on sessions during the pilot, and record runbooks for pool upgrades, VM moves and rollback. |
| Vates support plan (recurring) | Vates lists Essential at $2,000 per year and 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 (Vates pricing page). | Decide whether SLAs are needed, compare the per-host and per-year figures against host count, and ask Vates for a written quote from the agreed scope. |
| Operations and patching (recurring) | Ongoing patching, backups, capacity checks and XCP-ng upgrades on the 8.3 LTS line are staff effort that continues after cut-over. | Assign named owners, document a patch calendar, and estimate staff time from the pilot results. |
Questions buyers ask before moving off XenServer
How much effort and cost does a move from XenServer to XCP-ng involve?
The software cost of XCP-ng is zero, so the cost sits in labor, hardware checks, and any support you choose to buy. Vates describes XCP-ng and Xen Orchestra as open-source projects with no license fees, with commercial support subscriptions adding SLAs. The main cost drivers are the number of pools and hosts, how many VMs need to move and how much testing each workload needs, whether you buy Vates support plans (listed 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 whether you add XOSTOR storage at $800 to $1,200 per host per year. Ask any partner for a written scope that separates one-time migration work from recurring support and operations.
How long does a XenServer to XCP-ng migration take?
The timeline depends on pool size, the number of VMs, how much testing each workload needs, and how much downtime each service can tolerate. Pools that run HA or clustering need those features disabled before the upgrade, and the pool master is upgraded first, so the sequence of hosts shapes the schedule. Warm migration with Xen Orchestra V2V keeps a VM running while data syncs, which shortens cutover for moved VMs, but it applies only when the source is a supported ESXi version. Confirm the schedule, change windows and rollback points in a written scope before work starts, because no single duration applies to every estate.
What does the migration need from our internal team?
Your team needs people who can own the pool inventory, the change windows, and the decisions about which VMs move first. They also need to check the XAPI version and hardware compatibility, confirm backup and restore procedures, and sign off on application owner testing. Network and storage administrators should confirm VLANs, storage repositories, and boot firmware settings before the ISO is booted, since the installer must match the firmware mode of the original host. Ask a partner to document which of these tasks it performs and which it expects your staff to complete.
Can our own team perform the XenServer to XCP-ng move without a partner?
Yes, many teams can do it in-house if they have Xen or XAPI experience and a tested rollback plan. The XCP-ng documentation covers upgrades from XenServer and Citrix Hypervisor, and Xen Orchestra provides the management and backup layer. The questions to answer honestly are whether your staff have run pool upgrades before, whether you can test every critical workload in a lab first, and who responds if a host fails mid-upgrade. A partner is useful when the estate is large, when change windows are narrow, or when you need hardening, backup design and compliance evidence in the same project.
Do we need a Vates support plan after moving to XCP-ng?
XCP-ng and Xen Orchestra are free to run without a support subscription, and Vates states that commercial support subscriptions add SLAs. Whether you need one depends on your uptime targets, how many people can troubleshoot Xen in-house, and your internal policy for vendor-backed software. Compare the plan options directly: Essential and Essential+ are priced per pool for up to 3 hosts, Pro and Enterprise are priced per host with minimums, and Enterprise includes 24/7 support. Also check the XCP-ng support lifecycle, since 8.3 LTS is supported until November 30, 2028, and 8.2 LTS support ended September 16, 2025.
Can the XenServer to XCP-ng move be done in phases?
Yes, phased moves are common because XCP-ng can be upgraded one pool at a time, and each pool can keep its own HA and storage design during transition. Start with a non-critical pool to validate hardware, drivers, backup jobs and VM behavior, then move production pools in agreed change windows. Keep the pool master upgrade order, disabling HA and clustering before the upgrade, and rollback steps documented for each phase. Confirm the phase plan, dependencies and acceptance criteria in a written scope so each pool has a clear exit point.
What should we check first before scheduling the upgrade?
Start with a complete inventory: XenServer or Citrix Hypervisor version, XAPI version, hardware and driver compatibility, storage repositories, network configuration, and every VM's backup status. Confirm that you can boot the XCP-ng ISO in the same firmware mode as the original host, since a mismatch is a common cause of failed installs. Then verify that you can restore a VM from backup in a test environment, and document how HA and clustering will be disabled and re-enabled. These checks determine most of the effort, so ask for them to be listed as deliverables in any written scope.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a XenServer to XCP-ng move, we start with a written, fixed scope that covers your pools, VMs and cutover window before any host is touched.
How we scope
- Inventory every pool, host, xapi version and VM so the written scope reflects your actual estate
- Record which VMs need warm migration, which need a planned shutdown, and which must stay on the existing pool
- Agree in writing the rollback point, the pool master upgrade order and who signs off each cutover window
- Engagements are fixed-scope, and ongoing support after the move is available as a retainer
How we build
- Test the XCP-ng install ISO and firmware mode on spare hardware that matches your production hosts
- Upgrade the pool master first, then rehearse HA and clustering being disabled before any production change
- Set up Xen Orchestra and move test VMs with V2V warm migration, checking disks, network and boot after each run
- Validate backups and restore a sample VM from them before the first production host is changed
How we hand over
- Deliver runbooks for each cutover step, including the order of host upgrades and VM moves
- Document pool configuration, storage repositories, network mappings and the backup schedule as built
- Provide a record of test results, rollback steps and the open items your team needs to close
- Walk your operations staff through daily management tasks in Xen Orchestra and XCP-ng
How we support
- Offer ongoing support, upgrades and continuous testing under a retainer agreed in writing
- Plan future XCP-ng point upgrades around the support dates published for your release line
- Confirm with Vates which commercial support plan, if any, your environment needs, since the software itself carries no license fee
- Prepare the systems, controls and evidence your compliance assessors will ask for, while independent auditors issue any reports
