VMware Broadcom Transition

Broadcom's acquisition of VMware changed how vSphere is bought, and for many organizations the renewal quote was the first sign. A VMware Broadcom transition isn't one decision. It's a series of them: which bundle you actually need, how many cores you're paying for, which workloads belong where, and whether a move off VMware pays for itself once migration effort, retraining and new backup and DR tooling are counted.

We work through those decisions with your infrastructure and finance teams, then do the engineering: right-sizing what stays, and migrating what moves, with tested rollback at each step.

What changed after Broadcom

Broadcom completed its acquisition of VMware in November 2023. The changes that matter most for planning:

• Subscriptions replaced perpetual licenses. New perpetual licenses and Support and Subscription (SnS) renewals ended. Licensing is now a per-core subscription.
• The catalog was consolidated into bundles. The main offerings are VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF). Products that used to be bought separately are now inside, or only available through, a bundle.
• Cores are counted with a minimum per CPU. Broadcom counts at least 16 cores for every physical CPU, so hosts with low-core-count processors pay for cores they don't have.
• Partner and support routes changed, which affects who can sell you a renewal and how support is delivered.

The four realistic paths

1. Stay and optimize

For many estates, staying on VMware is still the cheapest and lowest-risk option once it's right-sized. That means consolidating clusters to reduce host and core counts, replacing hosts that are over-licensed by the per-CPU minimum, retiring idle VMs, and choosing between VCF and VVF based on what you actually use. If you don't use NSX, VCF Operations (formerly Aria Operations) or the VCF lifecycle tooling, VVF may cover you. If you do, or plan to, VCF may be the better value.

2. Stay, but restructure

Some organizations stay on VMware but change the shape of the estate: consolidating several vCenters into one, moving to a VCF architecture with workload domains, or moving a site into Azure VMware Solution or another cloud-hosted VMware service to close a data center. These are VMware-to-VMware moves, usually with HCX or cross-vCenter vMotion, and they keep your tooling and skills intact.

3. Partial exit

Moving the workloads that don't need VMware's features (test and development, simple Windows and Linux servers, branch sites) to a cheaper platform, while keeping the critical tier on VMware. This reduces the licensed core count without betting everything on a new platform at once. The cost is running two platforms, with two sets of backup, monitoring and runbooks.

4. Full exit

Moving the whole estate to another hypervisor or to public cloud. It removes VMware licensing entirely, but it's the largest project: every VM converted, every integration re-pointed, DR and backup rebuilt for the new platform, and the operations team retrained. It makes sense when the license savings are large and sustained, or when a hardware refresh is due anyway.

Comparing the destinations

No platform is the right answer for everyone. This is how the common options compare on the points that usually decide the project.

Whichever destination you choose, check three things early: whether your backup and DR products support it, whether your application vendors support their software on it, and how your team will operate it on day two.

How we assess

1. Inventory. Hosts, CPUs and cores, clusters, VMs, storage and the features in use, collected with PowerCLI so the numbers are exact.
2. License position. What you own, what renews when, what your current quote covers, and how many cores you'd license after right-sizing.
3. Dependency mapping. Which applications run where, what talks to what, and which VMs have vendor support or compliance constraints that limit where they can go.
4. Cost model. A multi-year comparison of each path built on your own quotes, hardware plans and staff costs, including the one-time costs that renewal comparisons leave out: migration effort, parallel running, new tooling and training.
5. Risk review. Downtime tolerance, rollback options, DR coverage during the move, and skills on the team.

You get a written recommendation with the numbers behind it. If staying is the right answer, we'll say so.

Migration paths and execution

Moves within VMware use HCX or cross-vCenter vMotion, which keep VMs unchanged and allow live or scheduled bulk migration. Moves to another hypervisor need conversion: the VM's disks and drivers change, so each wave needs testing and a rollback plan. We use the destination vendor's tools where they're mature (Nutanix Move, Azure Migrate, Proxmox's importer) and V2V conversion where they aren't.

Execution is phased:

• Pilot. A small set of representative VMs, to prove the tooling, the driver changes and the runbook.
• Waves. Groups of VMs ordered by dependency and risk, each with a cutover runbook, test plan and rollback.
• DR and backup alignment. Protection stays in place for every VM throughout, on the old platform until the new one is protected and tested.
• Decommission. Old hosts are retired only after the license end date and the last rollback window have passed.

The detail of wave planning and cutover is on our VMware migration services page.