The VMware price hikes are real.
VMware’s new licensing model is brutal. We’ve seen 3x, 5x, and even 20x increases with no added value or extra features that teams are supposed to justify to their CFO.
The anxiety and urgency make sense.
You need to move off the platform. But where do you go? And how do you make sure you don’t end up in the same situation again?
Some default to the cloud because it feels familiar. Others grab the cheapest option. They don’t realize they’re trading one trap for another and setting themselves up to be stuck again five years from now, facing the same pricing cliff.
You need to move away from VMware, choosing an infrastructure where your team can evolve while avoiding traps that leave your team boxed in, overcommitted, or locked into another price spiral.
When teams start planning a VMware exit, they focus on the obvious: moving the VMs.
However, they overlook the automation that runs beneath the surface: Terraform scripts, Ansible playbooks, and Puppet configurations. Not all of those scripts will port over, so you end up rebuilding more than expected.
Network transitions get missed, too. Teams forget machines live in both environments during the move. And they forget how to hand off users or what the downtime windows look like.
This is the best chance most teams will get to rethink their infrastructure. Not a full modernization sprint, but at least baking modernization into the plan.
Even with a tight runway and budget, you need a plan for what comes after. Otherwise, you’re just kicking the trap five years down the road.
Most of these people have enough time to at least consider the implications of their answer and plan effectively around them.
The issue is time, not capability.
When teams say, “We’ll figure it out later”, they don’t.
And they end up stuck again.
There are several alternatives to VMware. Many can create more problems. You should evaluate them against your current infrastructure strategy before making a decision.
Most teams default to the cloud when they get squeezed by VMware. On the surface, it makes sense. Their team’s already trained up. The company probably has workloads in Azure or AWS. There might even be a cloud-first mandate from the CIO.
But that doesn’t make it the right move.
What we’re seeing is a pattern: firms are choosing the cloud because they’re under pressure and don’t have time to explore other options. Not because they’ve weighed the tradeoffs.
It’s a knee-jerk reaction.
One usually framed as a cost-saving move. That’s where most teams get caught. Unless you’re refactoring your workloads and automating for cloud-native environments, the costs don’t drop. They simply move.
Compute is expensive in the cloud. It’s great for storage. Not for VMs.
Teams are under duress. They don’t have time to think about the long-term implications. So, they go all-in on cloud, thinking it’s safe. Twelve months in, they’re stuck in another rigid and expensive system.
We’ve seen it happen even in firms that already had a cloud footprint. The thinking goes: “We’re already on Azure, let’s just move the rest over.”
However, a wholesale shift without rethinking automation, architecture, or team capabilities leads to half-baked migrations with ballooning costs.
Even if you have a perpetual license, this isn’t a safe failback. VMware blocks updates under perpetual licenses and audits teams if they detect unauthorized activity.
We spoke with one firm currently under audit. It happens. If someone on your team updates without realizing it, and VMware catches it, you could face a massive bill.
Some teams overcorrect. They don’t want another VMware situation, so they pick something stripped-down and cheap, thinking it’ll protect them from lock-in.
One firm we know chose Proxmox. They wanted control. But now they’re stuck without enterprise features: no unified logging, no clear monitoring, no enterprise networking.
It works great in a lab. It’s not built for production at scale. And most teams don’t realize that until it’s too late.
Going Kubernetes-native gives your team a clean migration path now and the ability to modernize later.
With OpenShift Virt, you can migrate VMs now and modernize later. You don’t need to refactor out of the gate. You can lift and shift 80% of workloads and build on that foundation. OpenShift runs your VMs inside Kubernetes-native constructs using KubeVirt.
And you don’t have to commit to containers on day one. OpenShift lets you run VMs and containers side by side, so you can modernize gradually.
It’s not plug-and-play, though.
It takes planning, automation rework, and training. Most of the real work is refactoring automation (provisioning, scaling, monitoring), all tied to VMware’s stack.
Red Hat has been providing enterprise virtualization solutions for years, first with RHEV and then with OpenStack. With OpenShift Virt, they’ve taken that same experience and brought it into a Kubernetes construct.
It’s not a new offering. It has been proven over 14 years for containers, and over the last four years, it has been specifically built out for VM use cases.
Backed by IBM, they’re built for enterprise and focus on infrastructure. They’re not trying to be everything to everyone, meaning support stays clean and scalable.
And most teams don’t make this move alone. The right partner for migrating off VMware can cut your ramp-up time in half and help you avoid surprises.
Many teams rule out Kubernetes early, thinking they’re not a “Kubernetes shop.”
What they usually mean is, “We’ve never really touched containers, and it sounds complicated.”
That’s fair. Kubernetes used to break a lot. It was unstable, noisy, and hard to manage. But that’s not the case anymore. Most people still think it’s harder than it is because they’re stuck with outdated mental models.
Today, platforms like Red Hat OpenShift abstract away nearly all of that complexity. You don’t have to be a Kubernetes expert. You don’t even have to interface directly with it unless you want to. You can drive everything from a GUI, no need to constantly write YAML or master kubectl.
That’s a game-changer for teams under pressure, looking to shift away from VMware. You get all the benefits of Kubernetes without needing a team of CNCF-certified engineers.
OpenShift Virt brings that experience together: mature, enterprise-grade virtualization that’s built for real-world workloads.
Our team has successfully migrated businesses from VMware to a secure, scalable infrastructure using Red Hat OpenShift Virtualization.
These are two comprehensive examples:
Under pressure from Broadcom’s VMware price hikes, the client needed to switch to a secure alternative quickly.
Our team delivered a secure, production-ready OpenShift Virt environment despite major infrastructure gaps, limited access, and no in-house Kubernetes expertise.
The client faced a critical decision point with their virtualization strategy. Their existing VMware licensing was approaching renewal.
But with Broadcom's acquisition of VMware, they were confronted with:
We started with a pilot focused on a small-scale OpenShift deployment to validate the solution's viability before committing to full migration of their 350+ virtual machines by year-end.
Most executives are waiting too long to address VMware’s rising costs.
They know a renewal’s coming. They see the price is going up. But instead of moving now, they tell themselves, “We’ll handle it next quarter.”
They underestimate the time required to train their team and migrate to a new platform. At best, they rush to finish the migration.
Worse, they’re locked into contracts with two different providers. Or, their new platform’s prices skyrocket, and they’re back to square one.
Moving to OpenShift Virt, planning application modernization, and considering infrastructure agility helps keep your team from having to go through another fire drill in 18 months.