The VMware Diaspora: Lessons from a $61 Billion Arbitrage

Broadcom isn't the villain in this story. They're the debt collector.

In November 2023, Broadcom acquired VMware for $61 billion and immediately began extracting maximum value. Mass layoffs gutted the workforce. Perpetual licensing disappeared, replaced by mandatory subscription bundles. The partner ecosystem evaporated. Customers report price increases of 300-1,500%. The free ESXi hypervisor died. Automated cease-and-desist letters went out to customers with expired support contracts, including some who had already migrated away.

The strategy is working exactly as designed. VMware's operating margins jumped from around 20% to 77% under Broadcom. Quarterly costs were cut in half while revenue grew by roughly $1 billion per quarter. Broadcom's total revenue hit $51.6 billion in FY2024, up 44% year over year.

This post isn't about how Broadcom is evil. It's about how thousands of organizations built invisible prisons around themselves over fifteen years and are now surprised someone showed up to charge rent.

The Arbitrage Play

Broadcom identified something simple: the spread between VMware's old pricing and the maximum extractable revenue given customers' switching costs. Then they priced accordingly.

VMware wasn't just virtualized machines. It was the software that managed the virtualized machines. The monitoring. The backups. The failovers. The management of the management. Layer after layer of tooling, all in VMware's orbit. The talent was trained on VMware's specific way of doing things. They knew how to troubleshoot VMware's specific problems.

Broadcom looked at this and saw customers who couldn't leave. Not because of contracts or legal barriers, but because of architectural decisions made years ago that seemed reasonable at the time.

Fidelity claims they need 18-24 months to migrate away. Tesco says three years. And these are massive enterprises with deep engineering talent.

Part of this is just how big organizations work. Every decision goes through fifty committee meetings and change management reviews and C-suite flagpole runs. Big orgs can't pivot quickly, full stop. Broadcom knew this. They knew their biggest customers were giant organizations that couldn't pivot quickly, and there was no real alternative that existed for them to pivot to even if they could.

That was a good bet.

Platform Dependency is Technical Debt

Here's the thing about technical debt: it compounds invisibly until someone calls the note.

I've seen this pattern at smaller scales. One client picked a technology that was already nearing its end of cycle eight or ten years ago. They picked it because the guy they knew was experienced in it. They built their whole operational program on this old technology. Years later, that guy left. There's not a lot of talent that can work on it anymore. The idea of rewriting it is daunting. They're stuck in a paradigm that limits everything they can do.

Another client has a fax integration using a DLL that had to have been written in the late 90s or early 2000s. Twenty years old. No one even knows where it comes from or how it's supported. Their developers bend over backwards, circle around, spend hours working with this thing because they have no way of supporting it other than brute force. At the time, whoever thought "hey, we're going to integrate with fax" probably felt pretty good about it. But they built the integration tightly coupled to that specific technology.

That's the high-level problem. When you make architectural decisions that are tightly coupled to a particular technology, switching off that technology becomes a massive problem. Some technologies are safer than others. If you lock into Postgres as your database, you're probably feeling okay about it. But the VMware situation should make everyone ask: what else do we have huge tech debt problems with that we need an exit strategy for?

The Legal Theater

AT&T is alleging a 1,050% price increase. Tesco has 40,000 server workloads at risk. Siemens, the Dutch government water agency, UnitedHealthcare, and the European cloud trade group CISPE have all filed suits or complaints.

A Dutch court established a "duty of care" precedent, ordering Broadcom to provide transition support for critical water infrastructure.

I'm skeptical of this duty of care thing. The people who made the bad decisions in those cases were people who let themselves get vendor-locked on critical infrastructure. It's not unusual for big municipalities to make poor technological decisions. I've personally experienced that.

Broadcom didn't use violence to get this. They made a deal. Legally, perpetual licenses still exist. But without support renewals, which are only available at massively inflated subscription prices, customers can't get security patches. The license becomes practically worthless. Broadcom found a loophole that isn't really a loophole. They just noticed it would be really hard for people to leave and thought they could make money off that.

I wouldn't have done what Broadcom did. I have too much empathy for people. But not agreeing with something and thinking it should be illegal are different categories. They saw an opportunity and took it. The people getting screwed are the ones who built deep, single-vendor dependencies over fifteen years without contractual protections or exit planning.

The Talent Diaspora

Here's where it gets interesting. Broadcom may have misplayed their hand in a way they couldn't have anticipated.

