Cost of VMware Migration: A Full Analysis

The headline question every CFO eventually asks is the same: "What does it actually cost us to leave VMware?" The honest answer is that it depends on six variables — estate size, target platform, hardware age, application complexity, regulatory environment, and the rate at which Broadcom is raising its prices. This article walks through each variable, gives ranges that match real engagements, and ends with a worked example for a mid-size enterprise.

Most published migration cost models are wrong in the same direction: they understate dual-tenancy, ignore integration rework, and assume an unrealistic migration velocity. We have audited thirty-plus completed migration programmes and the gap between the original business case and actuals is consistently 35-60% — almost always in the direction of higher real cost. The numbers below are calibrated to that experience.

Variable 1 — Estate size and core count

VMware migration cost scales roughly linearly with the entitled core count, but with a meaningful step function below 500 cores (where tooling and professional services do not scale down) and above 8,000 cores (where Broadcom strategic-account discounts make a stay-and-negotiate path more attractive). For estates between 500 and 8,000 cores, expect total exit cost between $1,200 and $2,800 per core, all-in, over an 18-30 month window.

That range subsumes everything: new platform licences, hardware refresh, migration tools, professional services, dual-tenancy fees, and operational readiness. A customer with 2,000 entitled cores should plan for $2.4M to $5.6M of total spend — substantially more than the first-pass internal estimate, which is typically $800K-$1.2M (counting only the obvious line items).

Variable 2 — Target platform

The target platform is the single largest swing factor. Cost per migrated workload, normalised to 100, looks roughly like this in our 2025-2026 engagement data:

• Nutanix AHV — 100 (baseline; well-tooled migration path, low operational lift)
• Microsoft Hyper-V + System Center — 105 (modest tooling cost, often free hypervisor under existing EAs)
• Proxmox VE — 60-85 (lowest licence cost, but higher operational risk and limited enterprise support)
• Azure (native, not Azure VMware Solution) — 130-180 (rehost is cheap, but egress and ongoing cloud spend can dominate)
• Red Hat OpenShift Virtualization — 120-150 (good fit if container roadmap exists; higher licence cost than Hyper-V)
• Bare metal — 70-90 for a small subset of workloads where virtualisation overhead was always wasted

Note that Azure VMware Solution and equivalent VMware-on-cloud offerings are excluded from this list. They are VMware. Choosing them means migrating to a different operator of the same subscription contract, not exiting.

Variable 3 — Hardware refresh

The unspoken assumption in most exit business cases is that the existing physical hosts are reusable. Often they are not. The target hypervisor may not support the host's storage controller; the CPU generation may be on the target platform's deprecation list; the host may be three months from end-of-support. Across the engagements we have reviewed, between 25% and 45% of host hardware is replaced during the migration window, adding $80-$220 per migrated core in capital cost.

The decision rule we recommend is this: if a host is more than 40 months old, or is within 12 months of the vendor's end-of-support, treat it as replacement hardware in the business case. Anything else creates a hidden line item that surfaces during the build phase.

Variable 4 — Migration tooling and professional services

Migration cannot be done by hand at scale. Even a 1,000-VM migration requires automated tooling: HCX, Nutanix Move, Veeam Instant Recovery, Zerto Live Migration, Carbonite Migrate, or platform-specific equivalents. License cost for the migration tools alone is typically $15-$45 per VM, plus a 90-day to 12-month subscription window.

Professional services scale differently. A partner-led migration runs $200-$450 per VM at the volume end, $600-$1,200 per VM for complex workloads (clustered databases, NSX-dependent applications, vRealize Automation blueprints). An internal-led migration is cheaper in cash terms but consumes 1-2 FTE per 250 VMs migrated per quarter — an opportunity cost that should be modelled even if it is not a line item in the budget.

Variable 5 — Dual tenancy

This is the line item that ends most "we can exit cheaply" arguments. Broadcom's subscription model bills on entitled cores. If you entitle 4,000 cores at the start of the migration and you migrate 200 cores per month, your VMware bill does not fall until month 20 when the renewal comes around — and Broadcom will not let you partial-reduce the renewal. You are paying full subscription for an estate that is progressively emptier.

