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. vSphere was the default hypervisor for a reason — mature, well supported, and priced in a way that at least resembled the value you were getting (never cheap, but explainable). Operations teams could budget around it. Architects could work around it. The ecosystem around it was deep enough that you almost never had to.

Then Broadcom bought it.

Broadcom’s playbook isn’t a secret, and it isn’t new. Acquire a mature enterprise software company. Gut R&D and support headcount. Kill the product lines that don’t fit the bundle. Squeeze maximum revenue out of a captive installed base that can’t migrate overnight. They did it to CA Technologies. They did it to Symantec’s enterprise business. VMware is just the biggest, and the most damaging, run of that same play yet.

None of what follows is speculation. I build, deploy, and secure vSphere environments at scale for a living — more on that on my About page if you’re curious — so this is a field report, not a hot take. The decline is real, it’s measurable, and the enterprise community needs to start saying so plainly.

The Support Implosion: Layoffs, Consolidation, and Silence

Soon after the acquisition closed, Broadcom laid off employees across the entire VMware workforce — somewhere between 2,000 and 4,000 roles by most estimates, with professional services, customer success, and frontline technical support taking the deepest cuts. These weren’t superfluous positions. These were the engineers who actually knew the product.

Meanwhile, Broadcom moved fast on product consolidation. Standalone products that used to have their own dedicated support teams and documentation tracks all got folded under the VMware Cloud Foundation (VCF) umbrella. Institutional knowledge took the hit. Support paths went from clear to ambiguous at best, non-functional at worst.

Here’s what that actually means if you’re managing production vSphere: ticket response times are slower, escalation paths are unclear, and the engineers who actually knew vSAN, NSX-T, and vRealize deeply enough to reproduce your bug in a lab and own it to resolution? Mostly gone. What’s left is a leaner, less experienced tier-1 function armed mostly with documentation links and workaround suggestions.

For environments with compliance and SLA obligations — government networks, financial infrastructure, healthcare — this isn’t a minor inconvenience. A degraded support organization is a risk factor, full stop. It belongs in your vendor assessment documentation right next to licensing costs.

VCF: Chaos Engineering Masquerading as a Platform

VMware Cloud Foundation was pitched as the future — one integrated stack of vSphere, vSAN, NSX, and vRealize, one SKU, one deployment framework. Neat pitch. The reality’s a different story.

You’ll find VMware in enterprise datacenters for one reason: it’s so reliable it’s boring. And that’s a compliment. Hypervisors aren’t supposed to be exciting — they’re supposed to schedule workloads, not crash, and let you sleep at night. The bundle Broadcom is pushing everyone into, VCF as the only supported path forward, adds a level of complexity that fights that whole mandate directly.

The component interdependencies inside VCF create new failure domains too. You used to be able to upgrade vCenter and vSphere on whatever cadence suited your org. VCF’s lifecycle management is monolithic by design — the whole stack updates in lockstep, so the blast radius on a bad update just got a lot bigger. A buggy NSX release used to be an NSX problem. In VCF, it’s everyone’s problem. All at once.

To be fair — and I try to be, even when I’m annoyed — there are environments where VCF’s integrated approach genuinely makes sense, particularly net-new deployments with cloud connectivity requirements. But forcing VCF as the only supported path for everyone, regardless of deployment maturity or operational fit, isn’t a technical decision. It’s a business decision wearing a technical decision’s clothes.

Then there’s the elephant inside the elephant: SDDC Manager 5.x. Broadcom loves showcasing the improvements in VCF 9.x — cleaner architecture, less operational overhead, a management plane that finally acts like someone tested it before shipping. Great. The problem is the vast majority of customers running VCF today are still on 5.x, and anyone still on standalone vSphere 8 hasn’t touched SDDC Manager at all. VCF 9.x’s improvements are real. They’re also irrelevant to most of the install base.