The mass layoffs dispersed VMware talent across the industry. Nutanix is attracting 600-700 new customers per quarter. Scale Computing reported a 140% increase in new customers. Proxmox has surged as an open-source alternative for SMBs. Red Hat released a product specifically designed as a VMware replacement. AWS and Azure both have dedicated VMware migration programs, developed with help from talent that used to work at VMware.

And now those dispersed engineers are armed with something that didn't exist when Broadcom made their bet: sophisticated coding assistants.

Claude has Opus out that's quite good. OpenAI has their version. Gemini is getting better. There's a real possibility that Broadcom thought they had this arbitrage opportunity locked in, and then all of a sudden they're going to find out their talent left, got armed with AI coding assistance, and can rebuild competitive products faster than anyone expected.

I've seen this happen at smaller scales. There's a .NET validation library called Fluent Assertions that went to paid licensing. Someone wrote Awesome Assertions as a drop-in replacement. You just change the using statements.

That's what's happening to Broadcom right now. The big question is whether they realize the profits they expected before the gravy train ends.

The Great Contract Cliff

We are standing at the edge of the Great Contract Cliff right now.

Those three-year bridge agreements signed in the panic of late 2023 are hitting their expiration dates this year. The "intent" to leave is being tested by the reality of the migration. 98% of surveyed customers said they were exploring alternatives. That number represented intent. Now we get to see how many follow through.

Gartner projected VMware's market share would fall from 70% to 40% by 2029. That might be optimistic for Broadcom given what we're seeing.

Here's the uncomfortable truth that's emerged from the first wave of "fully migrated" companies: many found out their alternative required a massive reinvestment in hardware. Nutanix and Proxmox aren't drop-in replacements. They have different hardware requirements, different operational models, different skill sets. The software migration was one prison bar. The hardware refresh was another. Some organizations broke free. Others discovered they'd just moved to a different cell.

The migration tooling has matured rapidly. Every price increase accelerated competitor investment. Switching costs are a depreciating asset. But depreciation takes time, and some organizations ran out of runway before the asset depreciated enough to matter.

The AI Parallel

Everyone is currently building deep dependencies on specific AI platforms.

The VMware diaspora is a preview of what happens when you build critical infrastructure on a platform whose ownership, pricing, or terms can change overnight.

What would we do if AWS tripled their costs? I know the answer for my projects because I've thought about it. The pathway is relatively straightforward. It's not like these cloud offerings are doing significantly different things. But I've worked with clients where the answer is "we'd be in serious trouble."

When I build AI tooling, I have interfaces over everything. The Anthropic SDK is in there to interact with Claude, but there's an abstraction layer. If I had to switch that out for Gemini or ChatGPT or something local like DeepSeek or Qwen, that's not going to change any of the rest of my application. The only thing that changes is what's behind the interface.

Yes, abstraction layers have a complexity tax, and no two models behave identically under the hood. Model latency varies. Context window behavior differs. Prompt engineering that works perfectly for one model falls apart on another. But a slightly leaky abstraction is still a better exit strategy than a locked door.

This is just good software architecture. Clean architecture where you don't have dependencies from the domain into the infrastructure. You define contracts for things to interact with each other. You define interfaces. Then if any particular module gets compromised because of vendor lock-in, you just switch out that one module instead of rewriting your whole application.

Part of the VMware problem is they had concrete VMware-specific implementations at every level.

What Should Change

I wish I could say I've seen clients change their behavior after watching the VMware situation. I haven't.

Everyone says "look what happened to so and so, they did a terrible thing and now they're dealing with consequences." But they always think it won't happen to them. Human nature is that it's very difficult to learn from other people's mistakes. Many of us have to learn the hard way ourselves.

When I notice clients building tight coupling to specific technologies, I say something. The conversation is hard. People don't want to pay for things to be done right when it's cheaper to slap another band-aid on.

The conversation usually goes like this: I lay out a plan to build abstractions, wire everything up properly, create a product where changing any component is no big deal. They ask how long it will take. I say six months. They ask what we can do to get it done in two months. Or one month. Or by today.

If you give people too much truth, they find someone who will tell them what they want to hear. That's just how it works.

The One Takeaway

If this post accomplishes anything, I want people to stop thinking about how evil Broadcom is and start thinking about where they're at.

Be aware of your exit strategy. Even if your awareness is just "I don't have one."

That's the lesson. Not that Broadcom did a bad thing. But that thousands of organizations made decisions over fifteen years that seemed reasonable in the moment and created invisible prisons around themselves. Platform dependency is technical debt that compounds until someone calls the note.

Broadcom called the note. Someone always does eventually.

The question isn't whether you think they're wrong for doing it. The question is whether you've built your own prison and just don't know it yet.