Whether you're leaving VMware after Broadcom's licensing changes, repatriating workloads from public cloud, or transitioning from CloudStack — there is a well-understood path to OpenStack. The key is knowing what moves cleanly and what needs rearchitecting.
Each source platform has different strengths and friction points when moving to OpenStack.
The most common migration path today. Broadcom's acquisition has triggered licensing cost increases of 2-10x, forcing organizations to evaluate alternatives. VM images convert cleanly; vSphere-specific features need replacement.
Cloud repatriation — bringing workloads back on-premises after the cost, sovereignty, or control limitations of public cloud become untenable. Standard VMs move easily; proprietary managed services require alternatives.
CloudStack to OpenStack is the smoothest migration path. Both are open-source IaaS platforms with similar architectures. The primary work is in API migration and networking reconfiguration, not workload conversion.
Broadcom's acquisition of VMware in late 2023 fundamentally changed the licensing model. Perpetual licenses were eliminated. Bundled subscriptions replaced a la carte pricing. Many organizations saw their VMware costs increase 3-10x overnight, with little negotiating leverage. The result has been the largest wave of VMware departures in the platform's history.
OpenStack is the natural destination. It provides the same core capabilities — compute virtualization, software-defined networking, block storage, identity management — without per-socket or per-core licensing fees. The Apache 2.0 license means no vendor can change the terms.
vCenter API calls, PowerCLI scripts, and vRealize workflows do not translate. Replace with OpenStack APIs, Terraform OpenStack provider, or Heat templates.
NSX distributed firewall rules need to be recreated as Neutron security groups or OVN ACLs. The concepts are equivalent but the syntax differs.
vSAN is replaced by Ceph. This is a full storage platform migration — data must be moved, not converted in place. Plan for parallel operation during transition.
VMware Tools must be replaced with virtio drivers for KVM. For Windows guests, install virtio-win drivers before migration or inject them during image conversion.
Timeline: A typical VMware-to-OpenStack migration for 200-500 VMs takes 3-6 months, including parallel operation. The OpenStack environment is built first (6-8 weeks), then workloads are migrated in waves while both platforms run simultaneously.
No equivalent in OpenStack: Managed services like RDS, DynamoDB, Lambda, SQS, Kinesis, and Bedrock have no direct OpenStack equivalent. These require self-managed replacements (PostgreSQL, Redis, RabbitMQ) or architectural changes. This is the primary friction point in cloud repatriation.
Cloud repatriation is accelerating. The drivers are consistent: costs that grew faster than expected, data sovereignty requirements that public cloud cannot satisfy, and the realization that vendor lock-in to proprietary managed services makes future migration progressively harder.
The good news: standard IaaS workloads — VMs, block storage, networking — map directly to OpenStack equivalents. If your application runs on a Linux VM with a mounted volume behind a load balancer, it will run on OpenStack with minimal changes.
Apache CloudStack and OpenStack are both open-source IaaS platforms with overlapping capabilities. Organizations typically migrate from CloudStack to OpenStack for broader ecosystem support, a larger contributor base, and deeper integration with tools like Terraform, Ansible, and Kubernetes (via Magnum or Cluster API).
This is the smoothest migration path. Both platforms use KVM as the default hypervisor, both use Linux-based networking, and both manage similar resource types. The primary work is in API translation and network reconfiguration, not workload conversion.
Advantage: Because both platforms use KVM, live VM images (qcow2) can often be imported directly into Glance without conversion. This eliminates the most time-consuming part of most migrations — disk image conversion and driver replacement.
Regardless of source platform, successful migrations follow the same phases.
Inventory all workloads. Classify each as migration-ready, needs-modification, or requires-rearchitecting. Map network topology, storage dependencies, and automation tooling. Define success criteria and rollback procedures.
Duration: 2-4 weeks
Deploy the OpenStack environment on target hardware. Configure networking, storage (Ceph), identity (Keystone with LDAP/AD integration), monitoring, and backup. Validate with test workloads before migrating production.
Duration: 4-8 weeks
Move workloads in ordered batches: stateless services first, then stateful applications, then databases and critical systems last. Maintain hybrid connectivity between source and target. Validate each wave before proceeding.
Duration: 4-12 weeks (depends on scale)
Run production workloads on OpenStack while maintaining rollback capability to the source platform. Monitor performance, validate SLAs, tune Ceph and Nova configurations. Confirm all automation and CI/CD pipelines work against OpenStack APIs.
Duration: 2-4 weeks
Once all workloads are validated on OpenStack and the team is confident in operations, decommission the source platform. Cancel public cloud accounts or repurpose VMware hardware. Document the new operational procedures and close the migration project.
Duration: 1-2 weeks
Every migration starts with an assessment. Talk to engineers who have migrated production workloads to OpenStack from VMware, AWS, Azure, and CloudStack.