VMware exit strategy: the cloud is BYOL now

On 31 October 2026, the last license-included pay-as-you-go deployments of Azure VMware Solution had to transition to portable VCF to remain compliant. That date closes the loophole most vmware exit strategy decks still rely on: moving to a hyperscaler no longer gets you out of a Broadcom subscription. Google, Microsoft and AWS all now run VMware Cloud Foundation on a licence you buy from Broadcom yourself. The real decision is narrower: who operates the VCF stack you are paying for, and which workloads should stop running on it at all.

By the end of this post you will know what each cloud option actually transfers to the provider, what it leaves with you, and where re-platforming is the only route that changes the licence line. Facts are as of 10 November 2026.

What changed: every hyperscaler is BYOL for VCF now

Broadcom moved hyperscalers to an exclusive "bring your own" subscription model for VCF starting on 1 November 2025, according to Google's own notice. The same notice told Google Cloud VMware Engine customers that any new committed use discounts (CUDs) bought after 15 October 2025 require VCF licences purchased directly from Broadcom plus the BYOL option of the service.

Microsoft's licensing reference is the most explicit of the three. It states that as of 1 November 2025, Microsoft no longer includes a VCF licence with new Azure VMware Solution node purchases, and it publishes the remaining dates:

Date	What Azure VMware Solution requires
15 October 2025	Eligible VCF-included vDefend Firewall cores fixed; usage above that needs a Broadcom add-on
1 November 2025	New deployments must use portable VCF
31 October 2026	License-included pay-as-you-go deployments must move to portable VCF
30 August 2027	License-included reserved instances must be exchanged for VCF BYOL reservations, or the workloads moved off the service

On AWS, Amazon Elastic VMware Service (EVS) reached general availability on 5 August 2025, supporting VCF 5.2.1 on i4i.metal instances in six regions, with a "license portability entitlement" that lets you bring existing VCF licences. It was designed around your own subscription from the start.

The three questions a VMware exit strategy has to answer now

Since the licence comes from Broadcom wherever the hosts sit, a credible plan answers three separate questions rather than one. Where do the hosts run? Who patches ESXi, vCenter and NSX? And which workloads justify leaving VCF entirely? The first two are infrastructure choices; the third is an application decision, and it is the only one that reduces the number of cores you license.

That framing matters because a hyperscaler move can still be the right call for reasons that have nothing to do with Broadcom: a data centre lease ending, hardware at end of life, or proximity to cloud-native services. It just should not be sold internally as a licensing escape. If the problem you are solving is dependence on one vendor's pricing, the reversibility test for vendor lock-in is a better lens than the hosting location.

Managed: Google Cloud VMware Engine and Azure VMware Solution

The managed services keep the familiar deal: the provider runs the VMware stack's lifecycle and you run the VMs. Google describes VMware Engine as built for "turnkey operations prioritizing operational simplicity and offloaded maintenance", with VCF 5.2 on ve1 and ve2 nodes, role-based vCenter administrative privileges, and "automated patching, updates, and monitoring managed by Google". Its licensing row in that comparison now reads BYOL portable VCF subscriptions.

Azure VMware Solution works the same way: Microsoft's responsibility matrix gives it deploy, patch and upgrade for ESXi, vCenter Server, NSX and vSAN, while you patch guest operating systems and run your VMs. New private clouds currently deploy with vCenter and ESXi 8.0 U3k, and a cluster needs at least three hosts.

What AVS adds is licence bookkeeping that is easy to miss. You register the Broadcom subscription per private cloud, and the registered BYOL cores must exactly match the deployed BYOL cores. Host types map to fixed core counts, from 36 cores for AV36 and AV36P to 64 for AV64, so three AV64 hosts need 192 registered cores. Deploying more cores than Broadcom licensed makes the private cloud noncompliant and at risk of suspension, and Microsoft reports BYOL registrations and associated customer data to Broadcom monthly.

The managed route fits a team that wants out of the data centre but not into hypervisor operations. It is the wrong choice if you need VCF 9 features today: Google's own comparison lists VMware Engine on VCF 5.2, and Azure lists vSphere 8.0 for new deployments.

Self-managed bare metal: Google's Z3 offering and AWS EVS

Google Cloud self-managed VMware on Z3 bare metal

Google's new "VMware solution on Google Cloud", announced on 28 October 2026, is generally available across 22 Google Cloud regions. It runs VCF 9.x on dedicated z3-highmem-192-highlssd-metal instances: 2.2 GHz 4th Generation Intel Xeon (Sapphire Rapids), 96 physical cores (192 hyper-threads), 1.5 TB RAM, 72 TB of NVMe storage and 200 Gbps networking per node. You get full root access across ESXi, vCenter, NSX Manager and the rest of VCF, and lifecycle is "customer-or partner-driven" through VCF Operations.

