VMware renewal isn't the problem. The problem is where you'll be in three years.
The email arrives a few months before the deadline, and over the past two years, its tone has changed. The virtualization license renewal quote is no longer a budget line you approve without looking at it: it's a number that makes you pick up the phone. In many cases, it's doubled, in some much more, and it's changed format—from perpetual contracts to packaged subscriptions, including things you don't use and without the option to buy only what you need.
The instinctive reaction is to treat the issue as a supply problem: the price has gone up, so I'll find a cheaper alternative, migrate, and call it a day. It's an understandable reaction, and it's also the best way to find yourself in the same place three years from now.
Because the high estimate isn't the problem. It's the symptom. The problem is something else, and it's more uncomfortable to look at.
What happened, in short, and why it concerns you too
In 2023, Broadcom acquired VMware, and in the following months redesigned its business model: ending perpetual licenses, moving to bundled subscriptions, reorganizing the partner channel, and revising its service provider programs. The industrial rationale for that decision is debatable, and that's not the point. The point is the impact it had on those who use those licenses to run production.
The effect is that a decision made elsewhere, in a board of directors you don't sit on, with objectives that aren't yours, has resulted in a cost item you have to absorb, within a timeframe you didn't decide. And the sting isn't even the raise itself. It's the realization of how little room for maneuver you had.
This is the real lesson from Broadcom, and it applies far beyond VMware: when your infrastructure depends on technology you don't control, you're not buying a service. You're renting your very operations under conditions that someone else can change. As long as the conditions are good, you don't notice. The day they change, you suddenly discover where the line was drawn between what you decided and what the vendor decided.
The trap within the trap
And this is where the instinctive reaction—I'll change supplier, I'll get the cheapest one—becomes dangerous.
Because if the only criterion you use to choose a replacement is price, you're optimizing the wrong variable. Today's price is a snapshot. It tells you how much it costs to enter, not how much it will cost to stay, and above all, it tells you nothing about how much it will cost to exit when—not if, when—this supplier also decides it's time to reconsider its terms.
We've written in another article that the true cost of lock-in is invisible until you try to leave . The post-Broadcom migration is a perfect example. Thousands of organizations are now discovering how high that cost is, and the temptation is to pay it once to move to another equally locked-in platform, perhaps another proprietary hypervisor, perhaps a hyperscaler that solves the licensing problem by creating the larger problem of dependence on someone else's infrastructure.
It would be like leaving a locked room and entering another locked room, and feeling free because the door remains open for a while.
The right question isn't "what's the cheapest alternative to VMware." It's: How can I make this the last forced migration I experience?
What changes if you set the choice on reversibility?
Changing the criteria changes everything else. If the yardstick is no longer the entry price but the freedom to exit, the options on the table rearrange themselves.
Open source technologies are no longer "the free alternative" but are becoming the ownerless alternative. The value isn't that OpenStack or Proxmox VE don't cost a license; that's an accounting detail. The value is that no company can be acquired by another and unilaterally redesign your business model, because no single company owns the technology. The code is open, the standards are public, and if you want to change partners one day, you keep the platform. You change who manages it, not what runs it.
TCO should be calculated over the entire cycle, not the first year. An honest comparison between continuing with VMware and migrating to open source isn't based on the cost of license savings. It includes migration, training, process adjustments, and any specialized support. In the first year, migration can cost more than renewal. It's in the third, fifth, and especially at the deadline, when you won't have to renegotiate from a position of weakness, that the numbers change. Those who sell migrations tend to hide this; we prefer to say it, because a decision based on real numbers holds up, while one based on enthusiasm doesn't.
Migration becomes a project, not a leap in the dark. The reason many organizations stick with a technology they no longer want isn't because they prefer it: it's the fear of cut-over, downtime, and "what if something breaks in production." It's a legitimate fear, and the answer isn't to minimize it but to make it manageable—preventive assessments, infrastructure described as code, wave migrations with minimal downtime, and a revert path if something doesn't work. The difference between a scary migration and one that can be approved by a board is entirely in the method.
The point that almost no one puts on the table
There's one thing that, in the rush to replace VMware, often gets put off until later—and now is the right time to address it, because you're already getting your hands on the infrastructure.
A forced migration is painful, but it's also the only time an organization truly stops to look at its structure. It's the moment you can decide not only what to run, but how to govern it: who accesses what, how operations are tracked, how much you depend on a handful of people to keep everything running, and whether the automation you introduce stays within your perimeter or crosses it.
Those who treat migration as a simple move—I'm moving machines from shelf A to shelf B—miss this opportunity and, in a few years, find themselves having to start over from scratch. Those who treat it as a time to redesign infrastructure governance emerge from the migration in a structurally different position: they haven't just changed hypervisor, they've changed who owns their own house.
It's the difference between reacting to someone else's decision and taking your own decision into your own hands.
What does it mean for us to support this choice?
We could describe the VMware migration the way many do: a list of tasks, a promise of near-zero downtime, a reassuring "we'll take care of it." That would be true, but that would be the easy part.
The important part is something else. When we help an organization out of VMware, our goal isn't to make them dependent on us instead of Broadcom—that would be the same movie with a different title. It's to leave them in a position where, if they wanted to do without us, they could. The infrastructure is entirely open source, the data is under their control, everything is described as code in their own repositories, and there are no contractual obligations tying the technology to our presence.
It's a way of working that, on the surface, works against us: a customer who can easily leave is a customer we have to earn every year. But that's exactly the point. We prefer a relationship where we stay because we serve, not because you're stuck. It's the only type of relationship that, after the Broadcom experience, an organization should be willing to accept, and the only one we're interested in offering.
Because the real lesson of these two years isn't "VMware has become expensive." It's that technological independence isn't an ideological luxury: it's a form of risk management. And like any risk management, it's built when things are going well, not when the renewal email arrives.
Shall we talk about this before the next deadline?
If you're considering what to do with your VMware environment, even just to understand how much it would really cost and how long it would take, we can give you an honest picture: an assessment of the environment, a realistic estimate of the entire time and cost cycle, and a migration path you can share with your board without having to put your trust in us.
Comments