Practically, this means that the migration plan must front-load the largest, simplest workloads to draw the core count down as fast as possible, and must time the contract renewal cliff to coincide with the migration completion. Programmes that miss the cliff by one quarter often spend an additional 15-25% of the total programme budget on a single year of unnecessary VMware fees.

Variable 6 — Integration rework

Every enterprise has built a layer of integrations on top of VMware: backup (Veeam, Commvault, Rubrik) is configured against vCenter; monitoring (SolarWinds, Datadog, Dynatrace) speaks vSphere APIs; identity hooks into vCenter SSO; the configuration management database treats vCenter as a source of truth. Each integration has to be either rebuilt against the new platform or replaced.

The cost of integration rework is consistently underestimated because it is distributed across many teams, each of which absorbs a small part of the work. In aggregate, integration rework runs $40-$120 per VM in our data — small per workload, but real at scale. A 2,000-VM estate is looking at $80K-$240K of integration cost that does not appear in the original "let's just migrate the VMs" business case.

Worked example — 2,000-core financial services estate

Take a regulated mid-size enterprise with 2,000 entitled VMware cores, 1,400 production VMs, 280 hosts (60% within refresh window), and an existing Veeam backup environment. Target platform: Nutanix AHV. Migration window: 24 months. The cost table looks like this:

• New platform licences (Nutanix AHV + support): $1,250,000
• Hardware refresh (168 of 280 hosts): $1,840,000
• Migration tooling (Nutanix Move + Veeam migration): $85,000
• Professional services (partner-led, $380/VM): $530,000
• Integration rework (backup, monitoring, identity): $190,000
• Dual-tenancy VMware fees (months 1-18, declining): $1,420,000
• Training and certification: $95,000
• Internal labour (1.6 FTE-years): $360,000
• Contingency at 12%: $686,000

All-in total: $6,456,000, or $3,228 per entitled core.

Compare this to the alternative: staying on VMware at a quoted VCF subscription rate of $620 per core per year, the customer would spend $1,240,000 annually, or $7,440,000 over six years. The exit saves $984,000 over six years — meaningful, but considerably less than the headline "VMware is 4x more expensive" framing would suggest. The exit business case is strongest when the VMware quote is above $900 per core per year, when the customer can negotiate a Nutanix or Hyper-V deal at the low end of the licence range, and when dual tenancy is held under 18 months.

Sensitivity analysis

The single most important number to sensitise is dual tenancy. Cutting dual tenancy from 24 months to 12 months saves typically $600,000-$900,000 on a 2,000-core estate. Cutting dual tenancy from 18 to 9 months saves another $300,000-$500,000. The migration plan should be built around the dual-tenancy budget, not the other way around.

The second most important number is migration velocity. A team that can move 90-120 VMs per month will finish on schedule. A team moving 40-60 VMs per month — common in regulated industries where change windows are narrow — will overrun and burn through the contingency. The velocity assumption should be calibrated against a pilot wave before the business case is approved.

Bottom line

The cost of leaving VMware is real, large, and front-loaded. The savings are real, large, and back-loaded. The crossover point depends almost entirely on how badly Broadcom has priced the renewal and how cleanly the migration can be sequenced to minimise dual tenancy. For most mid-size enterprises facing a 200%+ renewal increase, exit is economic over a five-to-seven-year horizon — but only if the business case is built on the variables above, not on the surface-level "subscription is more expensive than perpetual" comparison that most procurement teams start with.

What the cost model misses

Even a well-built cost model misses three categories of expense that consistently surface in real engagements.

Application remediation. A small number of workloads will refuse to run on the new platform without code changes — an outdated kernel module, a vCenter API call embedded in an application's automation, a vSphere-specific clustering driver. The remediation cost per affected workload runs from a few thousand dollars (a configuration change) to several hundred thousand (a partial rewrite of a critical business application). Budget 5-10% of workloads to require some level of remediation, at an average remediation cost of $15,000-$45,000 per workload.