The documentation draws the line plainly. Google manages "physical facilities, bare-metal server hardware, and cloud networking infrastructure up to the hypervisor"; you procure VCF licences, deploy the stack, and apply updates and patches. You can put Google Cloud commitments and Flex CUDs toward the Z3 shapes, which is the one commercial lever on this path that Google controls.

Read the cost claims with care. Google says NVMe memory tiering "can reduce server TCO by up to 40%" and vSAN ESA "reduces storage TCO by up to 39%" against external arrays. Those are vendor figures with no published method, and Google publishes no list price for the offering in its announcement, so there is nothing yet to compare them against.

AWS EVS vs Azure VMware Solution

Amazon EVS is the AWS equivalent of the Z3 offering, not of AVS. It deploys VCF directly on EC2 bare metal instances within your Amazon VPC, and AWS lets you self-manage or use AWS Partners to operate it. InfoQ's coverage of the Google launch notes it follows similar customer-operated offerings from AWS and Oracle. AVS, by contrast, keeps the ESXi, vCenter and NSX lifecycle with Microsoft.

Option	VMware version (as published)	Who patches the VMware stack	Licence
Google Cloud VMware Engine	5.2	Google	BYOL portable VCF
Azure VMware Solution	vSphere 8.0 U3k, NSX 4.2.3.2 (new deployments)	Microsoft	Portable VCF required for new deployments
VMware solution on Google Cloud (Z3)	9.x	You or a partner	BYOL portable VCF
Amazon EVS	5.2.1 at GA	You or an AWS Partner	Licence portability

Self-managed bare metal is the right choice when your team already runs VCF well and wants VCF 9 or root-level control without owning hardware. It is the wrong choice if the reason you are leaving is that you cannot staff hypervisor upgrades: you would be moving that burden, not removing it.

What is the Broadcom VCF core minimum?

Broadcom's knowledge base article on counting cores states one minimum: you "must license a minimum of 16 physical cores for each CPU", and CPUs with fewer than 16 cores count as 16. The same article tells you to count the total physical cores across all CPUs in each host.

Many renewal guides also cite a 72-core minimum per order. That figure does not appear in KB 313548, the article Broadcom maintains for core counting. We have not found it in a Broadcom primary source, so treat it as something to confirm in writing with your reseller rather than as a rule, in either direction. On dense hardware the per-CPU floor rarely binds anyway: a Z3 node has 96 physical cores, and the counting rule means all of them need coverage.

VMware to Kubernetes migration: the only path that shrinks the VCF bill

Every option above keeps the workload on VCF, so the licensed core count follows the VMs wherever they go. Re-platforming is the only lever that removes cores from the subscription, because the workload stops needing vSphere at all.

There are two distinct moves here, and conflating them causes bad estimates. The first keeps the VM but changes the hypervisor. KubeVirt, a Cloud Native Computing Foundation incubating project, describes itself as "a virtualization API for Kubernetes" for applications in both containers and VMs on a shared platform. Red Hat's OpenShift Virtualization is built on the KVM hypervisor and included with any OpenShift edition, aimed at running traditional VMs alongside modern workloads. This route changes your operations model more than your applications.

The second move rebuilds or repackages the application to run as containers, often on a managed Kubernetes service. It costs engineering time rather than licence spend, and it only pays for applications you would be changing anyway: ones with active development, scaling problems, or a dependency on an operating system that is going out of support. A vendor appliance shipped as an OVA, or a stable line-of-business system nobody touches, rarely earns a rebuild. If you do go this way, Kubernetes implementation is a platform project in its own right, not a side effect of the migration.

The strongest counter-argument is that re-platforming a few hundred VMs costs more than several years of VCF subscription, and for many estates that is true. The answer is not to re-platform everything. It is to sort the estate so that the subscription you renew covers only the workloads that genuinely need VCF.

Renew, lift or re-platform: making the call

Start with the inventory, not the cloud. For each workload, record whether it is under active development, whether it is a vendor appliance, which OS it runs on, and how many cores it actually consumes. That list tells you how many VCF cores you need next term, which is the number every option above is priced against, whether it is your hardware, Google's Z3, AWS EVS or a managed private cloud.

Then pick the operating model for the VCF remainder. Renewing on-premises makes sense if hardware still has life in it. Managed GCVE or AVS makes sense if you want out of the data centre and away from hypervisor patching. Self-managed Z3 or EVS makes sense if you want VCF 9 and have people who already run it. And check your dates: if you have Azure license-included reservations, 30 August 2027 is the deadline that matters.

If you are weighing whether to renew, lift or re-platform, our legacy application modernization team can work through that inventory with you and separate the applications worth rebuilding as containers from the ones that should stay on VCF. We engineer the re-platforming side, not the VMware migration itself, so the conversation starts with which workloads deserve to leave.