Part 3 of 3. Read Part 1: why companies are making the move | Read Part 2: Aria vs CMP
By the time an organization finishes replatforming Aria into CloudBolt CMP, one thing has changed that is easy to see: the automation and governance layer is no longer tied to VMware. CMP’s blueprints, approval workflows, and policy enforcement work the same way regardless of what runs underneath.
That changes the shape of the conversation about leaving Broadcom. It stops being a binary decision made once and lived with for a decade, and becomes something a team can test in a controlled environment, next to production, on its own schedule. Four options make up most of the shortlist: Nutanix AHV, Red Hat OpenShift Virtualization, Proxmox VE, and public cloud.
Why VCF Automation forecloses the option
VCF Automation is built to orchestrate VMware and a defined set of public cloud endpoints. It was never built to provision or govern Nutanix, OpenShift, or Proxmox. Choosing that upgrade path removes the option to test anything else without standing up a second, disconnected tool.
CloudBolt CMP takes a different approach. The same blueprints, approval chains, and cost controls that already govern a VMware estate extend to another platform as soon as it is connected. Once the orchestration layer is vendor-agnostic, testing an alternative becomes a normal governed pilot: a handful of workloads, real data adjacent to production, real automation, and a real comparison, without touching the production VMware environment those workloads still depend on.
This also does not require picking one destination. Most organizations are routing different workloads to different landing spots at the same time, with some VMs onto Nutanix, some applications replatformed onto OpenShift, some services lifted into public cloud, and the rest of the estate staying on VMware for now. CMP orchestrates all of that under one set of blueprints and one governance model, so a workload moving from VMware to Proxmox this quarter does not disrupt the automation still managing everything that has not moved.
No team ends up running two disconnected tools or racing toward one hard cutover date for the whole estate.
What changes when you add platforms
Each platform brings its own tooling, lifecycle and operating model. The four most common VMware alternatives each arrive with a full stack of their own.
| Platform | Console | What comes with it |
| Nutanix | Prism Central | AHV lifecycle, Calm automation, separate licensing |
| Proxmox | PVE Cluster Manager | KVM virtualization, Ceph storage, community tooling |
| OpenShift | OpenShift Console | Operators, GitOps, SDN, SCC and RBAC |
| Public cloud | Cloud console | IAM, native services, consumption billing |
The result is five sets of lifecycles, APIs, toolchains, policies and required skills where there was previously one.
Why governance is the part that breaks
Governing several hypervisors to one consistent standard is harder than adding any one of them. Six things multiply at once, and each one carries its own cost.
| What multiplies | What it costs you |
| Consoles | Constant context switching |
| APIs | Custom integrations for each platform |
| Automation frameworks | Inconsistent workflows and runbooks |
| Security models | Policy drift and gaps that increase risk |
| Upgrade cycles | Hard to plan and expensive to maintain |
| Teams | Siloed skills and operational overhead |
The compounding effect is that there is no single source of truth, and operational risk grows with every platform added. Keeping the control plane vendor-agnostic is what stops each new platform from adding another silo.
Replacing one hypervisor with several replaces one console with four, and one policy model with four.
Four options worth testing
None of these are mutually exclusive, and most organizations end up piloting more than one at the same time.
Nutanix AHV
Nutanix AHV is the most enterprise-ready of the four. It is the hypervisor inside Nutanix’s AOS stack, bundling compute, storage, and networking into one platform, and it has become one of the two realistic destinations for large VMware estates with 200-plus VMs and DRS or SRM-level complexity. Nutanix backs the transition with dedicated migration tooling and over a decade of production hardening. The tradeoff is architectural: AHV’s strongest features, including Flow network security and its Kubernetes engine, are exclusive to the Nutanix stack, so testing it properly means evaluating the whole platform rather than just the hypervisor. CMP connects to Nutanix as a pre-built integration, so a pilot runs through the same blueprints already governing VMware.
Red Hat OpenShift Virtualization
Red Hat OpenShift Virtualization has become the default answer for organizations that want to run VMs and containers on the same platform. Red Hat’s Migration Toolkit for Virtualization converts VMware VMDK images into KubeVirt-compatible volumes, and Red Hat expanded its free, self-service migration assessments in 2026 to make evaluation easier. The honest caveat is maturity. Live migration, scheduling, and storage have functional equivalents to vMotion, DRS, and vSAN, but they require more manual configuration and are less mature today. CloudBolt added resource handler support for OpenShift Virtualization in the May 2026 release, so pilots run under the same governance as everything else.
Proxmox VE
Proxmox VE is the mid-market’s consensus pick: open source, free to run, with feature parity to VMware’s core compute, storage, and HA stack. Adoption has surged since the Broadcom acquisition. It is the right fit for organizations with roughly 50 to 200 VMs and less need for the audited change control and guaranteed vendor response times that larger enterprise buyers expect. Proxmox is not among CloudBolt’s named pre-built connectors the way Nutanix and OpenShift Virtualization are, so connecting it runs through CMP’s Python-based extensibility, the same path that covers any system with an API and no native handler. That means a little more setup at the start of a pilot, and the same blueprints and governance model once it is connected.
Public cloud
Public cloud is the fourth option and not a hypervisor at all. Lifting VMs into AWS, Azure, or GCP, or re-architecting them as cloud-native services, removes the hypervisor question entirely. CMP already treats AWS, Azure, and GCP as first-class, pre-built endpoints, so a workload can be piloted on public cloud under the same blueprints and cost controls as everything else, with real cost visibility before anything deploys. For workloads where the economics or the compliance requirements do not fit a hyperscaler, this option will not apply, which is itself useful information to have before committing to a broader exit plan.
Where leverage actually comes from
Leverage at renewal comes from having a real alternative rather than a stated intention. A team that has piloted 40 workloads on Proxmox, under the same governance model it runs in production, with cost and performance data to compare, is in a different position than a team that has read about Proxmox. The pilot is the leverage, and it holds whether or not it ever expands. CloudBolt CMP is free for up to 100 resources if you want to run one.
The pilot is the leverage, and it holds whether or not it ever expands.
A renewal conversation goes differently when the customer has somewhere to go and can show the work. That is a large part of why teams are running these pilots ahead of the contract date rather than after it.
That is also why the incremental approach matters more than the destination. CloudBolt’s CII Reality Report 2026 found that 63% of organizations have changed their VMware strategy two or more times since the acquisition, and that 41% report intensified executive pressure. Strategies that require a single irreversible decision do not survive that much churn. An approach where each pilot is independently useful, and where nothing has to be committed before it is tested, does.
The bottom line
The platforms underneath stay different. What changes is that one layer governs all of them.
Nutanix, OpenShift Virtualization, Proxmox, and public cloud each solve a different version of the same problem, and no organization needs to guess which one fits before finding out, or force every workload toward the same answer. CMP turns that decision into something that can be tested and then run at scale, with governed pilots, real automation, and real data adjacent to production, while different workloads move to different destinations on their own timeline and everything else stays governed on VMware.
That is what a controlled VMware exit looks like in practice: a series of measured, simultaneous moves run on an orchestration layer built to outlast whatever Broadcom decides to do next.
Run a governed pilot on your own estate
Start building for free
Download PDF
Related Blogs
The VCF 9 upgrade guide | Part 1 – Why companies are making the move
Part 1 of 3. Read Part 2: Aria vs CMP | Read Part 3: after the Aria upgrade For most…
