Two Paths Off VMware: The VM Way and the Cloud Native Way

Broadcom's licensing overhaul forced this conversation. Bundled SKUs, perpetual licenses gone, and renewal quotes at 2x-10x. For most infrastructure teams, this isn't a renewal, it's a forced architecture decision on a timeline they didn't choose.

But here's the thing: you don't have one exit path. You have two. And which one you choose depends on where your organization is heading, not where it's been.

Path A, the VM Way, uses KVM plus Proxmox or CloudStack: a familiar VM lifecycle with minimal application changes, best for teams with heavy VM estates and ops tooling built around vSphere patterns. Path B, the Cloud Native Way, uses Kubernetes plus KubeVirt: containers first, VMs where needed, best for teams already investing in GitOps, CI/CD pipelines, and platform engineering. Both paths share the same storage foundation: Ceph, battle tested, self healing distributed storage that eliminates proprietary SAN dependency.

Path A is the path of least disruption for teams with large VM estates. You keep the VM abstraction, keep your operational patterns, and swap the hypervisor layer from ESXi to KVM, the same hypervisor that powers Google Cloud, AWS Nitro, and most of the world's Linux virtualization. Proxmox VE brings a web UI, cluster management, live migration, and backup with no per socket licensing, closest to the vSphere experience. Apache CloudStack brings multi tenant cloud orchestration with self service portals and API driven provisioning, more an IaaS platform than a hypervisor manager. Migration typically means exporting VMDKs from vSphere, converting them into Ceph RBD volumes, recreating VM configs in Proxmox or CloudStack, swapping VMware Tools for QEMU Guest Agent, and cutting over in phased batches. This path is best for teams with 50+ VMs, legacy Windows workloads, and ops staff comfortable with traditional hypervisor management.

Path B is the forward looking path. Instead of replacing one hypervisor with another, you adopt Kubernetes as your unified control plane for both containers and VMs. KubeVirt lets you run traditional virtual machines as Kubernetes pods, same API, same scheduling, same GitOps workflow. It isn't a replacement hypervisor, it's a bridge: it lets you run legacy VMs that can't be containerized yet alongside cloud native workloads under a single Kubernetes API, migrating to containers at your own pace. Migration typically means deploying a bare metal Kubernetes cluster, installing the Rook-Ceph operator for storage and the KubeVirt operator for VM workloads, importing VMDKs into Ceph backed volumes, and defining VMs as version controlled, GitOps deployed manifests. This path is best for teams already investing in Kubernetes and platform engineering, where the VMware exit is also an opportunity to modernize.

Regardless of which path you choose, Ceph is the storage layer. It's the only open source distributed storage system battle tested at scale for over a decade across both traditional VM and cloud native workloads: block storage for VM disks and Kubernetes volumes, S3-compatible object storage for backups and media with no AWS dependency, and a POSIX compliant shared filesystem as an NFS replacement for legacy apps. Ceph eliminates the proprietary SAN or NAS dependency that most VMware environments carry: no more vendor locked storage controllers, no more per TB licensing, no more forklift upgrades.

The exit is mandatory. The architecture you land on afterward is entirely your choice. Whether you're going the VM way or the cloud native way, we run discovery on your current VMware estate and design the right landing zone for your workloads.