VMware Migration Planning:
When to Stay, When to Move

One of the most common mistakes we see enterprises make in response to Broadcom's VMware price increases is treating "migrate or stay" as an emotional decision rather than a financial one. Some organisations reflexively commit to migration because they are angry about the pricing. Others reflexively accept the new VMware terms because migration feels daunting. Neither approach serves the organisation's interests. The right answer is always determined by a structured cost analysis — and the answer varies significantly by organisation.

This guide provides the decision framework, cost model, and migration planning approach that allow enterprises to make this decision with clarity. For the full strategic context, start with the VMware Broadcom Guide 2026 — this article focuses on the migration decision and planning specifically.

The Migration Decision Framework

The migration decision is fundamentally a net present value comparison between two futures: stay on VMware under Broadcom's new pricing, or invest in migration to an alternative platform. Three factors determine which future has higher NPV: the cost increase magnitude, the total cost of migration, and your strategic cloud direction.

Factor 1: The Cost Increase Multiple

Calculate the ratio of your projected Broadcom VMware annual cost (under VCF or VVF subscription) to your previous annual VMware cost (perpetual amortisation plus SnS). This ratio is your cost increase multiple. The practical migration threshold based on our engagements is:

• Under 3×: Migration rarely makes financial sense when fully costed. The migration investment (professional services, testing, productivity impact, tool replacement) almost always exceeds the 5-year NPV of the additional cost. Focus on negotiating the best possible VCF terms.
• 3–5×: Analysis required. The decision depends heavily on your migration complexity and strategic cloud direction. Conduct the full cost model before committing either way.
• Over 5×: Migration is financially justified in most cases, even for moderately complex environments. The 5-year cost saving typically exceeds the migration investment by a significant margin. The question becomes "which alternative" and "what timeline," not "whether."

Factor 2: Total Cost of Migration

Migration costs are consistently underestimated by organisations that have not previously executed hypervisor migrations. The complete cost includes infrastructure procurement (new hardware or cloud targets), software licensing for the alternative platform, migration tooling licenses, professional services for migration execution, application remediation (applications with VMware-specific dependencies), testing and validation, training for operational teams, and productivity impact during transition. Based on our engagements, total migration cost for a 500-VM enterprise environment typically falls between $800,000 and $2.5 million, depending heavily on application complexity.

Factor 3: Strategic Cloud Direction

If your organisation is executing a significant cloud migration — moving 40%+ of workloads to AWS, Azure, or GCP within 3 years — the argument for investing in an on-premises hypervisor migration is weaker. Migrating from VMware to Nutanix to then move those same workloads to Azure 18 months later represents capital deployed twice for the same outcome. In this scenario, the better investment is often accelerating the cloud migration itself, potentially using VMware Cloud on AWS (VMC on AWS) as a bridge that allows cloud migration without requiring a hypervisor change.

Calculating Your Migration Number

Every enterprise should calculate their "migration number" — the upfront migration investment that, over 5 years, breaks even against the additional VMware cost. Any migration that can be executed for less than this number is financially justified; any migration that costs more is not.

The formula is straightforward: Migration Number = (Annual Broadcom VMware Cost − Annual Alternative Platform Cost) × 5-year discount factor. Using a standard 10% discount rate, 5-year NPV factor is approximately 3.79. If your annual VMware saving from migration (compared to VCF pricing) is $200,000 per year, your migration number is $200,000 × 3.79 = $758,000. Any migration that can be executed for under $758,000 in total investment is financially justified on a 5-year NPV basis.

Migration Platform Options

Three platforms account for the majority of VMware migration destinations. Each has distinct strengths, appropriate use cases, and migration complexity profiles.

Nutanix AHV

Nutanix is the most direct VMware replacement, offering hyperconverged infrastructure with built-in compute, storage, and networking virtualisation. Nutanix AHV (the hypervisor) is included at no additional cost with Nutanix infrastructure licensing. The migration path from VMware to Nutanix is the most mature of any alternative, with Nutanix Move providing automated VM migration. Nutanix pricing is hardware-inclusive (or software-only for existing hardware), typically running $15,000–$30,000 per node per year for a full stack including compute, storage, and AOS software. For enterprises looking for a like-for-like VMware replacement with similar operational model, Nutanix is typically the strongest fit. See our detailed comparison: VMware Alternatives: Nutanix, Hyper-V, OpenShift Compared.

Microsoft Azure Stack HCI

