Where XenServer cost comes from and where XCP-ng changes the math
XCP-ng carries no license fee, so moving to it shifts XenServer's cost into support, storage, migration and staff time rather than eliminating it. If you are facing a XenServer renewal or a per-socket quote, the decision comes down to what you pay for those remaining components and how long the move takes. The XenServer Premium per-socket price was not part of the research behind this page, so take the figure from your own Citrix quote, including the number of sockets across every host in each pool and the term length. Ask the vendor to itemize Premium licensing separately from any License Server, support or add-on charges, because those lines determine what you can compare.
Vates, the company behind XCP-ng and Xen Orchestra, describes both projects as open source with no limits and no license fees. Its commercial support subscriptions add service level agreements (SLAs) on top of that software, and its pricing page lists them per host or per pool, with add-ons such as XOSTOR hyperconverged storage sold separately. Those support plans are optional, so the recurring line in your comparison is a decision you control rather than a fixed cost of the platform. Ask Vates or a partner for the plan that matches your response-time and coverage requirements, and confirm whether it counts hosts, sockets or pools in your environment.
Your one-time costs will be the migration and the first deployment: planning pool upgrades, testing VM moves, and training administrators on Xen Orchestra and the XCP-ng toolstack. Your recurring costs are staff time, patching, backup and any support plan. Costs rise with the number of hosts, the storage design you choose and how much change your change-control process requires. Build a three-year model with both columns filled in, and confirm the XCP-ng lifecycle dates for your planned release in the XCP-ng releases documentation before you sign any support term.
Cost components on each side and what recurs
This table compares each cost component of staying on XenServer Premium with the equivalent component of running XCP-ng, and marks whether it is paid once or every year. Read it as a checklist for a quote request, since most line items depend on host count, pool design and internal skills. The main takeaway is that XCP-ng removes the recurring per-socket license but not the recurring operations, support or storage costs you choose to buy.
| Cost component | XenServer Premium (commercial side) | XCP-ng self-hosted (with Xen Orchestra and Vates options) | One-time or recurring |
|---|---|---|---|
| License or subscription | Per-socket Premium licenses tracked through the Citrix License Server, renewed on the vendor's terms | No license fee for the XCP-ng hypervisor or Xen Orchestra, according to Vates | XenServer: recurring. XCP-ng: none for the open-source software |
| Support | Vendor support included with the Premium license, scope set by the contract | Community support, or a Vates VMS plan sold per host or per pool, with SLAs added at higher tiers | Recurring if you buy Vates support, optional on the XCP-ng side |
| Management tooling | XenCenter and the vendor's management stack, included with the license | Xen Orchestra for management, API and backup, under AGPL-3.0, free to self-host | XCP-ng side: one-time setup, then recurring operations time |
| Storage add-ons | Storage options depend on the array or software you already run | XOSTOR hyperconverged storage sold by Vates at $800 to $1,200 per host per year, or other storage you select | XOSTOR: recurring per host. Other storage: one-time hardware plus recurring maintenance |
| Infrastructure hardware | Existing hosts can usually be reused if they meet XenServer 8 requirements (confirm with the vendor) | Existing hosts can usually be reused if they meet XCP-ng hardware requirements (confirm against the XCP-ng documentation) | One-time, unless you add hosts or storage capacity |
| Implementation | Internal staff or partner time for pool design and HA setup | Internal staff or a fixed-scope partner engagement for design, networking, storage and backup | One-time, quoted from written scope |
| Migration | Not applicable when staying on XenServer | Upgrade in place from XenServer or Citrix Hypervisor, plus V2V from ESXi 7 and later with warm migration | One-time, driven by VM count, disk size and downtime windows |
| Upgrades and patching | Upgrades covered by the active Premium subscription terms | Patching and upgrades between XCP-ng LTS releases, such as 8.3 LTS supported until November 30, 2028 | Recurring operations effort, owned by your team or a retainer |
| Internal skills and operations | Staff trained on the XenServer toolchain, with vendor training options | Staff trained on XCP-ng, Xen Orchestra and backup testing, which may need upskilling | Recurring, driven by staffing and on-call coverage |
What moves the XCP-ng cost up or down
XCP-ng carries no license fee, so the cost difference comes from the factors around it: how many hosts and sockets you run, how you store data, how much uptime you need, how much you must migrate and what your team already knows. Measure each factor in your own environment before comparing quotes, since the same XenServer estate can produce very different totals.
Host count and socket density
XenServer Premium is licensed per socket, so hosts with more sockets raise the license line directly. XCP-ng has no per-socket fee, but Vates plans are priced per host, with Pro at $1,000 per host per year and a 3-host minimum, and Enterprise at $1,800 per host per year with a 4-host minimum. Count sockets and hosts separately, then compare both models for your fleet, including any growth you expect in the next three years.
Pool size and management scope
Pool size affects how many hosts share storage, live migration and high availability, and whether a Vates plan is needed at all. Small pools may run fine on the open-source stack with community support, while larger pools usually justify a paid plan for SLAs and 24/7 response. Record pool count, hosts per pool and the number of administrators who need access to each pool before pricing a support tier.
Storage model and XOSTOR need
If your XenServer pools use external SAN or NFS storage, you may not need XOSTOR, which Vates sells at $800 to $1,200 per host per year. Hyperconverged local storage adds a recurring per-host cost but removes some SAN spend. List your current storage arrays, their support contracts and the replication you rely on, then decide whether XOSTOR replaces hardware you already pay for.
Availability and SLA requirements
Open-source XCP-ng gives you the software without a vendor contract, so you carry the response time risk yourself. If your service levels require a vendor to answer within a defined window, the Vates support tier becomes a cost you budget for, not an optional extra. Write down your recovery time and recovery point targets, the hours your teams can respond, and whether an internal on-call rota can meet them.
VM count and data volume to migrate
Migration effort grows with the number of VMs and the total data they hold, because each VM needs a planned window, a backup and a validation step. Xen Orchestra can migrate from ESXi with warm replication, which lowers downtime, but large disks still take time to synchronize. Inventory VM count, disk sizes and change rates for each pool so that you can ask any implementation partner for a fixed scope based on real numbers.
In-house Xen and XAPI skills
Running XCP-ng well depends on people who understand XAPI, dom0 maintenance, pool master behavior and Xen Orchestra. Teams with this experience carry the cost mostly as internal time, while teams without it may need training, a support plan or an external partner for upgrades and incidents. Assess which engineers already manage XenServer pools, how many can cover on-call duty, and whether a paid support plan would replace skills you lack.
How Vates support plans scale with hosts
Vates lists Essential at $2,000 per year and Essential+ at $4,000 per year, each covering up to 3 hosts. Because the price is flat rather than per host, these tiers favor small pools. A three-host pool pays the same fee as a pool with one or two hosts, so the cost per host falls as you fill the tier. Essential+ is the step up for the same host ceiling at a higher annual price.
- Flat fee: Essential costs $2,000 per year and Essential+ costs $4,000 per year for up to 3 hosts, per the Vates pricing page.
- Break-even: For a pool of one or two hosts, the flat tier is usually the highest per-host cost of the three options, so compare it carefully against Pro.
- Three hosts: At the host ceiling, the flat tier is the lowest per-host figure among the plans that cover three hosts.
- Growth limit: A fourth host moves you out of these tiers, so plan your expansion before you buy.
- Unsupported option: XCP-ng and Xen Orchestra remain free to run without any of these tiers, but you then handle updates and troubleshooting yourself.
Confirm with Vates whether the Essential tiers include the features you need and how the host count is measured for your pool.
Pro is priced at $1,000 per host per year with a 3-host minimum. Your annual cost grows in direct proportion to the number of hosts, so it suits a pool that stays at a steady size. At the three-host minimum, Pro costs $3,000 per year, which is above the $2,000 Essential tier and below the $4,000 Essential+ tier for the same three hosts. The cost comparison changes as you add hosts beyond that point.
- Minimum: Pro starts at three hosts, so smaller environments pay for hosts they do not run.
- Per-host cost: Each host adds $1,000 per year, which makes the total easy to forecast.
- Three-host pool: Pro costs $3,000 per year, placing it between the two flat Essential tiers.
- Support level: Pro is the entry paid tier for production pools, and the Vates page should be checked for the response terms it includes.
- Unsupported option: Running without Pro leaves the hypervisor and Xen Orchestra free of license fees, with support handled internally or by a third party.
Confirm with Vates whether Pro covers hosts in every pool you plan to operate and whether any host count discounts apply.
Enterprise is priced at $1,800 per host per year with a 4-host minimum and includes 24/7 support. It is the highest per-host figure on the page, so the premium is paid for the support model and service level rather than for more software. At four hosts the annual figure is $7,200, which is well above Pro at the same host count, so the decision rests on how much 24/7 coverage your operations require.
- Minimum: Enterprise starts at four hosts, so it does not apply to a three-host pool.
- 24/7 support: Round-the-clock coverage is the main difference from Pro, which matters for pools that host production workloads outside business hours.
- SLA: Vates describes commercial support subscriptions as adding SLAs, so request the exact response and resolution targets in writing.
- Four-host pool: The total is $7,200 per year, compared with $4,000 for Pro at the same count.
- Unsupported option: You can run XCP-ng without this plan, but you then own the on-call rota and incident response.
Confirm current Enterprise terms, including the SLA wording and what 24/7 means for severity levels, with Vates before you sign.
When XOSTOR changes the storage line of the budget
The storage line decides whether an XCP-ng move is cheap on paper or expensive in practice. Many XenServer pools already run on shared storage from a SAN or an NFS array, and that array is usually a sunk cost that keeps being paid for through maintenance and refresh cycles. If that array stays in scope after the move, XCP-ng adds no new storage subscription, and the budget question shifts to whether the array's support contract and hardware warranty will still be renewed for the new hypervisor. Xen Orchestra and XCP-ng can attach existing shared storage, so this is often the lowest-cost path.
XOSTOR is the alternative when the organization wants hyperconverged storage built from local disks in each host. Vates sells XOSTOR at $800 to $1,200 per host per year, according to the Vates pricing and support page, so the cost recurs with every host added to the pool. That fee is in addition to the hardware for the local disks, network capacity for replication and the labor to design and operate the storage layer. The trade-off is between a storage array you already pay for and a per-host subscription on new or existing servers that removes the array from the design. For a pool of a few hosts, the per-host figure can be large relative to the array's remaining value, so the comparison should be run on the full three-year cost, not on the hypervisor line alone.
Before requesting a quote, list every storage system the XenServer estate pays for today, with its support end date, renewal price, capacity headroom and whether it will be retired during the move. Mark each one as in scope or out of scope. Then ask Vates and any integrator to price the XCP-ng design twice: once on the existing array and once with XOSTOR, including the number of hosts that must carry the XOSTOR subscription. Also confirm the array vendor supports the XCP-ng storage connection method you plan to use, since that support is a separate question from hypervisor licensing.
What the migration work adds to the first-year budget
The migration sequence turns a licensing decision into a tested, documented XCP-ng pool with every VM accounted for and a rollback path. Most of the first-year cost sits in labor and downtime planning, and the sequence below shows where each cost lands and whether it recurs.
Inventory pools, hosts, VMs and licenses
Record every XenServer or Citrix Hypervisor pool, host, VM, network, storage repository and license entitlement, including which VMs are business critical and which depend on HA or clustering. The engineering team or the implementation partner does this work, usually once and then updated during the project. Cost type: labor, one-time. The output is a signed-off inventory that maps each VM to a target host, a downtime window and an owner. Confirm with your own records and Citrix or Vates documentation that you have captured the current license state before anything else changes.
Check XAPI versions and the upgrade path
Confirm the current XenServer or Citrix Hypervisor version on every host and compare it with the upgrade path in the XCP-ng migration documentation, which covers upgrades from XenServer and Citrix Hypervisor. Decide whether the target is XCP-ng 8.3 LTS, which was released on October 7, 2024 and is supported until November 30, 2028. Cost type: labor, one-time. The output is a written compatibility check per host, with any blocking items logged and assigned. Ask the implementation partner to state in the quote which hosts they will test against before production.
Build a test pool and rehearse the upgrade
Stand up a non-production pool on spare or borrowed hardware that matches the production hardware class, then run the upgrade and a sample VM move end to end. This is the step where test hardware cost appears, and it can be one-time if the lab is retained for later patching. Cost type: test hardware and labor. The output is a rehearsal record with timings, failure points and the exact sequence used, which becomes the runbook for production. Ask the vendor or partner what hardware they need for the rehearsal and whether it is included in the fixed scope.
Upgrade the pool master first
Upgrade the pool master before the other hosts, following the order in the XCP-ng documentation, and verify that the pool still reports healthy before touching members. Keep the change window open long enough to roll back if the master does not return to service. Cost type: labor and downtime planning, one-time for the migration. The output is a confirmed master on the target version with the pool state checked in XAPI and Xen Orchestra. Document any firmware boot changes, such as booting the ISO in the original firmware mode, in the runbook.
Disable HA and clustering during the change
Turn off high availability and clustering for the duration of the upgrade so the pool does not fence or restart VMs while hosts are being changed. Re-enable both only after every host is on the target version and the pool passes its checks. Cost type: downtime planning and labor, one-time. The output is a logged pre-change state and a documented re-enable step, so the team can prove HA was restored. Confirm with the vendor how your specific storage and HA configuration behaves during the change.
Move VMs with minimal downtime
Move VMs in waves ordered by the inventory, starting with low-risk workloads so the team learns the timing. Use live migration where storage and networking allow it, and schedule planned stops for VMs that need a cold move. Cost type: labor and downtime planning, one-time for the project, with backup storage cost during the moves. The output is a per-VM log showing the move method, start and end time, and a successful boot or service check. Ask for the expected downtime per VM class in writing rather than relying on a general estimate.
Validate and cut over to production
Test each application against its acceptance criteria, confirm backup jobs and restores run on the new pool, and check monitoring and access controls. Obtain sign-off from the application owners before retiring the old pool or license. Cost type: labor and backup, one-time for cutover, with ongoing backup and support costs that recur afterward. The output is a signed validation record and a closed change ticket. Ask the partner what evidence they provide for the handover, and confirm which support tier the team will use after cutover.
How to build the cost comparison with your own numbers
This sequence turns vendor list prices and your own environment into a side-by-side cost view for the same period, so you can see which costs are one-time and which recur. Each step produces a figure you can defend in a renewal or budget discussion.
Count sockets and hosts for each pool
Start with an inventory of every XenServer pool: the number of physical CPU sockets per host, the number of hosts per pool, and any pools planned for growth. Ask the infrastructure team to confirm counts against the hypervisor itself, not an old asset list, and record them for the next three renewal cycles. Note which hosts are in production, which are in disaster recovery, and which are retired but still licensed. The output is one table with pool name, host count, socket count per host, and planned changes by year. You know this step is done when the team signs off on the counts.
Collect the current XenServer quote and license requirements
Request a written renewal quote from your Citrix or reseller contact that lists the edition, the number of sockets, the term, the support terms, and any tax or currency conditions. Ask the vendor to confirm the License Server requirements, including where licenses are hosted, how they are activated, and what happens to running hosts if the license server is unavailable. Check whether any licenses are tied to a term that ends before your planned migration date. The output is a dated quote and a short list of licensing constraints in writing. You know this step is done when you can state the annual cost for each renewal cycle from a document.
Price XCP-ng support options for the same hosts
Using the same host counts from step one, review the Vates pricing and support page and record the plans that could apply, including the per-host and per-pool options and the minimum host counts for each. XCP-ng itself is open source with no license fee, so the cost to model is the support subscription you choose, if any, plus any add-ons such as XOSTOR storage. Ask Vates for a written quote matching your host count, support level, and term, and confirm which features each plan includes. The output is a support cost line for each year that you can compare with the XenServer quote. You know this step is done when the quote states plan, host count, and term.
Add storage, hardware, backup and monitoring costs
Cost the components that exist in both scenarios so the comparison is fair. Include storage (existing SAN or NFS arrays, or a new hyperconverged design), hardware refresh schedules, backup software and target storage, and monitoring tools. For XCP-ng, identify whether you will use XOSTOR or external storage, and price the add-on separately. Ask your hardware vendor and storage vendor for written quotes, and note which costs are one-time purchases and which are annual maintenance. The output is a component list with one-time and recurring columns for each scenario. You know this step is done when every line has a source document or a named owner.
Estimate internal hours for migration
Estimate the staff hours needed to move from XenServer to XCP-ng, covering pre-checks, pool upgrade planning, test migrations, VM moves, rollback planning, and documentation. Break the work into tasks and assign each to a role, such as platform engineer, network engineer, or application owner. Use your own experience from past maintenance windows for the estimates, and label every figure as an assumption with its basis. If you use an outside partner, request a fixed-scope written quote instead of relying on a rate. The output is a hours table by task and role, with assumptions listed beside each row. You know this step is done when the platform lead has reviewed and accepted the estimate.
Estimate recurring operations effort
Estimate the ongoing hours for patching, upgrades, capacity planning, backup testing, incident response, and vendor or support contact for each year after migration. Compare the same tasks for the current XenServer environment, because some work continues in both cases. Note which tasks change with XCP-ng, such as using Xen Orchestra for management and backups, and state the assumed hours per month for each. Ask whether your staff will need training and include that as a one-time line. The output is a recurring hours table for the current state and the target state. You know this step is done when the difference between the two states is explained in plain language.
Build the side-by-side table over one period
Combine the figures into one table covering the same period for both scenarios, such as the next three renewal cycles. Show one-time costs (migration hours, hardware, training) separately from recurring costs (licenses, support, storage, operations), and convert all hours to cost using one internal rate that finance approves. Include a row for the XenServer scenario that keeps the current licenses and a row for the XCP-ng scenario with the chosen support plan. Mark each assumption in the table with an identifier that links to a notes section. The output is one table and a notes page listing every assumption and its source. You know this step is done when a finance reviewer can trace each total back to a quote or a stated assumption.
Review assumptions and request final written quotes
Review the table with the platform, security, and finance owners, and challenge each assumption that has no quote behind it. Replace estimates with written quotes wherever possible, and note the date of each quote because prices change at renewal. Confirm the support terms, the license server requirements, and any scope limits with the vendors and any partner before a decision is made. Keep the signed-off table and the quotes together as the record for the renewal decision. The output is a version of the table with quoted figures where available and clearly labeled estimates elsewhere. You know this step is done when every remaining estimate has a named owner and a date for review.
Questions buyers ask before choosing XCP-ng
How much effort does a XenServer to XCP-ng migration take?
The effort depends mostly on pool size, the number of VMs, how much downtime each workload tolerates, and how many hosts run in HA or clustering. XCP-ng can be upgraded from XenServer and Citrix Hypervisor, so the work is typically a pool-by-pool exercise rather than a full rebuild, with the pool master upgraded first. Ask for a quote built from a written inventory of hosts, pools, storage repositories and VMs. The duration of the work should come from that scope, not from a generic figure.
Can our own team migrate XenServer to XCP-ng without outside help?
Many teams with working Xen or XAPI experience can handle a small, non-critical pool themselves, using the XCP-ng migration documentation as the starting point. The harder parts are planning change windows, disabling HA and clustering correctly, validating backups before each step, and rolling back if a host fails to rejoin the pool. If your team has not run pool upgrades before, or has no spare hardware for a test pool, bring in a partner for the planning and first pool, then decide what to keep in-house. DeployOpen plans and implements these migrations under a written, fixed scope.
What does the migration need from our side?
You need access to the hypervisor pools, management network and storage, approved change windows for each pool, and a recent, tested backup of every VM before any step starts. You also need named owners for the application teams who approve downtime, the storage and network administrators, and a decision maker who can accept the rollback plan. Most delays come from missing owners or unclear windows, not from the hypervisor itself. List these owners in the scope document before work begins.
Do we have to buy Vates support to run XCP-ng?
No. XCP-ng and Xen Orchestra are open-source projects with no license fees, so you can run them without a Vates subscription. Vates commercial support plans add SLAs and vendor support, and they are priced per host or per year depending on the plan. Decide whether your operations model needs a vendor SLA, a third-party support provider, or an internal on-call team. Confirm current plan prices and what each plan includes directly with Vates before you compare totals.
What does XOSTOR add to the cost, and is it required?
XOSTOR is an optional hyperconverged storage add-on sold by Vates. Vates lists it at $800 to $1,200 per host per year, so it adds a recurring cost on top of the hypervisor and any support plan. It is not required to run XCP-ng. If you already have a SAN, NFS or other shared storage, you may not need it. Compare it with your existing storage costs and the operational work of running a distributed storage layer, and ask Vates to confirm its current terms.
Can we drop XenServer licenses before the end of our term?
Check the terms of your XenServer Premium agreement and any License Server commitments before planning the cutover, because early termination and license counting rules are set by the contract, not by this page. Practically, you can usually stop renewing once workloads are off the pool, but confirm with your Citrix account team how unused licenses and the License Server are handled. Ask for written confirmation of the end date and any refund or credit position.
How do XCP-ng support lifecycles compare with XenServer?
XCP-ng 8.3 LTS was released on October 7, 2024 and is supported until November 30, 2028, while XCP-ng 8.2 LTS support ended September 16, 2025. Citrix Hypervisor 8.2 CU1 reached end of life on June 25, 2025. Plan your upgrades against these published dates, and confirm the current support windows in the XCP-ng releases documentation before committing to a target version, since release plans can change.
How DeployOpen scopes a fixed-price XCP-ng migration
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For XenServer cost vs self-hosted XCP-ng, we start from a written scope that sets out what moves, what stays, and how each cost component is handled before any work begins.
How we scope
- Inventory every XenServer pool, host, socket count and license entitlement before estimating any XCP-ng work.
- Record which VMs need warm migration, which need a planned outage, and which storage backends are involved.
- Agree in writing which Vates plan, if any, covers support, and whether XOSTOR is in or out of scope.
How we build
- Check xapi versions and firmware mode on each host, then upgrade the pool master first in a staged order.
- Disable HA and clustering on the affected pool before upgrading, and document the reversal steps.
- Set up Xen Orchestra backups and restore tests so the new environment has tested recovery before cutover.
How we hand over
- Deliver runbooks for host upgrades, VM moves, backup schedules and Xen Orchestra administration.
- Document the license and support position so your team can see recurring costs after handover.
- Provide a list of open items, owners and the checks your auditors or assessors may ask to see.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
- Confirm with your team which patch and LTS release cadence you will follow, and the staff who will apply it.
- Review the platform after each XCP-ng release on the documented support lifecycle to plan the next upgrade.