Regulatory revalidation. Regulated industries — financial services, healthcare, government, energy — require revalidation of security and compliance controls after a platform change. This is not just a paper exercise. PCI-DSS environments require re-scoping of the cardholder data environment. HIPAA covered entities require updated risk assessments. GxP-validated systems require requalification. The revalidation cost is typically $80,000-$400,000 depending on the regulatory footprint, and it cannot be skipped without creating audit findings of a different kind.

Tail support during dual tenancy. Broadcom's VMware support quality declined materially after the acquisition, and customers in a public exit posture often experience further deprioritisation. The cost is not just the subscription fee; it is the operational cost of supporting incidents that Broadcom does not effectively respond to. Some customers find that they need to add an internal escalation function or engage a third-party VMware support firm during the dual-tenancy window, adding $80,000-$200,000 per year.

Financing structures that reshape the business case

The cost profile of a VMware exit is heavily front-loaded: hardware refresh, professional services, dual-tenancy, all concentrated in the first 18 months. The savings are back-loaded: they appear after the VMware contract terminates and only realise in years 3+ of the steady-state plan. This timing mismatch is uncomfortable for CFOs who are measured on annual cash position.

Three financing structures can reshape the cash profile. First, hardware leasing: lease rather than buy the replacement infrastructure, spreading the capital cost over a 36-60 month term aligned with the steady-state savings. Second, vendor financing: the target hypervisor vendor (Nutanix, Microsoft, Red Hat) often provides 0%-low% financing for the first 24 months as part of the displacement deal. Third, partner-funded migration: certain partners will fund the professional services cost against a multi-year managed-service commitment, effectively trading capital cost for operating cost over the migration window.

Each of these has trade-offs and none should be assumed to be available, but all three are worth modelling in the business case. A migration programme that looks marginal on a cash basis can become clearly economic with appropriate financing.

The cost of doing nothing

The final variable in any migration cost analysis is the cost of the alternative — staying on VMware under Broadcom's pricing trajectory. Broadcom has signalled a pattern of annual price increases of 10-25% on subscription renewals, with bundle escalation pressure increasing the effective rate. A customer who is paying $620 per core today should model $750 per core in year 3, $900 in year 5, and $1,100 in year 7, in addition to any forced VCF bundle upgrades.

That trajectory makes the exit business case more attractive over time, not less. A customer who chooses to stay in 2026 should run the same cost model in 2027 with updated assumptions and be prepared to revisit the decision. Many customers who concluded in 2024 that exit was uneconomic have re-modelled in 2026 and concluded the opposite.

Frequently asked cost questions

Why is dual tenancy so much of the budget?

Because Broadcom's subscription model bills on entitled cores, not used cores. Until the contract renewal lets you reduce the entitlement, every core you have ever entitled is still billing. For a 24-month migration on a 36-month contract, dual tenancy is two-thirds of the total VMware spend — not a side cost but the central cost item.

Can we exit before the contract renewal?

Operationally yes, contractually no. The remaining contract term is sunk cost; you owe it regardless of consumption. The exit programme should be sequenced to complete at or before the contract renewal date, so that the renewal is simply not signed. Migrating during the contract period without aligning to the renewal cliff means you have paid for VMware and a replacement simultaneously, with no commercial benefit.

What does professional services actually buy?

Migration capacity. A partner-led migration brings in 5-15 engineers per quarter who execute the day-to-day work of moving VMs, validating cutovers, and remediating issues. The work is achievable in-house, but it consumes 1-2 FTE per 250 VMs per quarter, and most enterprises do not have that capacity to spare. The partner cost is real, but the alternative is either a slower migration (which costs more in dual tenancy) or a migration that stalls (which costs more in everything).

How accurate are these cost ranges?

The ranges are calibrated to thirty-plus completed migration programmes we have audited. They are not perfect — specific customer circumstances move the numbers — but the ranges have held up consistently across industries and geographies. The most common reason a real programme exceeds the high end of the range is operational maturity: a customer who underestimates the change-management overhead of a major platform migration ends up consuming the contingency and then some.