Since Broadcom’s acquisition of VMware in May 2023, the virtualization landscape has changed fundamentally: Price increases of up to 1,200% in the education sector, over 2,800 laid-off employees, and cost increases tenfold for many smaller MSPs. The shift to subscription-only licensing and stricter partner requirements (at least 3,500 cores) are forcing companies to reevaluate their infrastructure strategy.
With OpenStack A mature, standardized open-source alternative is available that is API-compatible and does not result in vendor lock-in. As one of the first three SCS-certified cloud providers in Germany, we have been operating production OpenStack environments for years and support customers in migrating from proprietary virtualization stacks.
We are currently migrating a VMware environment at our Nuremberg-Fürth location to our OpenStack-based ScaleUp Open Cloud. Initial migrations have already been successfully tested, and the migration of customer workloads will begin shortly (alternatively: starting in Q3 2026). In this article, we share our practical experiences, technical insights, and the path to a cost-effective, future-proof cloud infrastructure.
Why OpenStack?
Cost-Effectiveness and Independence
OpenStack eliminates proprietary licensing models. For companies with growing infrastructure, this means predictable costs and long-term independence from any single vendor. Using Ceph as a storage backend perfectly complements this approach: It is software-defined, highly available, and fully horizontally scalable.
Standardization Instead of Proprietary Extensions
The Sovereign Cloud Stack (SCS) certification, which is based on frameworks such as OSISM, defines a common standard for OpenStack deployments. This includes reproducible architectures, standardized APIs without vendor extensions, and guaranteed interoperability among certified providers. This results not in a cobbled-together siloed system, but in an open ecosystem with consistent interfaces.
Modern Cloud Architecture
OpenStack offers native APIs, multi-tenancy, self-service portals, and a container-friendly ecosystem. Applications that currently still rely on traditional VMs can be gradually migrated to container or Kubernetes stacks without requiring a platform change.
Flexibility and Automation
The modular OpenStack architecture enables operation in a variety of configurations—from compact edge deployments to large-scale data center clouds. An API-first design, infrastructure-as-code, and open interfaces enable automation at all levels.
Migration at Our Nuremberg-Fürth Location: Current Status and Goals
At our Nuremberg-Fürth location, ODN operated a VMware environment that had evolved over time and hosts a wide range of customer workloads. These workloads are now being gradually migrated to our OpenStack-based ScaleUp Open Cloud. The first virtual machines are already running stably in the new environment. The complete migration is scheduled to be completed by the end of the second quarter of 2026.
Our vision is to achieve significant savings in licensing and operating costs, reduce technical complexity, and foster greater knowledge sharing within the teams. In addition, we aim to provide our customers at this location with greater flexibility and self-service capabilities, as well as to modernize the entire infrastructure stack in a sustainable manner.
The migration is carried out using coordinated maintenance windows and optimized paths for the respective workloads.
Technical Challenges and Potential Pitfalls When Migrating from VMware to OpenStack
The transition from VMware to OpenStack is a strategic move that requires careful planning. The benefits are significant, but potential challenges must be actively managed to ensure a smooth transition.
- Organizational and Skill Shift. OpenStack is more than just a hypervisor manager; it is a cloud infrastructure management platform that abstracts compute, storage, and networking as unified services. Teams must transition from a VM-centric mindset (vSphere) to a cloud API-centric mindset (Nova, Neutron). This requires retraining, shifting the focus from graphical management tools to Infrastructure-as-Code, CLI usage, and automation via the OpenStack APIs (Keystone, Nova, Neutron).
- Conversion and workload adjustment. Direct migration of VMware VM images requires converting proprietary disk formats, such as VMDK, to open-source formats like RAW. However, the more time-sensitive task lies in adapting the workloads themselves. Network concepts in OpenStack (Neutron) differ fundamentally from those in VMware: Complex Layer 2 or Layer 3 configurations implemented in vCenter or NSX must be mapped to Neutron’s abstractions—namely, networks, routers, and security groups. This requires detailed planning and often a redesign of the network configurations. Added to this is operating system preparation: Workloads require the installation and configuration of Cloud-Init to automatically configure the network, SSH keys, and hostname when the instance starts in OpenStack.
- Tooling and Ecosystem Integration. While VMware, as a proprietary solution, offers a monolithic ecosystem, OpenStack has a modular architecture. VMware tools previously used for backup, disaster recovery, and monitoring must be migrated to OpenStack-compatible open-source solutions, such as Ceph backup mechanisms or Prometheus and Grafana for monitoring. API integration must be ensured throughout the process.
- Migration with minimal downtime. A cross-hypervisor live migration from VMware to OpenStack without downtime is not technically feasible. Instead, a smooth migration with minimal downtime requires careful planning: Disk images are converted from proprietary VMware formats and transferred in advance to Glance or Ceph; large amounts of data are synchronized before the actual maintenance window; and Cloud-Init, network configuration, and SSH keys are prepared. We migrate the workloads themselves in stages and according to priority—non-critical systems first, production workloads during coordinated maintenance windows—while maintaining the VMware environment in parallel until the OpenStack migration has been verified.
The technical effort, therefore, lies less in image conversion than in adapting workloads to cloud-native principles. This includes Cloud Init integration, Neutron network mapping, and the transformation of static VM configurations („Pets“) into automatically provisioned, stateless instances („Cattle“).
Complexity vs. Reality: The Evolution of OpenStack Management
The notion that OpenStack is overly complex dates back to the early deployment phases before 2016, when lifecycle management was performed manually or using immature tools. The OpenStack community has responded by significantly standardizing deployment and upgrade processes.
In the past, the Day 1 deployment process was the biggest pain point. Today, there are tools such as kolla-ansible, OSISM, and Yaook. Containerized deployment tools simplify installation and maintenance: Instead of complex system configurations, the individual OpenStack services are run in containers. This makes it easier to resolve dependency issues, improves the reproducibility of environments, and enables automated upgrades, thereby maximizing uptime and significantly reducing the manual maintenance effort.
Operational models have also matured. Today, OpenStack operations are characterized by the use of Ansible, Terraform, and Kubernetes. Management becomes transparent and scalable because all configurations are documented in the code.
At first glance, the sheer number of OpenStack components—there are over 50 projects—can seem confusing. However, modern distributions and operators—such as ourselves—focus on a stable and streamlined core selection. This includes Nova, Neutron, Cinder or Ceph, Keystone, Glance, and Horizon. This reduces complexity and allows the team to focus its expertise on the critical services.
Conclusion
With frameworks such as OSISM and a focus on modern, standardized deployment approaches, OpenStack is today a reliable and highly automatable platform, whose complexity is primarily related to the initial architecture rather than day-to-day operations. The need to operate OpenStack as infrastructure-as-code has contributed to the maturation of tools such as Terraform and Ansible. These automation approaches are now considered best practices and do not make OpenStack operations more complicated, but rather more transparent, reproducible, and scalable.
The move from VMware to OpenStack is not just a response to rising licensing costs, but a strategic modernization step toward open standards, automated operating models, and agile cloud architectures that can scale to meet the demands of the coming years. With structured planning, realistic timelines, and a focus on stable core services, the transition to OpenStack is technically feasible and economically sound.
As an SCS-certified provider, we operate production OpenStack environments at our locations in Berlin and Nuremberg and support this transformation—from architecture and design through deployment to ongoing operations.
Are you currently evaluating whether OpenStack is a viable alternative to VMware for your environment? Get in touch with us for an initial technical analysis of your current VMware environment and a detailed migration roadmap.
Sources on the Broadcom/VMware developments:
- CISPE Complaint and License Fee Increases Among Cloud Service Providers: cloudcomputing-insider.de (March 2026)
- VMware Price Analysis: Before and After the Broadcom Acquisition: cristie.de (December 2025)
- Responding to Broadcom/VMware Licensing Changes: intelisys.com (October 2025)
