Services / VMware exit
When the renewal stops adding up
VMware exit & virtualization modernization
Stop paying more each renewal for the same platform. Move off VMware and traditional hypervisors onto a unified, Kubernetes-based private cloud: VMs, containers, and AI on one control plane, then run and own the result.
A fixed-scope read of the estate and the cleanest path off. Paid, typically one to two weeks, and the fee credits against the engagement if you go ahead. Not ready for that? Send us the shape of your estate and get a written reply within two business days.
What is the renewal actually buying?
A licence, and the operating model that comes with it.
Count the on-call rotations in your infrastructure team, then the ticket queues, the runbooks, the upgrade calendars. Where there are two of each, one for declarative Kubernetes and one for keeping the virtualization stack alive, you are funding two platforms and only one of them arrives as an invoice.
Renewing the licence renews that split. So does swapping it for a different vendor’s.
There is a bigger move available: one control plane you own, running the VMs you have today and the containers and AI workloads arriving behind them, instead of renting your platform.
That is worth knowing even if you renew. The strongest position in a renewal conversation is a costed, credible plan to leave, and you cannot negotiate from one you have not built. If the plan says stay, you have paid for a number you can put in front of your board. If it says go, you already have the route.
Why not just swap hypervisors?
It is the obvious move, and we looked at each of them seriously.
OpenStack
We took this one as far as a designed architecture and then stopped. Deployment has genuinely improved since: Red Hat’s current release and Canonical’s Sunbeam both run the control plane as operators on Kubernetes, and SLURP lets you upgrade once a year instead of following every release. What designing it made concrete was what comes after day one. It is a second API surface with its own services, its own upgrade path and its own failure modes, and the people to keep all of that healthy. That is the duplication we set out to remove.
Nutanix
The commercial alternative your board will have heard of, and it has opened up on storage: external arrays from Everpure, formerly Pure Storage, are generally available, Dell PowerFlex is supported on all-Dell hardware, PowerStore went generally available in July 2026, and NetApp ONTAP and Lenovo land later in the year. Two things are worth knowing before you plan around that. It runs as a compute-only cluster, so you are not using Nutanix storage at all in that mode, and Fibre Channel is not supported and is not on the roadmap, so an existing FC SAN does not come with you. The hardware was never the lock-in that mattered anyway. It is a licensed product with its own renewal cycle, so leaving one vendor relationship lands you in another.
Proxmox
Proxmox is genuinely the right answer for some estates, and it is cheaper and simpler than what we build. It has run system containers alongside VMs in one API for a decade; OCI images arrived in 9.1, and OCI application containers are still a technology preview. Its HA manager keeps guests where they should be, with a dynamic load balancer added in 9.2. What it has no native equivalent of is declarative configuration state. You can get it, through a Crossplane provider or a Cluster API provider, and the Terraform provider most people use is community-maintained and still short of 1.0, so that layer is yours to own and to upgrade. And it is not Kubernetes: if your applications already target the Kubernetes API, Proxmox is a second operating model rather than a shared one.
OpenShift Virtualization
Red Hat’s converged platform, commercially supported, and the strongest answer available if a vendor support statement is a hard requirement for the software you run. We will tell you when that is the case. It is licensed per physical node rather than per core, and the VM-only edition is priced squarely at VMware migrations, so on a dense estate the arithmetic can work in your favour. What kept us looking is the shape. It is open source and the layers underneath can be swapped, with certified alternatives for networking and storage, but the defaults are opinionated and each substitution walks you toward the edge of what Red Hat will support. If the support statement is why you bought it, that is a narrow corridor.
Harvester
SUSE’s converged platform, recently rebranded SUSE Virtualization, and the closest of these to the shape of what we build. Storage is more open than it was: since v1.5 you can bring your own CSI driver for root and data volumes, Ceph among them. What you get is a choice against a feature matrix rather than a free hand, and each option gives something up. Ceph costs you VM backup, LVM costs live migration and backup, NFS costs snapshots and backup. It runs standalone, but the moment you want multi-cluster management or guest Kubernetes provisioning the supported path is Rancher, which SUSE now sells alongside it. That is a coherent stack. It is also a stack.
Where the accelerators land
There is one more axis worth naming. On a virtual-machine-first platform the accelerator is allocated to a VM, and the Kubernetes that wants it runs as a tenant inside that VM. Nutanix is closing this with bare-metal Kubernetes nodepools, and OpenStack can live-migrate a virtual GPU now, so the gap is narrowing rather than absolute. The Kubernetes-based platforms narrow it further, though not to zero: a node still commits to one mode, containers or passthrough or vGPU, because the driver stacks differ. What changes is that VMs and containers share one cluster and one scheduler, so re-pointing capacity is a drain and a relabel rather than a platform decision.
None of these is a bad product, and one of them may be the right answer for you. What each costs you to keep is the real question, and that is what the assessment answers.
Competitor detail on this page was verified on 5 August 2026.
Where the leverage comes from
From the fact that no single vendor owns the whole stack. Every layer is a separate decision, made against your workloads rather than bundled into someone else’s product.
A platform product decides your virtualization, your storage, your networking, your backup and your observability in one purchase. Here each of those is chosen on merit, and any one of them can be replaced later without the others moving. Sometimes the right answer for a layer is a commercial product, and we will say so; it is still one layer, and it is still yours to change.
The price of that is real: nobody owns the whole stack, so nobody is on the hook for all of it. Someone has to keep the layers coherent through upgrades, and that is the work you are hiring us for. If what you actually want is one vendor accountable for everything, that is a legitimate choice and you should buy a product. We will tell you when we think that is the better answer.
What you get for the trade is room to negotiate. Support is bought where it earns its keep rather than everywhere by default, and no single supplier holds enough of the platform to set terms. Underneath that sits the part worth more than the money: a vendor’s roadmap quietly becomes your roadmap, their end-of-life dates set your upgrade schedule, their bundling decides what you run. Owning the decisions gives that back.
What we build
We lead the move onto a Kubernetes-based private cloud. The workloads that should stay virtual run as VMs on the same control plane, alongside containers. That layer is KubeVirt, which runs a virtual machine as a native Kubernetes workload, so a VM is scheduled, networked and stored by the same control plane as everything else.
The workloads that should not be virtual stop having to be. A hypervisor makes everything a virtual machine by definition; here a high-load database can run directly on the node, with the hardware underneath it and no virtualization layer in the path taking its cut.
AI is the newest example. Models, inference services, agents, gateways and MCP servers all run on Kubernetes, so if your VMs stay on a hypervisor, AI becomes a third platform to fund alongside the two you already have. Consolidate now and that work lands somewhere you already run, with the GPUs and the hardware directly underneath it.
The whole of it, the storage, the networking and security model, and the automation around them, is designed to be operated by your team, not handed over as slideware. Existing arrays are often reusable through the CSI driver their vendor already ships, which the assessment confirms before anything is bought:
- One control plane for VMs, containers, and AI workloads
- Storage chosen against the workloads that move, including the enterprise arrays you already own
- Security hardening, RBAC, and network policy built in from the start
- Multi-site layout where the estate spans locations
Where this is weakest
Everything above has a price, and you should hear it from us with the same specificity we just applied to everyone else.
- Adoption is younger, and you should price that in. Gartner’s published position is that KubeVirt stays under ten percent of on-premises production virtual machine workloads through 2028. Which side of that you are on is the first thing the assessment establishes, and if the answer is that you should buy a product instead, we will tell you so.
- The backup ecosystem is younger. Whatever you are leaving has a backup API its vendors built against for years, and a field of products matured on top of it. The equivalent for virtual machines on Kubernetes is a building block rather than a settled ecosystem. Products that cover it exist and we will name the ones that fit your estate, but the field is thinner than the one you are leaving.
- Day-to-day VM operations are thinner than the console you have now. Templates and guest customization, snapshot history, hot-plug of CPU and memory, moving a running VM’s disk between datastores, per-VM performance history: some of this is absent, some becomes a declarative change rather than a right-click.
- It changes what your team needs to know. The platform is Kubernetes, and operating it takes Kubernetes fluency alongside the virtualization knowledge your team already has. Some virtualization teams work with both already; some do not. Whether yours does is worth settling before the plan is written, because retraining, hiring, and keeping us on are all workable answers, and assuming it away is not.
- Staying current never stops. No vendor owns the upgrade path here, so someone has to own it. That is us while we run it, and it is your team if you take it back. It is real, ongoing work either way and it should be in your plan.
How the move runs
Moving a VM is a data-streaming operation: disks are streamed from the existing datastores into storage the new platform owns. The mature paths use VMware’s changed-block tracking for the warm copy, with tooling such as Forklift and the Containerized Data Importer doing the transfer. Which combination fits depends on the source environment, and selecting it is part of the assessment. Some estates support a warm copy that synchronises in the background while the VM keeps serving; others need the cutover window to cover the copy itself.
The move runs in waves. Each wave has rollback options in place, and the source estate stays until that wave is signed off, which means you carry both platforms while it runs. How long that lasts is set by your existing contract and how long you want the old estate standing as a fallback, not by us.
How many waves, and over what period, is a property of your estate rather than a number we can publish. Anyone quoting you a duration before seeing what you run is guessing, and the assessment exists to replace that guess with a plan.
What your teams get back
Engineering velocity. The estate is described once and reconciled continuously through GitOps: changes arrive as reviewed commits with a history, drift is corrected by the platform itself, and one declarative API covers VMs, containers, storage and networking. ClickOps stops being the interface.
And developers stop waiting. A modern private cloud gives them the thing most teams assume they gave up by staying on-premises: a managed Kubernetes cluster, a database, a bucket, a load balancer, an isolated network, or GPU capacity to run a model on, provisioned in minutes without a ticket. They can do it from a portal or declare it in git, so the people who want a console get one and the people who want reviewable state get that instead. It happens inside the boundaries your security team sets, isolated per team and governed by policy, on capacity you already own, so nobody is waiting on you and nobody gets a surprise invoice.
What travels and what does not
Whatever you are leaving built its capabilities around its own model, and they do not port one-for-one. Some are covered a different way here, some genuinely go, and some things you have never had arrive in exchange. You should hear that list from us rather than discover it mid-move.
- Automatic workload balancing. There is no drop-in equivalent. Balancing becomes scheduler policy, which we set with your team rather than leaving you to find the defaults.
- Live migration. It depends on the storage layer rather than being a given. The requirement is a volume more than one node can attach at once. Your array is almost certainly shared already, so the real question is whether the CSI driver its vendor ships offers multi-attach, which varies by driver and is written in its documentation. That is something you can check before you ever talk to us.
- Delegated permissions. Most hypervisors inherit permissions down a tree; here they are scoped to namespaces and tenants. Your delegation model gets rebuilt deliberately, before workloads land.
- Backup built on your hypervisor’s own APIs. That specific integration does not come with you. Whether the rest of your tooling does is a question for the assessment.
Three things people expect to lose and do not: a self-service portal is part of the design, so your teams are not handed a bare command line; observability is scoped and stood up as part of the build; and the tenant model is part of what we build rather than something you assemble afterwards: isolated namespaces, network policy and quota under one boundary. What still gets designed with you is the delegation inside it.
And some of what arrives has no equivalent where you are now, which is the part nobody puts on a comparison sheet. You cannot miss what you have never had, so the surprises run in both directions.
What you own
- No platform-wide licence. The estate-wide meter you pay today ends. Individual layers may still carry licences or support on their vendors’ terms, and nothing we put in place prices the whole estate or reprices it on a schedule you do not set.
- An exit that works. The platform can be moved, rebuilt, or handed to another firm without anyone’s permission. You still depend on something; you can leave it.
- One place for AI too. GPU workloads run on the same cluster as everything else, so the AI work does not need a platform of its own.
- A platform you can see inside. Your data, your metadata and the control plane itself are yours to inspect, audit and keep where you put them, down to reading the source of what runs your business. Nothing here is a box only its vendor can open.
Individually these are line items. Together they are the difference between running a platform and renting one.
Run it or hand it back
The default is that your team ends up running it. We stay through adoption rather than disappearing at cutover.
If you would rather not run it alone, there are two ways we stay. We operate the platform to agreed targets, or your team runs it and we take the escalations: they own the day to day and open a ticket when something is beyond them. Either is scoped and priced with you rather than sold as a standing tier, and either way the estate ends up somewhere you can run yourself if you choose to.
Where the destination is a productized platform rather than a bespoke build, that is SECO, our sovereign private cloud.
Why this practice
The work is led by a principal engineer with eight years operating VMware in production at a regional cloud provider, where it carried other companies’ workloads rather than a single in-house estate, and infrastructure work reaching back to the end of the 2000s, paired with the Kubernetes and distributed-storage depth to land the target platform. Engagements are principal-led, with senior specialists brought in as the work requires.
We have VMs that cannot be containerized. What happens to them?
They stay as virtual machines. The target platform runs VMs and containers side by side on one control plane, so a workload that should not be containerized does not have to be. The move consolidates what you run rather than converting it.
Will there be downtime?
Yes. Each wave has a planned cutover window, agreed before the wave runs. We scope the window rather than promise there will not be one.
What about our backup and DR tooling?
More of it carries than people expect, and the split is usually clean. Anything that backs up from inside the guest travels: the agent does not know what runs underneath it, and your targets, retention and off-site copies come with it. What does not travel is image-level backup built on your hypervisor’s own API, because that integration belongs to the platform you are leaving. That piece gets its replacement designed in before the first wave moves, not after.
We run software with a vendor support matrix. Does it still get supported?
That is a first-week question in the assessment, not a surprise in wave three. Some vendors certify the guest operating system regardless of what runs underneath; others name platforms explicitly. Where a vendor support statement is a hard requirement, we will tell you if a commercially supported distribution is the right answer, even though it is not what we sell.
What happens to our Windows Server licensing?
It moves with the host count and core count, so consolidation changes the number in both directions. On Windows-heavy estates this can be the larger line, which is why we size it in the assessment alongside the platform rather than after.
We are planning GPU capacity for AI. Does this help or complicate it?
It helps. A GPU can be scheduled to workloads on the same cluster as everything else, so model serving, inference and the services around them do not need a platform of their own. What it does not do is make sharing a single card simple. Passing an entire GPU through to a VM or a pod is straightforward; splitting one across several workloads is a different problem, and we size that in the assessment rather than assuming it.
Are we locked into you afterwards?
No. The platform runs on hardware you own. Any licences a layer carries are yours, held with that vendor directly. Keep us on to run it, move to another provider, or run it yourself.
Facing a renewal?
Send us a rough shape of what you run and what your renewal looks like. You will get a written reply within two business days: whether this is a fit, and what we would propose as a first step. Where you have given us enough to price it, that comes with it. No call required.