How to migrate from vSphere to XCP-ng without losing control of the cutover
A renewal quote, a move to per-core subscriptions or a concern about lock-in is usually what pushes a team off vSphere. XCP-ng with Xen Orchestra can take most virtual machines over with a warm V2V migration from ESXi, but the networking, backup jobs and high availability design have to be rebuilt by hand. The disk copy is the easy part. The risk sits in the rebuild, so plan that work as carefully as the data movement. In most cases an internal platform team does the work, with an implementation partner covering the parts the team has not run before, such as pool design, storage and backup. The effort depends mainly on the size of the estate and the mix of VM types. Linux guests with clean configurations move differently from Windows servers with custom drivers, licensed appliances or vSAN-backed disks. Ask any partner to split the quote into inventory and classification, V2V waves, network and storage mapping, backup rebuild, high availability testing and documentation, so each component can be checked against your environment. Perpetual vSphere hosts do not stop when support lapses. According to Broadcom's knowledge base, ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. Confirm with Broadcom which entitlement your hosts hold before you set the cutover date, because that determines how long you can keep a host in service while waves are still moving.
Which vSphere capabilities map cleanly to XCP-ng and which need rework
This table maps common vSphere capabilities to their XCP-ng, Xen Orchestra and XOSTOR counterparts and marks each as clean, needs rework or gap. Read the status first, then use the confirmation column to test the claim against your own hosts, storage and workloads before scheduling a wave. Several rows depend on behavior that must be verified in a lab, not assumed from the product names.
| Capability | XCP-ng and Xen Orchestra equivalent | Status | What to confirm in your environment |
|---|---|---|---|
| vCenter inventory and web management | Xen Orchestra web UI managing XCP-ng pools, with XAPI as the host API | Clean | Confirm that your admin roles, tags and inventory views cover what your operators use daily |
| vMotion (live migration of running VMs) | XAPI live migration between hosts in a pool with shared storage | Needs rework | Test live migration with your specific guest OS, CPU baseline and network paths before relying on it for maintenance |
| High availability restart | Pool HA with heartbeat SR and host fencing, configured in XCP-ng and managed through Xen Orchestra | Needs rework | Test host failure scenarios and restart priorities; confirm the heartbeat storage design for your pool size |
| DRS-style automatic placement | No direct equivalent of continuous automated load balancing is confirmed in the supplied facts; manual or scripted placement is the typical approach | Gap | Ask whether your operations depend on automated rebalancing and plan a manual placement or scripting process if they do |
| vSAN-backed datastores and disks | Local or shared storage repositories; XOSTOR for replicated block storage on XCP-ng | Needs rework | vSAN-backed disks need a separate import path; confirm how each disk is exported and whether XOSTOR fits your node count and performance needs |
| Distributed virtual switches and port groups | Xen networks and bridges managed per pool, with XAPI network objects | Needs rework | Map each port group, VLAN tag and bond to an XCP-ng network and verify that every VM retains its connectivity after import |
| Snapshots | VM snapshots and snapshot chains through XAPI and Xen Orchestra | Clean | Confirm how your VMs with long snapshot chains import and whether consolidation is needed before the V2V run |
| Backup jobs and replication | Xen Orchestra backup jobs and replication, rebuilt on the XCP-ng side rather than migrated from vSphere backup tooling | Needs rework | Rebuild every backup job, retention rule and restore test; keep vSphere backups until restores are proven |
| ESXi version and V2V source | Xen Orchestra V2V warm migration reads from ESXi 7 and later, with disks on VMFS, NFS or vSAN datastores | Needs rework | Confirm your ESXi build is within the supported range and that your datastore types are readable by the V2V tool |
What data and integrations move, and what you rebuild by hand
The V2V path moves virtual disks, but most of the operational layer around vCenter stays behind and has to be recreated on the XCP-ng side. The cards below separate what the documented export paths carry across from what your team must rebuild, test and hand over. Confirm each item against your own estate before the first wave.
VM disks via Xen Orchestra V2V
Xen Orchestra's V2V feature warm-migrates VMs from ESXi 7 and later and reads disks from VMFS, NFS or vSAN datastores. Confirm that each source host runs a supported ESXi release and that the datastore type matches what the tool reads. Test a representative Linux and Windows VM first, and record the disk size, boot mode and guest OS for every VM in the wave plan. Plan a short final cutover for each VM rather than assuming the warm copy is identical to the source.
OVF and OVA export fallback
When V2V cannot handle a VM, a documented fallback is to export the VM as OVF or OVA and import it on XCP-ng. This path is slower for large disks and needs free space on the staging storage, so size it before you start. Keep the export files under change control until the imported VM passes boot, network and application checks. Ask your vSphere administrators which VMs have custom hardware, such as passthrough devices, that an export will not preserve.
Backup jobs and retention
vCenter-linked backup products usually store jobs, schedules, retention rules and restore points outside the hypervisor, so none of them move with the VM disk. Recreate every job in Xen Orchestra's backup features, then run a full restore test for each tier. Document the retention policy you actually need, including who approves changes, because the old backup product may still hold restore points you must keep for audit. Keep the old backup chain readable until restores from the new target have been proven.
Virtual networks and VLANs
Port groups, distributed switches, VLAN tags and MTU settings on vSphere do not translate automatically into XCP-ng networks. Map each port group to an XCP-ng network and VLAN before you move the first VM, and confirm the trunk configuration on the physical switches. Check firewall rules and any routing that depends on specific MAC or IP assignments. Record the final mapping in a table that network and security teams both sign off.
Monitoring agents and service accounts
Monitoring agents, endpoint tools and service accounts installed on guests often point at vCenter names, certificates or credentials. Some agents will re-register on the new hypervisor, others need manual configuration or a new license. Inventory every guest agent, its owner and its dependency on the old management plane, then remove or rotate credentials that only vCenter used. Confirm that any alert thresholds and dashboards are rebuilt against the new host and VM names.
Automation scripts tied to vCenter APIs
PowerCLI scripts, Ansible modules, Terraform providers and custom tooling that call the vCenter API stop working once vCenter is retired. Rewrite each script against the Xen Orchestra or XAPI interfaces, and test it in a non-production pool. Assign an owner to every script, and keep a list of which runbooks or change tickets depend on it. Expect this to be the largest rebuild item for teams with heavy automation, so budget review time for it explicitly.
The migration sequence from inventory to decommissioning vSphere
This sequence moves vSphere workloads to XCP-ng in controlled waves, so each group of VMs is proven on a pilot, run in parallel with its source, cut over in a agreed window and only then removed from vSphere. Each step ends with a written artifact that the next step depends on.
Build the VM and dependency inventory
Record every VM with its guest OS and version, virtual hardware, disk types and sizes, snapshots, VMware Tools status, attached networks and storage datastores. Map which VMs depend on each other, on DNS, directory services, licensing servers and external integrations. Confirm the source ESXi hosts run version 7 or later, since the Xen Orchestra V2V feature reads from ESXi 7 and later, and flag vSAN-backed disks for separate handling. Done when the team signs a VM inventory with OS and disk types and a dependency map that business owners have reviewed.
Classify VMs into migration waves
Group the inventory by risk and business criticality, then assign each VM to a wave. Mark VMs that need a vendor-supported path, licensed software tied to hardware identifiers, or application-level quiescing, and send them to later waves or to a separate review. Ask your application vendors in writing whether they support XCP-ng as a target before a VM is placed in a production wave. Done when every VM has a wave number, an owner and a named cutover contact.
Run a pilot wave with non-critical VMs
Choose a small set of non-critical Linux and Windows VMs that cover the disk and network types in your estate. Migrate them with Xen Orchestra V2V, then test boot, drivers, network connectivity, backup and restore, and application login. Write a pilot runbook covering the exact steps, verification checks and the people who sign each check. Done when the pilot runbook has been executed once end to end and the findings are logged against the runbook.
Build XCP-ng pools, storage and networks
Install XCP-ng hosts, join them to a pool and connect shared storage that the target hosts can reach. Create the network bridges, VLANs and management interfaces to match the vSphere port groups recorded in the inventory, and set up Xen Orchestra with its backup jobs and access controls. Confirm that the storage design meets the availability goals of the wave, and that a host failure test has been run on the pool. Done when the pool, networks and Xen Orchestra management layer pass a documented acceptance test.
Parallel run each wave with warm V2V
For each wave, start a warm V2V transfer while the source VM keeps running, so the disk copy catches up before the final switch. Verify the migrated copy against the inventory, run application tests on it, and keep the vSphere source intact and powered on until cutover. Document the transfer status, any errors and the rollback point. Done when the parallel copy has been checked and the application owner has accepted the test results for that wave.
Prepare a rollback plan and cutover window
Before each cutover, write a rollback plan that states who decides to roll back, how DNS, load balancer or IP changes are reversed, and how the vSphere source is powered back on without data loss. Agree a cutover window with the business owners, freeze changes on the source VMs, perform the final sync, switch traffic and run the agreed verification checks. Done when the rollback plan is approved and the cutover checks have passed.
Sign off cutover and rebuild backup jobs
Rebuild backup jobs, monitoring and alerting for each migrated VM in Xen Orchestra and confirm that a test restore succeeds before the source backup is retired. Record the signed-off cutover record for each wave, listing the VMs, verification results, approvers and the date of the switch. Keep the vSphere source in a read-only or powered-off state for an agreed retention period set by your own policy. Done when the cutover record is signed and backup restores are proven.
Decommission vSphere after the final wave
After the last wave and the agreed retention period, remove the ESXi hosts from vCenter, delete or archive the remaining VM files according to your data retention rules, and revoke vSphere access and service accounts. Update the asset register, licensing records and disaster recovery documentation to reflect the XCP-ng estate. Confirm with your vendor and auditors what evidence they require for the decommissioning. Done when the decommissioning record is complete and no production workload depends on vCenter.
What drives migration cost and duration, and how to keep each down
This table lists the factors that change the effort and cost of moving vSphere workloads to XCP-ng with Xen Orchestra, who typically pays for each one, and whether it is a one-time or recurring cost. Use it to shape the scope you request in a written quote and to decide where your own staff should carry the work.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of VMs and waves | Each VM needs a plan, a test boot and a cutover window, so counts drive staff hours more than tooling does. | Group VMs into waves by application owner and risk, and move low-risk test systems first. |
| Disk sizes and change rate | Warm V2V copies data while the VM runs, so large or write-heavy disks extend the sync period before cutover. | Measure disk size and daily change per VM, and move the heaviest disks in their own window. |
| vSAN-backed storage | Disks on vSAN must be read through the vSphere datastore path, and storage design on the XCP-ng side (for example XOSTOR or an existing SAN) becomes a separate project. | Confirm the Xen Orchestra V2V path for your datastore type and size the target storage before the first wave. |
| Windows versus Linux workloads | Windows guests often need driver and VM tools changes, and licensing or activation checks can add test cycles. | Test Windows images on a clone first and confirm which applications need vendor sign-off. |
| Network complexity | VLANs, bonds, firewall rules and IP addressing must be rebuilt on XCP-ng networks, and mistakes show up only at cutover. | Export a network inventory per VM and rebuild network mappings in a lab pool before production moves. |
| Backup job count and retention | Backup jobs, retention rules and restore tests are rebuilt in Xen Orchestra, and each job needs validation. | Consolidate schedules and run a restore test for each backup class before retiring the vSphere jobs. |
| Change windows and downtime tolerance | Cutovers limited to narrow windows force more coordination and can lengthen the program. | Agree maintenance windows with business owners early and plan rollback steps for each wave. |
| Staff skills on Xen and XAPI | Teams that know vCenter must learn XCP-ng pool management, Xen Orchestra and XAPI tooling, which costs training time or external help. | Ask the implementation partner for knowledge transfer, runbooks and a documented support handover. |
| Support plan and recurring costs | XCP-ng is free software, but optional Vates support plans per host, backup storage and staff time recur after the migration. | Request the per-host support tier in writing and compare it with current vSphere renewal terms. |
What usually goes wrong in a vSphere to XCP-ng move
Most failed vSphere to XCP-ng moves do not fail in the conversion tool itself. They fail in the work around it: unexamined disks, guests left unprepared, backups that never got rebuilt, and networks that map to the wrong place. Each card below names one of these failure points and a check you can run before the first production wave.
V2V failures on unsupported disk layouts
Xen Orchestra's V2V feature reads disks from VMFS, NFS or vSAN datastores on ESXi 7 and later, but VMs with unusual disk layouts, independent disks, raw device mappings, or large multi-disk configurations can fail or need manual handling. Inventory every VM's disks and datastore location before scheduling a wave. Run one non-critical VM through the full warm migration and confirm it boots and its data matches the source.
Guest tools not updated after conversion
Guests moved from ESXi still carry VMware Tools and drivers for the old virtual hardware, which can leave network adapters, disk controllers or time sync misbehaving on Xen. Plan a post-migration step that removes VMware Tools and installs the Xen guest tools or equivalent drivers for each operating system. Confirm each guest reports its IP address and clock correctly in Xen Orchestra before declaring the VM done.
Forgotten backup jobs
Backup jobs, retention policies and replication schedules configured in vSphere or a third-party agent do not move with the VM. A workload can run on XCP-ng for weeks with no backup target attached. Before cutover, list every VM's backup job in the old platform, recreate each one in Xen Orchestra or your backup product, and restore a test file from the new backup to prove it works.
Network mapping errors
VLAN tags, port group names and MTU settings from vSphere port groups must be mapped to XCP-ng networks by hand. A wrong mapping can put a VM on a flat network, break a database listener, or drop traffic only at the VLAN boundary. Export the vSphere network design, write a mapping table that lists each source port group, VLAN ID and target network, and check reachability from each migrated VM before the wave is closed.
Undersized storage for parallel copies
Warm migrations copy full disks over the network and write them to local or shared storage on the XCP-ng side. Running several copies at once can fill the target storage repository, saturate the migration network, and slow production traffic on the source. Measure free space on the target and the throughput of the migration path, then limit concurrency to what those numbers support. Ask your storage team to confirm snapshot and copy headroom in writing.
Skipping rollback tests
Teams often cut over a VM without proving they can return it to vSphere. If the migrated guest fails, the source VM must still be intact, powered off only after sign-off, and able to start. Define a rollback window for each wave, keep the source disks until that window closes, and rehearse a rollback on one VM before the first production cutover. Record who approves the rollback decision and how long the source stays available.
How the move differs by estate size and starting point
A small estate usually runs a handful of ESXi hosts that are managed individually or through a single vCenter, with local or shared datastores and few dependencies between workloads. The migration is mostly about moving VMs in small batches and rebuilding a simple management layer. Because there is little cluster state to preserve, the wave plan can be short and the cutover for each VM can be scheduled independently.
- Wave plan: Group VMs by application owner and maintenance window rather than by host, since standalone hosts rarely share dependencies.
- Storage choice: Existing VMFS or NFS datastores can be read by Xen Orchestra V2V, so new storage is often needed only for the XCP-ng target pool.
- Parallel run: Keep the source hosts powered on until each wave passes its functional checks, which usually makes the parallel run short but still per wave.
- Management: Xen Orchestra replaces vCenter for a few pools, and its backup jobs can be recreated with fewer schedules.
- Licensing: Confirm whether the perpetual ESXi hosts still receive the patches you need, using the Broadcom support rules for perpetual licenses.
Before the first wave, confirm the ESXi version on each source host against the Xen Orchestra V2V documentation and check that each VM has the disk layout the tool supports.
A multi-cluster estate with vSAN is the most demanding starting point. vSAN-backed disks are the main constraint because the data must be moved off vSAN onto storage that XCP-ng can read, and that storage has to be sized for the largest wave. Clusters also carry HA, DRS-style placement and network dependencies that must be mapped to XCP-ng pools and networks before any VM moves.
- Wave plan: Move one cluster at a time and start with low-risk workloads so the storage path is proven before critical systems move.
- Storage choice: Plan the target storage first, whether that is an NFS or iSCSI array or XOSTOR, and confirm how V2V reads disks from vSAN datastores in your ESXi version.
- Parallel run: Expect a longer parallel run per cluster because each wave depends on storage capacity and on the restore tests that prove the copies.
- Networking: Map distributed port groups and VLANs to XCP-ng networks, and document which workloads need the same subnets during the transition.
- Governance: Record change approvals and rollback steps per cluster so that auditors can trace which systems ran where at each date.
Ask your storage and virtualization teams to confirm how much free capacity the target storage needs for the largest cluster before setting any cutover dates.
A team that already runs XenServer or XCP-ng knows the Xen control stack, the XAPI model and the pool concepts used by XCP-ng. The migration mostly changes the source hypervisor, so the work shifts toward importing VMs, aligning the backup and networking design with existing practice, and deciding whether the current XenServer estate should also move to XCP-ng. Skills transfer is faster, but the team still needs to learn the VMware-specific parts of the source estate.
- Wave plan: Start with the VMware workloads that can be converted with the least change, and move any existing XenServer pools in a separate track.
- Storage choice: Reuse storage repositories and backup targets that the team already operates, after confirming they meet the requirements for the new workloads.
- Parallel run: Shorten the parallel run where the same XAPI tooling and runbooks apply, but keep it for workloads that depend on VMware-specific guest tools or drivers.
- Tooling: Existing Xen Orchestra deployments can be extended to cover the migrated pools, which reduces new tool adoption.
- Lifecycle: Check the XCP-ng release line and its support window against the team's upgrade calendar before combining both estates.
Confirm with the team which XenServer or XCP-ng release each pool runs, because upgrade paths and support windows determine whether the two estates can share one maintenance calendar.
When XCP-ng fits better than a KVM platform like Proxmox VE
The choice between XCP-ng and a KVM platform such as Proxmox VE is mostly a question of which hypervisor and management model your team can run well for the next several years. XCP-ng is built on the Xen hypervisor and the XAPI toolstack, the same base as XenServer, so teams that already operate XenServer pools will recognize the pool, host and storage repository concepts and the Xen Orchestra web interface. Proxmox VE combines KVM virtual machines and LXC containers in one web interface. Both can take VMs from ESXi, so the decision rests on the operating model, not on the migration path alone.
Start with an inventory of skills and tooling. If your staff already automates XenServer through XAPI, or you want a single management layer for backups, replication and role-based access through Xen Orchestra, XCP-ng keeps that work intact. If your team already knows Linux KVM, libvirt or Proxmox clustering, or needs LXC containers next to VMs, Proxmox VE is usually the shorter learning curve. Also check your support model. Xen Orchestra is open source, while Vates sells optional per-host support plans for XCP-ng, and Proxmox sells per-socket subscriptions with the same features in every tier. Ask each vendor what response times, escalation paths and repository access the subscription gives you, and compare the recurring cost against your staff time.
Confirm the feature needs in a pilot before you commit. Build a two-host cluster on each platform, import one representative VM through the V2V path, then test live migration, HA behavior, backup jobs to your target storage and restore time, and the network layout your VLANs require. Record the results in a short scoring sheet with the features your applications truly depend on. Then decide, and keep the pilot notes as evidence for the change record.
Questions buyers ask before moving from vSphere to XCP-ng
How much effort does a move from vSphere to XCP-ng take?
The effort depends mostly on the estate, not on the hypervisor. The main drivers are the number of VMs, the mix of Windows and Linux guests, disk sizes, how many VMs carry snapshots, the vSAN-backed or NFS and VMFS datastores in use, network design, and how many backup jobs and integrations must be rebuilt. Each VM that needs application owner sign-off, a changed IP plan or a compliance control adds work. Ask for the effort split into discovery, pilot, migration waves, backup and networking rebuild, hardening, documentation and handover, so you can see which parts scale with your inventory and which are fixed.
How long does a vSphere to XCP-ng migration take?
No duration applies across all estates, so treat any single number as a guess until your inventory is assessed. The schedule is driven by the number of migration waves, total data volume, the change windows your business allows, how many applications need joint testing, and how quickly backups and monitoring are rebuilt on the new platform. Xen Orchestra's V2V feature warm-migrates VMs from ESXi 7 and later, which keeps each cutover short, but the surrounding work still sets the calendar. Confirm the timeline, its milestones and the acceptance criteria in the written scope before work starts.
Which ESXi version does the Xen Orchestra V2V tool need?
Xen Orchestra's V2V feature warm-migrates VMs from ESXi 7 and later. It reads disks from VMFS, NFS or vSAN datastores, so the storage type is part of the check, not only the hypervisor version. Confirm your exact ESXi build against the current XCP-ng migration documentation before the pilot, and test one VM from each guest OS and datastore type you run. Older hosts, including those on ESXi 6.5 or 6.7, need a different path, such as exporting the disks and importing them, so identify those hosts in the inventory first.
What happens to perpetual ESXi hosts during the transition?
Perpetual ESXi hosts and vCenter keep running after Support and Subscription expires, according to Broadcom's knowledge base. What stops is access to new patches and major version upgrades, which requires an active support contract. That makes the transition period a security question: hosts that stop receiving patches should be isolated, limited to the workloads still on them, and retired on a dated plan. Confirm your entitlement status with Broadcom and record which hosts are unpatched in your risk register. The Broadcom knowledge base article sets out the rules.
What does my internal team need to provide for the migration?
The team has to supply the knowledge only your organization holds, and the access needed to act on it. This includes read access to vCenter and the datastores, current network diagrams and VLAN plans, an inventory of VMs with owners and criticality, backup policies and retention rules, change calendars, and a named approver for each application wave. Storage and network administrators must be available for cutover days. Also name who will operate XCP-ng and Xen Orchestra after handover, because that role needs Xen, XAPI, storage and networking skills that were previously handled by vCenter.
Can our own team run the migration without outside help?
Yes, a capable internal team can run a migration, provided it has the Xen, storage and networking skills and the time to plan waves, test restores and document the result. The Xen Orchestra V2V feature and the XCP-ng documentation make the mechanics accessible, but the hard parts are dependency mapping, rollback planning, backup rebuild and hardening. Teams without that depth often use a fixed-scope engagement for the planning, pilot and first waves, then move the operations in-house. DeployOpen implements, customizes, integrates, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure, so you can choose which of those parts to hand over.
How do I request a fixed-scope quote for this migration?
Send a written description of the estate and the outcome you need, and DeployOpen will scope the work from it. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. Include the VM count and guest OS mix, datastore types and ESXi versions, network and VLAN layout, backup tools and job count, compliance obligations, and whether you want ongoing support. Ask the quote to list assessment, pilot, each migration wave, backup and networking rebuild, hardening, documentation and handover as separate items, plus any optional retainer for upgrades and continuous testing.
When to export VMs instead of migrating them directly
Export is the safer path when a VM sits outside what the V2V tool can warm-migrate. Xen Orchestra's V2V feature reads from ESXi 7 and later, so any host still running an older release needs a different route before its VMs enter a wave. Confirm the exact ESXi build on every source host, not only the vCenter version, because hosts are often patched on separate schedules. The same reasoning applies when Xen Orchestra cannot reach the datastore over the network path it needs. Check the XCP-ng migration documentation for the current source requirements before you assign each VM to a wave.
Export also makes sense for a one-off copy. If a VM is being archived, handed to a test lab, or retired once its workload moves elsewhere, a full export to OVA or OVF files is usually simpler than building a warm migration, mapping networks and recreating backup jobs for a machine that will not stay. Exported files are also the practical option for an air-gapped transfer, where the XCP-ng pool has no path to the vSphere datastore at all. The trade-offs are that each copy is a full set of disks, so storage and transfer time grow with every VM, and the VM generally must be powered off for a consistent copy. The export steps and file formats are covered in the sibling topic on exporting data from VMware vSphere.
Before choosing export for any VM, run a short check. Record the ESXi version of its host, whether the VM has snapshots, which datastore holds its disks, and whether anything in it depends on the vSphere environment, such as a specific virtual device or software licensed to the host. Then confirm with the import path you plan to use that the target XCP-ng pool accepts the exported format and disk type. Store a checksum for each exported file so the copy you import can be shown to match the one you exported. Treat export as the exception, and list those VMs in the wave plan so the cutover team knows which machines left by a different route.
How DeployOpen scopes, runs and supports your XCP-ng migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from vSphere to XCP-ng, we start from a written scope covering the VMs, networks, backup jobs and cutover waves you need to move, then run the migration in your environment.
How we scope
- We inventory ESXi hosts, vCenter versions, datastores and VMs to confirm the ESXi 7 or later requirement for Xen Orchestra V2V.
- We identify vSAN-backed disks, VMs with snapshots and guests without VMware Tools that need a different path.
- We agree the written scope, deliverables and timeline with you before any work starts, since engagements are fixed-scope.
How we build
- We install and configure the XCP-ng pools and Xen Orchestra in your own cloud accounts, data centers or air-gapped networks.
- We rebuild network mappings, storage repositories and backup jobs in Xen Orchestra so they match the vSphere design you approved.
- We run test migrations of representative VMs and record the results before any production wave is scheduled.
How we hand over
- We document the cluster design, network layout, backup schedules, restore procedures and the cutover runbook for each wave.
- We record rollback steps and the evidence of each restore test so your operations team can repeat them.
- We train your administrators on daily XCP-ng and Xen Orchestra operations, then confirm handover against the agreed scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover XCP-ng and Xen Orchestra updates, including moves between release branches, tested in your environment first.
- Confirm with Vates which per-host support plan your team needs, since that cost is separate from the DeployOpen engagement.
