A practical sequencing guide for teams migrating off VMware post-Broadcom pricing changes, comparing Nutanix, Proxmox, and bare metal Kubernetes as replacement options. It recommends locking the container infrastructure decision first, then migrating stateless workloads, followed by workloads with external state, and leaving storage-performance-dependent workloads for last. It also notes that Cluster API (CAPI) lets teams run mixed environments across hypervisor choices without a single irreversible bet, and that migration timelines routinely slip due to compliance and reprioritization.
Table of contents
What's actually changed since we wrote the pricing math?Which of the three options actually fits your workload?So what do you actually move first?Why does this always take longer than planned?Why can one platform carry all three paths?Where do you actually start?Questions this post answers
What order should I migrate workloads in when moving off VMware to Kubernetes-based infrastructure?
Lock the container infrastructure decision first, such as choosing between K3s and full Kubernetes, since changing it mid-migration unravels the plan. Then move fully containerized stateless workloads first for low risk, followed by workloads with external state but no exotic storage needs, and leave anything with untested storage-performance dependencies for last. Teams planning a VMware exit can track migration playbooks like this one on daily.dev.
How does Cluster API let me run Nutanix, Proxmox, and bare metal Kubernetes together during a migration?
Cluster API (CAPI) is a Kubernetes sub-project providing a declarative, infrastructure-agnostic way to provision and manage clusters, with each infrastructure target having its own CAPI provider implementation. The operational model on top, including GitOps, upgrades, and observability, stays consistent regardless of hypervisor choice, letting teams run mixed environments during a transition instead of making one irreversible bet. Engineers comparing infrastructure options for a VMware migration can follow developments like CAPI on daily.dev.
Is Proxmox always faster than VMware or Nutanix for storage-heavy workloads?
Not necessarily. One manufacturing customer's own benchmarks showed their existing setup running 2-4x faster than Proxmox on their specific storage backend, because it used a different storage driver, underscoring that newer infrastructure choices should be tested against actual workloads rather than assumed to be faster. Teams weighing Proxmox against existing hypervisors for storage-sensitive workloads can compare real benchmarks on daily.dev.