By Adrián Cameselle • Updated August 14, 2026 • 5 min read
A practical, step-by-step engineering playbook for IT directors, infrastructure architects, and platform teams migrating virtual machines, storage volumes, and Tanzu Kubernetes workloads off VMware to open infrastructure.
When organizations evaluate a VMware alternative, the primary technical obstacle is not the hypervisor itself; it is the entire software ecosystem surrounding it. Moving off vSphere requires mapping every layer of your current stack to an open, production-grade equivalent.
Every layer maps to an open equivalent: ESXi to KVM under Nova, vCenter to the Keystone, Nova and Neutron APIs behind one console, Tanzu to standard CNCF Kubernetes, NSX to Neutron with OVN, and vSAN or VMFS to Cinder across your existing arrays. The mapping itself is settled; what decides the project is who operates the result.
The estate-by-estate breakdown, including what each piece becomes operationally, lives on the VMware alternative page. This guide covers the execution.
2. Phase 1: inventory and sizing before you move anything
Before moving any production workload, run an inventory audit across your vSphere clusters. Categorize workloads into two distinct migration paths:
Stateful Legacy VMs: Monolithic workloads requiring disk image conversion ( → QCOW2/RAW) and static network mapping.
Containerized / Cloud-Native Workloads: Stateless applications and container microservices running on Tanzu that can be redeployed directly via Helm charts or CI/CD pipelines onto standard Kubernetes on OpenStack.
3. Phase 2: ingesting virtual machines and disk images
Virtual disk migration relies on proven Linux virtualization toolchains to convert VMware proprietary formats into standard OpenStack Glance images:
Step 1: direct disk conversion with qemu-img
For standalone virtual disks, convert the VMDK directly to a raw image or QCOW2 sparse format:
# Convert VMDK streamOptimized or flat image to raw format for OpenStack Cinder/Glance qemu-img convert -p -f vmdk -O raw enterprise-db-disk1.vmdk enterprise-db.raw
# Alternatively, convert directly into OpenStack Glance image catalog openstack image create "Ubuntu-24-Production-Base" \
--file enterprise-db.raw \
--disk-format raw \
--container-format bare \
--property hw_qemu_guest_agent=yes \
--public
Step 2: automating driver injection with virt-v2v
For complex Windows Server or enterprise Linux VMs with specialized SCSI controllers, automatically converts the VM and installs the necessary KVM VirtIO drivers:
4. Phase 3: redeploying Tanzu workloads on standard CNCF Kubernetes
VMware Tanzu often couples teams to vSphere-specific storage classes () and bundled hypervisor licensing. Migrating to edgeContinuum restores standard upstream Kubernetes:
Provision Standard CNCF Clusters: Using the edgeContinuum console or API, provision a new managed cluster on OpenStack in minutes, selecting either dedicated or hosted control planes.
Standardize Storage Classes: Replace proprietary vSphere CSI volume claims with standard OpenStack Cinder CSI claims ().
Export & Replay Helm Manifests: Because edgeContinuum runs unmodified upstream Kubernetes, standard Helm charts, ArgoCD, or Flux GitOps pipelines deploy with zero code changes.
5. Phase 4: day-two operability and self-service
Many VMware exit plans stall because teams fear the operational complexity of raw OpenStack CLI and Horizon. This is the exact gap edgeContinuum resolves:
Self-Service for Developers: Developers deploy Kubernetes clusters, managed PostgreSQL databases, and VMs directly from a public-cloud-like UI or Terraform.
Desired-State Self-Healing: Cluster scaling, rolling version upgrades, and node failure recoveries reconcile automatically in the background.
Hard Multi-Tenancy: Complete project boundaries with CPU/RAM/Storage quotas, IAM access controls, and per-tenant usage accounting for service providers and enterprise business units.
✓ Storage pools in Cinder validated with required IOPS and QoS limits.
✓ DNS TTL values lowered to 300s prior to final maintenance cutover window.
Planning a VMware exit? Review your architecture with us
Talk to our engineering team. We will analyze your VMware inventory, map the storage and networking topologies to open infrastructure, and demonstrate a live migration in a sandbox environment.
How long does a VMware to OpenStack migration take?
For a mid-sized estate the honest range is three to nine months end to end, and the variable is almost never the disk conversion. Inventory and sizing take two to four weeks if your CMDB is trustworthy and considerably longer if it is not. The first workload wave usually lands within a month of the platform being stood up. What stretches the timeline is change windows, application owners' availability, and the parallel-running period, which is why we sequence by renewal pressure rather than by technical convenience.
Can we convert VMDK disks to OpenStack without downtime?
Not entirely, but the downtime can be small and scheduled. The conversion itself, qemu-img from VMDK to raw or QCOW2, runs against a snapshot while the source VM keeps serving. The cutover window is the final delta sync plus the boot on the target, which for most workloads is minutes rather than hours. Stateless and horizontally scaled workloads can move with no user-visible downtime at all by standing up the new instances and shifting traffic. Databases and single-instance legacy applications are the ones that need a real window.
What happens to VMware snapshots, templates and vSphere tags?
They do not carry across as objects, and planning for that early avoids a nasty week. Snapshots are point-in-time deltas in VMware's format and should be consolidated before conversion rather than migrated. Templates become Glance images, which is usually an improvement because they get versioned and shared across projects. Tags and custom attributes have no direct equivalent, so they are re-expressed as project structure, image metadata and flavor naming, and that mapping is worth agreeing before you start rather than after.
Do we need to rewrite our Terraform and automation?
The provider changes, the shape of your code mostly does not. Resource definitions move from the vSphere provider to the OpenStack provider, and the concepts line up closely enough that most modules survive a mechanical rewrite plus testing. What genuinely changes is anything that reached into vCenter directly through PowerCLI, since that has no equivalent and becomes API or Terraform work. Teams that already had their estate in code find this the easiest phase; teams that clicked through vCenter find it the hardest, because they are writing the automation for the first time.
How do we redeploy Tanzu workloads without a platform project?
Because the target clusters are CNCF-conformant with no fork, your Helm charts, operators and manifests apply unchanged. The work is not in the workloads, it is in what surrounded them: TKG-specific cluster definitions are replaced by managed clusters provisioned from the console, API or Terraform, and vSphere-backed storage classes are repointed at Cinder. In practice teams stand up a target cluster, redeploy a non-critical namespace to prove the path, then move namespace by namespace. You are redeploying workloads onto standard Kubernetes, not migrating cluster state.
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Preferences
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
