VMware exit after the Broadcom licensing changes
Since Broadcom moved to subscription-only VMware Cloud Foundation and vSphere Foundation, we've been planning and running VMware exits. Every VM gets sorted into one of three places. OpenShift Virtualization, for teams that want one platform for VMs and containers. Azure VMware Solution, for a fast move with VMware tooling intact. Native AWS or Azure, for workloads ready to change. Migration then goes in waves, and we rebuild backup, DR and networking for the new platform.
- 01VM inventory and destination per workload
- 02Licence and contract timing
- 03Target platform build
- 04Pilot with representative VMs
- 05Wave migration and vSphere shutdown
The story
Told without the client's name or anything that could identify them.
A university's infrastructure group received a VMware renewal quote far above its old support bill, bundling products it had never deployed. Its fallback, Azure VMware Solution, depended on a license-included SKU that Microsoft is retiring, and the team already ran OpenShift, so it was paying for two platforms. We exported the vCenter inventory, gave every VM a destination and an owner, and lined the Broadcom subscription and SnS dates up against the migration calendar. OpenShift Virtualization storage, networking and backup were designed before any VM moved, and a pilot of Windows and Linux VMs, a database and an appliance tested performance and restores. Waves followed by dependency, and vCenter and ESXi hosts were retired as their clusters emptied.
why it was urgentOn 11 December 2023 Broadcom ended perpetual VMware licences and moved to VCF and VVF subscriptions. Azure VMware Solution is going the same way. License-included PayGo SKUs retire on 31 October 2026 and all license-included SKUs on 30 August 2027, so AVS now needs a portable VCF subscription bought from Broadcom.
- openThe renewal quote is far above last year's support bill and bundles products you never deployed.
- recurringThe perpetual licences still run. The patches stopped when SnS lapsed.
- blockedYou already run Kubernetes or OpenShift and are paying for two platforms.
- openYou budgeted for AVS with a licence-included SKU, and that SKU is going away.
The estate, before and after
Before: vSphere clusters and a second platform for containers
Windows, Linux and appliance VMs ran on vCenter-managed ESXi clusters, with backup, DR and monitoring all calling vCenter APIs. Containers ran on a separate OpenShift cluster, so the team paid for and operated two platforms.
Read the diagram as text
- Windows VMs → vCenter and ESXi clusters: runs on
- Linux VMs → vCenter and ESXi clusters: runs on
- Vendor appliances → vCenter and ESXi clusters: runs on
- Container apps → Separate OpenShift cluster: pods
- vCenter and ESXi clusters → vSAN or SAN storage: datastores
- Backup agents → vCenter and ESXi clusters: vCenter API
- DR orchestration → vCenter and ESXi clusters: vCenter API
- Monitoring and provisioning → vCenter and ESXi clusters: vCenter API
After: workloads split across OpenShift Virtualization, AVS and cloud
Most of the VMs share OpenShift Virtualization with the container apps now. Appliances that need VMware are on AVS with a portable VCF subscription, workloads that were ready to change run as native cloud VMs, and we rebuilt backup and DR for each target.
Read the diagram as text
- Windows VMs → OpenShift Virtualization: migrate in waves
- Linux VMs → OpenShift Virtualization: migrate in waves
- Linux VMs → Native AWS or Azure VMs: rehost
- Vendor appliances → Azure VMware Solution: move without conversion
- Container apps → OpenShift Virtualization: pods
- OpenShift Virtualization → Backup and DR: backup · DR
- Native AWS or Azure VMs → Backup and DR: backup · DR
- Terraform → Native AWS or Azure VMs: landing zone
How we run it, phase by phase.
5 phases take you from VMware vSphere or VCF on-premises to OpenShift Virtualization, AVS or native cloud. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
VM inventory and destination per workload
We export the vCenter inventory, including CPU, memory, storage, OS, snapshots and network attachments, and give each VM a destination. That's staying on VMware for now, AVS, OpenShift Virtualization, native cloud VM, managed service or retire.
- phase 02
Licence and contract timing
Put the Broadcom subscription terms, SnS end dates and AVS reservations on the same calendar as the migration. That shows you how few cores to renew, and for how short a term.
- phase 03
Target platform build
For OpenShift Virtualization, design storage classes, networking (OVN-Kubernetes, bridged or SR-IOV), live migration and backup before any VM moves. For AVS or native cloud, build the landing zone, connectivity and identity first.
- phase 04
Pilot with representative VMs
Push a mix of Windows and Linux VMs, one database and one appliance through the target platform's migration tooling. Then test performance, backup restore and failover before planning the real waves.
- phase 05
Wave migration and vSphere shutdown
Migrate in waves grouped by dependency, retire vCenter and ESXi hosts as clusters empty, and replace VMware-specific tooling for backup, monitoring and DR.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every VM has a destination and an owner
We marked every workload with where it goes. Stay on VMware for now, AVS, OpenShift Virtualization, a native cloud VM, a managed service, or retire.
- result 02
The renewal covers only what is still on VMware
We mapped Broadcom subscription terms, SnS end dates and AVS reservations against the wave plan. Renewals now cover only the cores still needed, for the shortest term that fits.
- result 03
VMs and containers run on one platform
OpenShift Virtualization was designed up front, down to storage classes, OVN-Kubernetes networking, live migration and backup. We built it and proved it in the pilot with real workloads.
- result 04
Backup, monitoring and DR no longer depend on vCenter
We swapped out tooling that called vCenter APIs on the new platform before its VMs moved, and the decommission plan covers vCenter, ESXi hosts and VMware tooling.
Risks we plan for
-
Tooling that assumes vCenter
Backup agents, monitoring, DR orchestration and provisioning scripts often call vCenter APIs. Each one needs a replacement on the new platform before its VMs move.
-
Storage and network performance
Storage and networking change underneath the VM. Something tuned for vSAN or a SAN may act differently on Ceph, cloud disks or a new CNI, so the pilot measures it on real workloads.
-
Appliances and unsupported guests
Vendor appliances and old guest operating systems may only be certified on VMware. Some stay on a small VMware footprint or AVS until the vendor catches up.
-
Renewal deadline pressure
Signing a long renewal because the migration slipped wipes out the savings. So the plan leaves a buffer before every contract date.
Where AI helps, and where it needs guardrails
AWS Transform has agents for VMware discovery, wave planning and network conversion. We use them to plan faster, then check their wave groupings against real traffic before trusting them. Any agent that touches vCenter or cluster APIs during migration gets short-lived, read-mostly credentials, and everything it does is logged.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
VM inventory with a destination and owner per workload
yours to keep - plan02
Licence and contract timeline against the migration plan
yours to keep - design03
Target platform design for storage, network, backup and DR
yours to keep - tests04
Pilot results with performance and restore tests
yours to keep - runbook05
Wave plan and cut-over runbooks
yours to keep - plan06
Decommission plan for vCenter, ESXi hosts and VMware tooling
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Landing zone
- The base cloud setup that workloads move into: accounts, network layout, identity and security rules, built before migration waves start.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we move to OpenShift Virtualization, AVS or native cloud?
Usually a mix. AVS is fastest because VMs move without conversion, but you still pay for VCF through Broadcom. OpenShift Virtualization suits teams that already run Kubernetes and want one platform. Native cloud fits workloads that can be resized or moved to managed services. We decide per workload, not per estate.
02Can our perpetual licences keep running after support ends?
The software keeps running. Broadcom's knowledge base says an expired support contract doesn't revoke the entitlement. You just stop getting patches and new versions, which matters most for systems facing the internet or a regulator.
03How long does a VMware exit take?
It depends on VM count, how many appliances and old guests you have, and how much VMware-specific tooling must be replaced. The pilot gives real numbers per VM type, and we build the schedule from those.
04Do you staff OpenShift and VMware engineers?
Yes, we do. OpenShift administrators, VMware engineers and cloud migration engineers, on contract, contract-to-hire or permanent terms.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study5bea655b - 01VMware blog: End of availability of perpetual licensing and SaaS services (22 Jan 2024)blogs.vmware.com ↗
- 02Microsoft Learn: Azure VMware Solution license-included service retirementlearn.microsoft.com ↗
- 03Broadcom KB: Perpetual license functionality after SnS expirationknowledge.broadcom.com ↗
- 04AWS Transformaws.amazon.com ↗
- 05Red Hat: OpenShift 4.22 release notesdocs.redhat.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it