SDDC Manager 5.x in production is an exercise in operational debt, particularly in air-gapped environments where you don’t get to just open a ticket and wait. Its lifecycle workflows are brittle. Its dependency resolution fails silently more often than I’d like to admit. Its health checks surface errors that lead absolutely nowhere useful. In environments running it at scale, a disproportionate amount of admin time goes not toward the actual vSphere stack — the actual workloads, the actual infrastructure — but toward just keeping SDDC Manager alive. A management plane that needs more babysitting than the infrastructure it manages isn’t a feature. It’s a liability. When the tool meant to simplify operations becomes its own operational burden, the platform has failed the one job it had.

VMware Broadcom Licensing Costs: Extortion Dressed Up as Pricing

This is the part everyone in enterprise IT already knows, even if not enough of us say it out loud: VMware Broadcom licensing costs have become a protection racket. The increases aren’t modest, they aren’t justifiable, and they sure aren’t mapped to any meaningful product improvement. They correlate to exactly one thing — how expensive it is for you to leave.

The shift from perpetual per-CPU licensing to subscription-only VCF bundles — which bundle in products plenty of customers neither use nor want — drove reported cost increases of 300% to 500% across a meaningful chunk of the install base. Some larger enterprises reported renewal quotes north of 10x their previous spend. That’s not a price adjustment. That’s a business calculating exactly how much it can extract before customers finally accept the sunk cost of leaving.

fig. 1 — reported VMware Broadcom licensing costs vs. pre-acquisition baseline

What makes it particularly cynical is everything the increase isn’t buying. It isn’t buying better support — we already covered that. It isn’t buying meaningful new capability either, since VCF’s core components are barely evolutionary. And it’s definitely not buying any investment in the product’s long-term health. Broadcom’s stated strategy is margin expansion. Not product development.

For public sector and government environments specifically, this creates a real problem. A lot of these orgs are locked into multi-year procurement cycles, need FedRAMP or equivalent validation before they can even consider an alternative platform, and operate under budget constraints that make a 5x licensing jump genuinely mission-threatening. Broadcom’s pricing strategy doesn’t account for any of that. It doesn’t care to.

The realistic alternatives — Nutanix AHV, Red Hat OpenShift Virtualization, Microsoft Hyper-V, or a full cloud migration — all carry real transition costs and real risks. Nobody’s pretending otherwise. But they’re being evaluated now against what VMware licensing costs today, and what it’ll cost again next renewal, not what it used to cost back when the math made sense. Run that comparison and the alternative usually wins.

Two More Topics Worth Covering

These two deserve their own full posts, but they’re part of the same story, so I’m not skipping them entirely here:

The Death of the VMware Ecosystem: What Happens to Your Third-Party Integrations?

VMware’s partner ecosystem — backup vendors, security tooling, monitoring platforms — was built around stable APIs and predictable product roadmaps. Broadcom’s consolidation is breaking that. APIs are being deprecated, partner certifications are in limbo, and vendors are quietly pulling VMware-specific development resources. This is invisible until you hit it, and when you hit it in production, it’s already too late.

Building the Exit Ramp: A Practical Framework for vSphere Migration Assessment

Not a vendor recommendation piece — an honest methodology for infrastructure architects who need to present a credible migration business case to leadership. Covers workload inventory and compatibility mapping, total cost of ownership modeling across platforms, phased migration risk reduction, and how to frame the decision in terms leadership will actually act on.

The Verdict

Broadcom bought VMware to extract value, not create it. Every decision since the acquisition closed — the layoffs, the consolidation, the forced VCF migration, climbing VMware Broadcom licensing costs every renewal — points at the same single objective. None of it makes VMware better. All of it makes VMware harder, and more expensive, to leave.

That’s the actual 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 instead of adversarial doesn’t change the damage done.

The question for infrastructure architects and IT leadership isn’t whether VMware is still the right platform anymore. It’s how fast 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 own terms.

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