Leaving VMware after Broadcom: when cloud migration makes sense and how to do it properly

What has actually changed since 2024

There are plenty of half-truths circulating about VMware licensing, so let’s start with what can be verified as of autumn 2026. According to Stackscale’s licensing overview from September 2026, two subscription bundles are sold today – vSphere Foundation (VVF) and VMware Cloud Foundation (VCF) – with a licensing minimum of 16 cores per physical processor. In several EMEA countries, only VCF has been offered since December 2025.

The same overview debunks one of the most frequently repeated claims: the 72-core minimum per order, announced to partners on 28 March 2025, was withdrawn around 10 April 2025 after partner pushback and does not apply. If your business case relies on it, your numbers are wrong.

In September 2026, reports emerged that Broadcom is preparing to bring back vSphere Standard as a subscription; according to Eric Sloof’s analysis, this came from VMware leadership at VMware Explore 2026, not from an official product announcement. No pricing, availability or commercial terms have been published, so you cannot plan around it yet.

Are customers leaving, or just threatening to?

The data points to something in between. CloudBolt’s survey of 302 IT managers in North America, published in February 2026, found that 86% of respondents are actively shrinking their VMware deployments, but only 4% have fully migrated away. Roughly half are choosing a gradual, partial transition. Nearly three quarters are moving workloads to the public cloud, and about two thirds have changed strategy at least twice since the acquisition.

The distribution of price increases is also telling: 14% of respondents reported cost increases of more than 100%, while the 25–49% band was more common. Headlines about tenfold increases therefore describe extreme cases, not the average. Note, however, that this is a North American sample; we were unable to find a comparable Czech survey.

According to a September 2025 report in The Register, Gartner expects more than a third of today’s VMware workloads to run on a different platform by 2028. At the same time, research VP Julia Palmer pointed out that a full migration takes three years or more, and that migrating purely to save money is a weak reason – it only makes sense when combined with modernization.

Disputes that round out the picture

• Tesco: according to Computer Weekly in June 2026, the retailer has been accelerating its move from VMware to another hypervisor since April 2025, aiming to complete the rollout by the end of 2027. Its lawsuit against Broadcom continues; Tesco filed an amended claim on 22 May 2026.
• CISPE: the association of European cloud providers filed an antitrust complaint with the European Commission on 19 March 2026, requesting interim measures. Broadcom rejects the allegations and points out that CISPE is funded by hyperscalers.

For planning purposes, there is only one takeaway: none of these disputes has yet produced an outcome you can rely on. A strategy built on the hope that a regulator or court will restore the old terms is a bet, not a plan.

Four paths and what each one actually solves

In practice, a single path almost never works for the entire portfolio. The realistic outcome is a combination: retire some applications, keep some, move some to the cloud and temporarily run the rest on a smaller VMware cluster.

The “VMware in the cloud” trap

Services such as Azure VMware Solution or Amazon EVS look like an elegant escape: the same tools, no datacenter. But they don’t get you away from Broadcom.

In its documentation on retiring the license-included options, Microsoft states that in November 2025 Broadcom changed the rules for all hyperscalers and now requires customers to bring their own portable VCF license. The consequences are concrete:

• license-included pay-as-you-go (PayGo) SKUs end on 31 October 2026,
• license-included reserved instances will be retired on 30 August 2027; before then you must switch to the VCF BYOL option or move the workloads elsewhere in Azure.

AWS is no different. The Amazon EVS documentation requires an active VCF subscription with portability, does not support perpetual vSphere licenses and, for four i4i.metal hosts, assumes a minimum of 256 licensed cores. That is a very high bar for smaller environments.

When migrating to native cloud makes sense – and when it doesn’t

Arguments for

• A hardware refresh or the end of a datacenter contract is approaching, so the investment would be needed anyway.
• The applications are actively developed and the team wants to use managed databases, Kubernetes or AI services.
• Load fluctuates and elasticity has measurable value.
• The company already runs part of its operations in the cloud and basic governance is in place.

Arguments against

• Stable, predictable load running around the clock on fully utilized hardware – this is where the cloud tends to be more expensive.
• Software whose license is tied to physical cores or a specific hypervisor; licensing terms must be checked with each vendor individually.
• Systems that need low latency to manufacturing technology or on-site equipment.
• A team without cloud experience and without time to learn it before the deadline.

The license price should not be the only criterion. An honest comparison counts the same things on both sides: hardware and its refresh, energy, facilities, licenses, backup and people – and, on the cloud side, also egress traffic, storage and the cost of the migration itself.

How to do the migration properly

1. Inventory and dependencies

Start by exporting all VMs, including actual CPU, memory and disk utilization over several weeks – not allocated capacity. Add the dependencies between systems and the owner of each application. Without an owner, you cannot plan a maintenance window or an acceptance test.

2. A decision for each application

AWS’s methodology for large migrations distinguishes seven strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. For large migrations it mainly recommends rehost, replatform, relocate and retire; it explicitly advises against refactoring during the migration and recommends modernizing only after the move.

That is debatable. The recommendation speeds up the move, but it assumes there will be budget and appetite left for modernization afterwards. If there isn’t, you end up with oversized virtual machines running around the clock in the cloud. A sensible compromise is to replatform whatever can be done cheaply – typically databases onto a managed service – and to rightsize already during the move.

3. A landing zone before the first migration wave

Microsoft defines a landing zone as an architecture for governing, securing and scaling a multi-subscription environment, and divides it into eight design areas: billing and tenant, identity and access, resource organization, network topology and connectivity, security, management, governance and platform automation. On AWS the logic is the same, just with accounts instead of subscriptions.

The landing zone should be built as code. Clicking through the portal by hand cannot be repeated or audited six months later; more on this in our articles on Infrastructure as Code security and AWS security.

4. Pilot and waves

The first wave should be small, low-criticality and representative – it validates networking, DNS, backups, monitoring and the rollback procedure. Compose subsequent waves by dependencies, not by org chart. Every wave needs a defined success criterion and a decision on the deadline by which you can still roll back.

5. Operations after the move

The migration does not end with the DNS cutover. Immediately after the move, set up tagging, budgets and cost alerts, logging and security monitoring – and only then decommission the old environment. Running both environments in parallel is the most expensive phase of the whole project, so it should have a fixed end date.

What to do this month

The last point is worth stressing. Even a company that ultimately stays will negotiate better terms if it has a credible exit plan in progress. Conversely, a one-year renewal to buy time is a legitimate decision – provided that year is actually put to use.

Key takeaways

• There is no exodus, but there is shrinkage. 86% of respondents in the CloudBolt survey are reducing their VMware footprint; 4% have left completely.
• Work with verified rules. The 16-cores-per-processor minimum applies; the 72-core minimum was withdrawn in April 2025.
• The decisive date is 11 October 2027. vSphere 8 reaches end of support with no upgrade path for Standard and Enterprise Plus perpetual licenses.
• VMware on a hyperscaler is not leaving Broadcom. Both AVS and Amazon EVS require your own VCF subscription.
• The license price alone is not a reason. Cloud migration pays off where it also brings modernization and a different operating model.
• Landing zone and FinOps belong before the first wave. Catching up on governance after the fact costs more than preparing it.
• Test your migration tools. The August 2026 restriction on VDDK access may change both your approach and your timeline.