For years, VMware was the obvious answer. You needed to run workloads, you needed isolation, you needed enterprise support, and VMware delivered all of that reliably. Nobody questioned the bill.
That's changed. Not because VMware got worse, but because the world around it moved on. Most enterprise workloads are containerized today. Development teams ship to Kubernetes. Platform teams manage clusters, not VMs. And yet, a lot of organizations are still renewing six- or seven-figure VMware licenses, essentially paying a premium for a virtualization layer that's sitting underneath infrastructure that no longer needs it.
It's worth asking the question: what exactly are you paying for?
When you run Kubernetes on top of VMware, you're running a container orchestration platform on top of a hypervisor on top of physical hardware. That's three layers where two would do. The hypervisor isn't adding much at that point. Kubernetes handles scheduling, isolation, and resource management on its own. But the license invoice doesn't care about that.
For large enterprises with significant on-premises footprints, this adds up fast. We're talking hundreds of thousands of euros per year, sometimes more, going to a software layer that's no longer pulling its weight.
The alternative isn't complicated in principle. If your workloads run in containers, run Kubernetes directly on bare metal. Remove the hypervisor entirely. One less layer, one less license, no meaningful loss in functionality for the workloads that matter.
This is exactly what the Giant Swarm platform supports. Our curated, open source stack runs directly on bare metal nodes, and we manage and operate it for you. Built from 10+ years of production experience across 150+ clusters, it's production-proven at large organizations and ready in days, not months. Companies that have made this move have eliminated a substantial share of their VMware spend, sometimes all of it.
Of course, most enterprises have a mix. Some workloads are fully containerized. Others still depend on virtual machines: legacy applications, specific compliance requirements, software that was never designed for containers. For those situations, you have two sensible options.
The first is to keep a small VMware footprint alongside your Kubernetes environment. You shrink the licensed surface dramatically, keeping VMs only where they're genuinely needed. That alone can cut licensing costs significantly without requiring a big-bang migration of everything at once.
The second option, for organizations where the remaining VM workloads are small enough, is to eliminate VMware entirely by running VMs inside Kubernetes using KubeVirt. Your teams get a single platform to operate, and your finance team gets a much cleaner invoice.
There's one practical wrinkle worth addressing. Enterprises that have historically relied on virtualization often have large, powerful physical servers sized to be carved up into many VMs. In bare metal Kubernetes, one physical server becomes one Kubernetes node. That works well for many setups, but if you want to run many smaller, separate clusters, it can create challenges around resource efficiency.
This is where open source hypervisors like Proxmox come in. Proxmox has seen remarkable adoption growth over the last few years, and for good reason. It gives you the virtualization flexibility of a traditional hypervisor without the proprietary licensing costs. The Giant Swarm stack supports Proxmox as an underlying infrastructure layer, and we can run it for you just as we do with bare metal. You get the flexibility to slice up hardware as needed, with a fully open source stack from top to bottom.
This matters beyond just the cost line. Proprietary infrastructure creates lock-in. License negotiations happen on the vendor's terms, not yours. When Broadcom acquired VMware, many enterprises were reminded of this the hard way. Pricing structures shifted, and customers who had assumed stable costs found themselves facing very different renewal terms.
An open source stack doesn't work that way. The software is transparent, the community is large, and the economics don't change based on a corporate acquisition. With Giant Swarm, there's no vendor lock-in by design. Your infrastructure, your data, your rules. Every component is yours to keep.
One more thing that tends to surprise people: how quickly this can actually happen. Replacing VMware sounds like a multi-year transformation project, and a full exit genuinely can take time. Industry estimates put a complete migration at 18 to 48 months depending on environment complexity. That's realistic for large enterprises with legacy dependencies.
But a full exit isn't the goal in year one. What works is footprint reduction. You start with workloads that are already containerized or container-ready: stateless applications, dev and test environments, new services that haven't been built yet. These move first, often within weeks. Critically, nothing new goes on VMware again.
The existing VMware environment keeps running for workloads that aren't ready to move. That's fine. The bill starts shrinking as soon as the first workloads move, and it keeps shrinking as the new platform grows.
In practice, with a curated platform like Giant Swarm, already running in production at organizations like adidas, Vodafone, and Deutsche Telekom, you can have the new environment live and proving itself quickly. The platform is hardened, pre-integrated, and operated by a team that carries the pager so yours doesn't have to.
The question of whether to re-evaluate your virtualization spend isn't really a technology question anymore. The technology is ready. It's a business question: how much longer do you want to pay for infrastructure your architecture has largely already moved past?
If you're curious what that would look like for your environment, we're happy to talk.