
Why your next tech upgrade must deliver real value, not just a hefty invoice
14 November 2025
Why Cyber Essentials Plus matters to us
28 January 2026
For a long time, VMware was an easy call.
You bought the licences.
You paid support.
You ran the kit until it was time to refresh.
It was predictable, capital friendly, and — most of the time — kept IT and Finance pointing in the same direction.
That world changed in November 2023.
Broadcom’s acquisition of VMware didn’t just tweak pricing. It changed how ownership works. And for organisations with recent licence purchases or perfectly serviceable hardware, the consequences landed quickly.
This isn’t a technical problem to fix.
It’s a commercial decision that now needs to be revisited — whether teams were planning to or not.
What’s actually changed
At a practical level, VMware is now a subscription-only platform.
That shows up in a few ways.
Perpetual licences are no longer available. Existing ones still run, but they now sit outside the active roadmap.
Costs move from capital spend to operating cost, regardless of how environments were originally designed or approved.
Licensing is increasingly bundled. Many organisations now need to adopt broader packages, even if they only use a portion of what’s included.
Pricing is calculated per core, with minimums that disproportionately affect high density CPUs.
None of this is abstract. It directly changes long term cost exposure and planning assumptions.
The uncomfortable bit: sunk costs
The hardest conversations tend to be with teams that invested recently — new hardware, licences bought in 2022 or 2023, refresh cycles that were meant to run for years.
Those licences still work. But without active support, they’re static. No updates, no security patches, no safety net.
For most organisations, that’s not somewhere they’re comfortable staying.
At the same time, moving away from VMware isn’t frictionless either. Not every alternative neatly fits the infrastructure already in place.
This is where decisions stall — not because options aren’t clear, but because none of them feel clean.
The four paths most organisations are weighing up
There isn’t a right answer. Just different trade-offs.
Staying put is the simplest operationally. You accept the subscription model, review what you actually need, and try to contain costs. For many, this means paying more than before in exchange for continuity and lower delivery risk.
Changing the hypervisor can reduce long term exposure, but it’s real work. Teams need to retrain. Workloads need to move. Backup, disaster recovery, and monitoring often change too. Any savings come with effort.
Moving fully to public cloud removes on-prem licensing from the equation but introduces a different kind of risk. Lift-and-shift migrations that aren’t re-architected often cost more month to month than expected. This is a strategic shift, not a quick financial fix.
Using a managed IaaS platform keeps VMware in play but passes licensing and commercial complexity to a service provider. Costs become more predictable, though control shifts as well. For some organisations, that stability is the point.
Each option can be valid. What matters is understanding the consequences before committing.
Where Darwin comes in
Darwin doesn’t have a preferred outcome here.
We don’t sell platforms.
We don’t push migrations.
And we don’t benefit from which path you choose.
Our role is to sit in front of decisions like this and slow them down just enough to get them right.
That usually means making the real costs visible, cutting through vendor noise, and helping teams reach decisions that stand up beyond the technical layer — including at board level.
The goal isn’t speed.
It’s confidence.
Thinking this through
If VMware changes are forcing decisions you weren’t planning to make yet, it’s often useful to talk them through before locking into a direction.
Darwin helps organisations step back, look at the real options, and make decisions they’re comfortable standing behind.
If that would be useful, you can get in touch via our contact page.
