VMware Is Now a Threat Actor
to Its Own Customers

The Acquisition That Changed Everything

For close to 20 years VMware held a special place in enterprise IT. There was a reason why vSphere was the default hypervisor platform – it was mature, it was well supported, and its licensing model, while never exactly affordable, at least had some semblance to the actual cost and value of what you were running. Operations teams could budget. Architects might be able to work around it. Its surrounding ecosystem was deep and well understood.

Then Broadcom bought it.

Broadcom’s playbook isn’t a secret. They acquire mature enterprise software companies, gut R&D and support headcount, kill off product lines that don’t fit their bundle strategy, and get maximum revenue from a captive installed base that can’t migrate overnight. They did it with CA Technologies. They did it with Symantec’s enterprise business. VMware is simply the biggest – and most damaging – execution of this playbook to date.

What follows isn’t speculation. This is a field report from someone who builds, deploys and secures vSphere environments at scale. The decline is real, it is measurable and the enterprise community needs to be talking about it straight.

The Support Implosion: Layoffs, Consolidation, and Silence

Soon after the acquisition closed, Broadcom laid off employees across the entire VMware workforce. The cut is estimated at somewhere between 2,000 and 4,000 roles, with professional services, customer success and frontline technical support taking particularly deep cuts. These were not superfluous positions. These were the engineers who knew the product.

Broadcom meanwhile moved faster on product consolidation. The standalone products with their own dedicated support teams and documentation tracks were folded under the VMware Cloud Foundation (VCF) umbrella, creating disruption to institutional knowledge, and making existing support paths ambiguous at best and non-functional at worst.

The tangible consequence for those managing production vSphere environments is that ticket response times are slower, escalation paths are unclear, and the engineers who had deep institutional knowledge of products such as vSAN, NSX-T and vRealize, who could reproduce your bug in a lab and own it through resolution are mostly gone. They have been replaced by a leaner, less experienced tier-1 function that relies on links to documentation and suggestions of workarounds.

For environments with compliance and SLA obligations — government networks, financial infrastructure, healthcare — this is not a minor inconvenience. A degraded support organization is a risk factor. It belongs in your vendor assessment documentation alongside licensing costs.

VCF: Chaos Engineering Masquerading as a Platform

VMware Cloud Foundation was introduced as the future: a single, integrated stack of vSphere, vSAN, NSX and vRealize under one SKU and one deployment framework. The pitch is neat. The reality is a different story.

You’ll find VMware infrastructure in enterprise datacenters because it is so reliable it’s boring. Hypervisors don’t have to be exciting. They have to schedule workloads properly, not crash, and let you sleep at night. The product lines that Broadcom is pushing customers into — particularly VCF as the required bundle for anyone who wants to remain on a supported path — add a degree of complexity that is fundamentally at odds with that mandate.

The component interdependencies within VCF also introduce new failure domains. Previously, you could upgrade vCenter and vSphere independently on a cadence that suited your organization. VCF lifecycle management is monolithic by design — updates must be applied across the full stack in lock-step, meaning the blast radius of a problematic update has grown considerably. A buggy NSX release in a standalone deployment used to be an NSX problem. In VCF it’s everyone’s problem, simultaneously.

To be fair, there are environments — particularly net-new deployments with cloud connectivity requirements — where VCF’s integrated approach makes architectural sense. But Broadcom’s decision to make VCF the only viable forward path for the majority of customers, regardless of deployment maturity or operational fit, is a business decision dressed up as a technical one.

Then there is the elephant inside the elephant: SDDC Manager 5.x. Broadcom has made a point of showcasing the improvements in VCF 9.x — a cleaner architecture, reduced operational overhead, a management plane that finally behaves like a product someone tested before shipping. The problem is that the vast majority of customers running VCF today are on 5.x, and those still on standalone vSphere 8 haven’t touched SDDC Manager at all. VCF 9.x’s improvements are real — and completely irrelevant to most of the install base.

SDDC Manager 5.x in production is a exercise in operational debt particularly in air-gapped environments. Its lifecycle management workflows are brittle, its dependency resolution frequently fails silently, and its health checks surface errors that lead nowhere useful. In environments running it at scale, a disproportionate amount of administrative time goes not toward managing the vSphere stack — the actual workloads, the actual infrastructure — but toward keeping SDDC Manager itself alive. A management plane that requires more babysitting than the infrastructure it manages is not a feature. It is a liability. When the tool designed to simplify operations becomes its own operational burden, the platform has failed its core design objective.

Licensing Extortion: Pricing That Has Little to Do With Value

This is the part everyone in enterprise IT knows but not enough of us are say out loud. VMware licensing under Broadcom has become a protection racket. The increases are not modest, not justifiable, and not mapped to meaningful product improvements or new capability delivery. They are correlated to one thing: the cost of migrating away from VMware.

The shift from perpetual per-CPU licensing to subscription-based VCF bundles — which bundle products many customers don’t use and don’t want — resulted in reported cost increases of 300% to 500% for a significant portion of the install base. Some larger enterprises reported renewal quotes that were more than 10x their previous spend. This is not a price adjustment. This is an business calculating the maximum it can extract before customers accept the sunk cost of migration.

What makes this particularly cynical is what the licensing increase is not buying. It is not buying improved support, as discussed above. It is not buying meaningful new capability — VCF’s core components are barely evolutionary. And it is certainly not buying organizational investment in the product’s long-term health. Broadcom’s stated strategy is margin expansion, not product development.

For public sector and government environments, this creates a very specific problem. Many of these organizations are locked into multi-year procurement cycles, require FedRAMP or equivalent compliance validation before migrating to alternatives, and operate under budget constraints that make a 5x licensing increase genuinely mission-threatening. Broadcom’s pricing strategy does not account for — and does not care about — these constraints.

The realistic alternatives — Nutanix AHV, Red Hat OpenShift Virtualization, Microsoft Hyper-V, or full cloud migrations — all carry transition costs and risks that are real. But they are now being evaluated not against what VMware licensing used to cost, but against what it costs now and what it will cost on the next renewal cycle. That calculation looks very different and is often in favor of the alternative.

Two More Topics Worth Covering

These two threads deserve their own full posts, but they’re part of the same story:

The Verdict

Broadcom bought VMware to extract value, not create it. Every decision made since the acquisition closed — the layoffs, the product consolidation, the forced migration to VCF, the licensing restructuring — is consistent with that single objective. None of it is designed to make VMware better. It is designed to make VMware harder and more expensive to leave.

That is the definition of a threat actor: an entity whose actions create risk and harm to the systems and organizations it has access to. The fact that VMware’s access is contractual rather than adversarial doesn’t change the damage.

The question for infrastructure architects and IT leadership is no longer whether VMware is still the right platform. It is how quickly you can responsibly build the exit ramp, and whether you start now — while you still have the budget, the time, and the leverage to do it on your terms.

The default answer is no longer VMware. That’s not a rant. That’s a change control.