The VMware Double Tax: Why So Many Enterprises Stay Longer Than They Want
I recently had a conversation with a CTO at a large enterprise that perfectly captured the funding reality behind a lot of VMware decisions.
Their team had explored an alternative path. Technically, they could see a way forward. But they could not get funding for what they called the “double tax.”
For many infrastructure leaders, that double tax is the cost of paying for capabilities twice while trying not to disrupt the business in the process.
Let me unpack this.
What the VMware double tax actually is
Most VMware conversations start with a platform question. Where are we moving?
The funding problem starts somewhere else. The question becomes, what are we paying for while we figure that out?
In many enterprises, the VMware double tax has two layers.
The first is the VMware bill itself. Broadcom’s push toward bundled offerings means organizations are paying for a broader VCF stack, whether or not they wanted every part of it.
The second is the bill for the tools and platforms that those organizations already use and trust, such as networking, storage, disaster recovery, automation, and monitoring. In many cases, those products have been in place for years. Teams know how they work, processes have been built around them, and the business depends on them.
That is the double tax.
On the one hand, Broadcom says that more functionality is now included in the VMware bundle. On the other hand, Finance asks why the company is still paying for the other tools.
But we know the answer: replacing those tools is not free.
It means rebuilding integrations, retraining teams, reworking runbooks, testing for parity, and accepting disruption in places where the business may not tolerate it.
This is why the issue is bigger than licensing. It is a bundled platform strategy colliding with the reality of how enterprise environments are actually run.
Why this gets so hard to defend internally
From the finance side, the argument can sound simple. If the bundle already includes networking, automation, operations, or storage capabilities, why keep paying for the existing products?
From the infrastructure side, the answer is rarely simple.
Many of those incumbent tools are not interchangeable line items. They are tied into team workflows, operational habits, vendor relationships, and years of architecture decisions. In some environments, leaders have already spent years building around products like Cisco, dedicated DR tools, or automation platforms outside the VMware ecosystem. Walking away from those investments is not just a technology swap—it changes how the organization operates.
That is why, as uncomfortable as it may be, so many teams find themselves building a business case for keeping what they already have.
They are not defending duplicate spend for the sake of defending continuity, avoiding disruption, and buying time to build real optionality. They are trying to avoid being pulled deeper into the beguiling gravitational pull of the VMware bundled stack by default.
The disruption tax is what finance often misses
This is the part that gets lost when the conversation stays focused on license overlap.
If an organization decides to stop using the non-VMware tools it already relies on, it necessitates yet another cost: the disruption tax.
How long does it take to reach parity in a new tool?
What is the opportunity cost involved in learning the new tools and becoming proficient?
What breaks in the transition?
How much engineering time goes into rebuilding what already works today?
How does the change affect the people and teams who have spent years operating in the current environment?
From the conversations I’ve had, people are not resisting change out of complacency. They are trying to avoid making a broad infrastructure decision that will create more disruption than value in the near term.
In that situation, the double tax is not just about paying twice. It is about paying once in software overlap and again in operational disruption.
The double tax is not just paying twice. It is paying once in software overlap and again in operational disruption.
What the market is actually doing
This explains why the mass-exit narrative never matched reality.
In our January 2026 research of 302 enterprise IT decision-makers, only 4% reported completing a full migration away. A majority reported staying with VMware while actively reducing dependence (54%). More than half said they changed strategy two or more times since the acquisition.
That pattern makes sense when viewed through the lens of the double-tax problem.
Teams are not choosing between a complete “stay” and a clean exit. They are trying to avoid deepening dependence on Broadcom’s bundled stack while also avoiding a disruptive rip-and-replace of the tools and processes they already depend on.
That usually leads to a phased program where some workloads move, some stay, and some overlapping tools remain in place because replacing them would create more pain than savings in the short term.
How to make the work defensible
The organizations making the most progress are not trying to solve the entire problem at once, but making the overlap visible and then managing it deliberately.
Here are a few suggestions on how to do so as cleanly and as measured as possible:
- Identify bundle overlap early: Before the internal pressure starts, identify where VCF overlaps with tools the organization already uses for networking, storage, DR, operations, and automation. That gives leadership time to understand where questions about duplicate spend will surface.
- Build the business case around disruption, not just licensing: The relevant comparison is not just between the bundled capability and the incumbent product. It is also the cost of rebuilding the process, retraining teams, revalidating controls, and absorbing the disruption of the switch.
- Measure exposure reduction quarter by quarter: If the only success metric is a complete migration, the work becomes too easy to dismiss as a blank check. Track trapped footprint, renewal exposure, and the areas where dependence is actually shrinking.
- Stop net-new dependence growth: Even if the broader transition takes years, new workloads do not need to keep landing in the same place by default. That is one of the few ways to reduce future exposure without taking on a major upfront disruption.
The funding reality most teams run into
Even organizations that want out can end up staying longer than they planned. Not because they have decided Broadcom is the right long-term answer, but because they are trying to avoid paying for the same capability twice while also destabilizing the teams and processes that keep the business running.
The VMware double tax is not merely an overlap between the old and new platforms. It is the overlap between a bundled VMware stack and the real-world tools, workflows, and operating models enterprises already have in place.
The way through is not to ignore or hide the overlap. Rather, it is to make it visible, explain the disruption cost clearly, and reduce dependence in a sequence that leadership can actually defend. Welcome to VMware Double Tax Season.
Full research report (ungated): The Mass VMware Exodus That Never Was: The Squeeze Is Just Beginning
Want to compare notes with people living it? VMwhere? Therapy Thursdays is our biweekly discussion series. Short briefing, then open discussion and Q&A. Register here.
Related Blogs
The VMware Shakeup Hits Europe Differently: Sovereignty Isn’t a Preference, It’s a Constraint
If you’re watching the hypervisor market shift from Europe, the conversation sounds different from what it does in North America. Not because…