Azure Stack HCI is Microsoft's hyperconverged infrastructure solution that runs on-premises but is managed through the Azure portal and billed through an Azure subscription. It is an ideal fit for organisations that are already heavily invested in the Microsoft ecosystem — Azure, Windows Server, SQL Server, Active Directory — and want unified management across cloud and on-premises. Azure Stack HCI includes Hyper-V as the hypervisor and uses Storage Spaces Direct for storage virtualisation. Pricing is based on Azure Arc billing ($10 per physical CPU core per month) plus hardware. Migration tooling from VMware to Azure Stack HCI is improving rapidly, though it remains less mature than Nutanix Move.

Red Hat OpenShift Virtualization

OpenShift Virtualization allows VMs to run inside Kubernetes pods on OpenShift Container Platform, enabling unified management of both containerised and VM-based workloads. It is the appropriate choice for organisations executing a Kubernetes-native transformation who want to consolidate VM and container management on a single platform. The migration path is more complex than Nutanix and requires more operational re-skilling. Red Hat OpenShift licensing runs approximately $10,000–$20,000 per node per year. OpenShift Virtualization is not the right choice for organisations that simply want a cheaper hypervisor — it is appropriate for organisations that are also modernising their application deployment model.

Migration Planning: The Wave Approach

For organisations that have decided to migrate, a structured wave approach is essential. Attempting to migrate all workloads simultaneously almost always results in operational failures, extended timelines, and cost overruns. The wave approach manages risk through controlled progression.

Wave 0: Infrastructure and Tooling (Weeks 1–4)

Establish the target platform infrastructure and validate core capabilities before migrating any production workloads. Set up the Nutanix, Azure Stack HCI, or OpenShift environment. Configure networking so the target environment can receive migrated VMs. Validate backup, monitoring, and security tooling on the target platform. Migrate 2–3 test VMs to validate the migration tooling and process. Resolve any tooling or connectivity issues before proceeding to Wave 1.

Wave 1: Non-Production Environments (Weeks 5–10)

Migrate development, test, and sandboxes first. These environments tolerate planned downtime, allow the migration team to build experience, and expose integration issues without operational risk. Wave 1 should cover 15–25% of your total VM count. Track migration tooling performance (migration rate, error rates, VM validation pass rates) to calibrate Wave 2 planning.

Wave 2–3: Staging and Pre-Production (Weeks 11–20)

Migrate staging and pre-production environments, working progressively toward more complex applications. This phase frequently surfaces VMware-specific dependencies — vSphere API integrations in backup tools, NSX network policies embedded in applications, SRM configurations — that require remediation before production migration. Budget 20–30% of total migration effort for dependency remediation discovered in Waves 2–3.

Wave 4+: Production Migration (Months 5–18)

Production migration proceeds in application groups, not server groups. Group VMs by application (all components of Application X migrate together), not by server (all servers in Rack 5 migrate together). Application-grouped migration reduces integration failures and allows application-level cutover testing. Maintain parallel VMware infrastructure during production wave to enable rollback if issues arise. Decommission VMware infrastructure only after 30 days of stable operation on the target platform.

Common Migration Mistakes and How to Avoid Them

Based on post-migration reviews of engagements where costs exceeded estimates, four mistakes account for the majority of overruns.

Underestimating application dependencies: The most common migration surprise is discovering that applications have deep VMware dependencies that are not visible from the vSphere console. Thorough dependency mapping before Wave 1 — including interviews with application owners, not just infrastructure scanning — is the most cost-effective investment in the migration programme.

Migrating backup before validating restore: Multiple organisations have migrated to alternative platforms and discovered that their backup software (which used vSphere APIs) no longer functions as expected. Validate backup and restore on the target platform for representative workloads before migrating production.

Neglecting network policy migration: NSX-defined network policies — micro-segmentation rules, firewall policies, load balancer configurations — do not automatically migrate to the target platform. NSX policy migration requires dedicated planning and testing, and is often the longest-lead-time component of a VMware migration.

Not retaining parallel VMware capacity: Decommissioning VMware infrastructure prematurely to realise cost savings before migration is complete creates risk without proportionate reward. The cost of maintaining parallel VMware capacity during migration is typically 10–15% of the annual saving — a worthwhile insurance premium against operational failures during cutover.

For detailed platform comparisons to inform your target platform selection, read VMware Alternatives: Nutanix, Hyper-V, OpenShift Compared. For negotiating with Broadcom if you decide to stay, see VMware Broadcom Guide 2026. Leading advisory firms such as Redress Compliance provide both migration cost modelling and VCF negotiation support, allowing enterprises to develop both paths in parallel before committing to either.