Seit der Broadcom-Übernahme von VMware im Mai 2023 hat sich die Virtualisierungslandschaft fundamental verändert: Preiserhöhungen von bis zu 1.200% im Education-Sektor, über 2.800 entlassene Mitarbeiter, und für viele kleinere MSPs Kostensteigerungen um das Zehnfache. Die Umstellung auf subscription-only Lizenzierung und verschärfte Partner-Anforderungen (mindestens 3.500 Cores) zwingen Unternehmen zur Neubewertung ihrer Infrastruktur-Strategie.
Mit OpenStack steht eine ausgereifte, standardisierte Open-Source-Alternative zur Verfügung, die API-kompatibel ist und kein Vendor-Lock-in verursacht. Als einer der ersten drei SCS-zertifizierten Cloud-Provider in Deutschland betreiben wir seit Jahren produktive OpenStack-Umgebungen und begleiten Kunden bei der Migration aus proprietären Virtualisierungsstacks.
Aktuell migrieren wir selbst eine VMware-Umgebung an unserem Standort in Nürnberg-Fürth auf unsere OpenStack-basierte ScaleUp Open Cloud. Erste Migrationen wurden bereits erfolgreich getestet, der Umzug von Kunden-Workloads wird demnächst (alternativ: ab Q3 2026) beginnen. In diesem Artikel teilen wir unsere praktischen Erfahrungen, technischen Learnings und den Weg zu einer kosteneffizienten, zukunftssicheren Cloud-Infrastruktur.
Warum OpenStack?
Kosteneffizienz und Unabhängigkeit
OpenStack eliminiert proprietäre Lizenzmodelle. Für Unternehmen mit wachsender Infrastruktur bedeutet dies planbare Kosten und langfristige Unabhängigkeit von einem einzelnen Anbieter. Der Einsatz von Ceph als Storage-Backend ergänzt diesen Ansatz ideal: Es ist software-defined, hochverfügbar und vollständig horizontal skalierbar.
Standardisierung statt proprietäre Extensions
Die Sovereign-Cloud-Stack-(SCS)-Zertifizierung, die auf Frameworks wie OSISM basiert, definiert einen gemeinsamen Standard für OpenStack-Deployments. Dieser umfasst reproduzierbare Architekturen, standardisierte APIs ohne Vendor-Extensions sowie garantierte Interoperabilität zwischen zertifizierten Providern. So entsteht kein gebasteltes Inselsystem, sondern ein offenes Ökosystem mit konsistenten Schnittstellen.
Moderne Cloud-Architektur
OpenStack bietet native APIs, Multi-Tenancy, Self-Service-Portale sowie ein containerfreundliches Ökosystem. Anwendungen, die aktuell noch auf klassische VMs setzen, können schrittweise in Container- oder Kubernetes-Stacks überführt werden, ohne dass ein Wechsel der Plattform nötig ist.
Flexibilität und Automatisierung
Die modulare OpenStack-Architektur ermöglicht den Betrieb in individuellen Ausprägungen – von kompakten Edge-Deployments bis hin zu groß skalierten Rechenzentrums-Clouds. Ein API-First-Design, Infrastructure-as-Code und offene Schnittstellen ermöglichen Automatisierung auf allen Ebenen.
Die Migration an unserem Standort Nürnberg-Fürth: Stand und Ziele
An unserem Standort Nürnberg-Fürth betrieb die ODN eine historisch gewachsene VMware-Umgebung, die eine Vielzahl von Kunden-Workloads hostet. Diese Workloads werden nun schrittweise auf unsere OpenStack-basierte ScaleUp Open Cloud umgezogen. Erste virtuelle Maschinen laufen bereits stabil in der neuen Umgebung. Der vollständige Umzug ist bis Ende des zweiten Quartals 2026 geplant.
Als Zielbild sehen wir erhebliche Einsparungen bei den Lizenz- und Betriebskosten, eine geringere technische Komplexität sowie eine stärkere Bündelung von Wissen innerhalb der Teams. Hinzu kommen mehr Flexibilität und Self-Service-Funktionen für unsere Kunden an diesem Standort sowie eine nachhaltige Modernisierung des gesamten Infrastruktur-Stacks.
Die Migration erfolgt mit abgestimmten Wartungsfenstern und optimierten Pfaden für die jeweiligen Workloads.
Technische Herausforderungen und mögliche Fallstricke beim Umzug von VMware zu OpenStack
Der Wechsel von VMware zu OpenStack ist ein strategischer Schritt, der sorgfältige Planung erfordert. Die Vorteile sind signifikant, doch potenzielle Herausforderungen müssen aktiv gemanagt werden, um einen reibungslosen Übergang zu gewährleisten.
- Organisations- und Skill-Shift. OpenStack ist mehr als ein Hypervisor-Manager, es ist eine Cloud-Infrastructure-Management-Plattform, die Compute, Storage und Networking als einheitliche Services abstrahiert. Teams müssen von einem VM-zentrierten Denken (vSphere) zu einem Cloud-API-zentrierten Denken (Nova, Neutron) übergehen. Das erfordert eine Umschulung, bei der der Fokus von grafischen Management-Tools auf Infrastructure-as-Code, CLI-Nutzung und die Automatisierung über die OpenStack-APIs (Keystone, Nova, Neutron) verlagert wird.
- Konvertierung und Workload-Anpassung. Die direkte Migration von VMware-VM-Images erfordert eine Konvertierung der proprietären Disk-Formate, etwa VMDK, in Open-Source-Formate wie RAW. Der zeitkritischere Aufwand liegt jedoch in der Anpassung der Workloads selbst. Netzwerkkonzepte in OpenStack (Neutron) unterscheiden sich grundlegend von denen in VMware: Komplexe Layer-2- oder Layer-3-Konfigurationen, die in vCenter oder NSX implementiert wurden, müssen auf die Abstraktionen von Neutron, also Netzwerke, Router und Security Groups, abgebildet werden. Das erfordert detaillierte Planung und oft eine Re-Architektur der Netzwerkkonfigurationen. Hinzu kommt die Betriebssystem-Vorbereitung: Workloads benötigen die Installation und Konfiguration von Cloud-Init zur automatischen Konfiguration von Netzwerk, SSH-Keys und Hostname beim Instanz-Start in OpenStack.
- Tooling und Ökosystem-Integration. Während VMware als proprietäre Lösung ein monolithisches Ökosystem bietet, ist OpenStack modular aufgebaut. Bisher verwendete VMware-Tools für Backup, Disaster Recovery und Monitoring müssen auf OpenStack-kompatible Open-Source-Lösungen umgestellt werden, etwa Ceph-Backup-Mechanismen oder Prometheus und Grafana für das Monitoring. Die API-Integration ist dabei durchgehend sicherzustellen.
- Migration mit minimaler Downtime. Eine Hypervisor-übergreifende Live-Migration ohne Downtime von VMware zu OpenStack ist technisch nicht praktikabel. Stattdessen erfordert eine reibungslose Migration mit minimaler Downtime sorgfältige Planung: Disk-Images werden von proprietären VMWare-Formaten konvertiert und vorab in Glance beziehungsweise Ceph übertragen, große Datenmengen werden vor dem eigentlichen Wartungsfenster synchronisiert, und Cloud-Init, Netzwerkkonfiguration sowie SSH-Keys werden vorbereitet. Die Workloads selbst migrieren wir gestaffelt und priorisiert, unkritische Systeme zuerst, Produktiv-Workloads in abgestimmten Wartungsfenstern, während die VMware-Umgebung parallel vorgehalten wird, bis die OpenStack-Migration verifiziert ist.
Der technische Aufwand liegt also weniger in der Image-Konvertierung als in der Anpassung der Workloads an cloudnative Prinzipien. Dazu gehören die Cloud-Init-Integration, das Neutron-Netzwerk-Mapping und die Transformation statischer VM-Konfigurationen („Pets“) in automatisiert bereitgestellte, zustandslose Instanzen („Cattle“).
Komplexität vs. Realität: Die Evolution des OpenStack-Managements
Das Narrativ von der übermäßigen Komplexität von OpenStack stammt noch aus den frühen Deployment-Phasen vor 2016, als das Lifecycle-Management manuell oder mit unreifen Werkzeugen erfolgte. Die OpenStack-Community hat darauf mit einer massiven Standardisierung der Deployment- und Upgrade-Prozesse reagiert.
Früher war der Day-1-Deployment-Prozess der größte Schmerzpunkt. Heute gibt es Tools wie kolla-ansible, OSISM oder Yaook. Containerisierte Deployment-Tools vereinfachen die Installation und Wartung: Statt komplexer Systemkonfigurationen werden die einzelnen OpenStack-Services in Containern betrieben. Das erleichtert die Behebung von Abhängigkeitsproblemen, verbessert die Reproduzierbarkeit von Umgebungen und ermöglicht automatisierte Upgrades, wodurch die Betriebszeit maximiert und der manuelle Wartungsaufwand spürbar reduziert wird.
Auch die Betriebsmodelle sind gereift. Der Betrieb von OpenStack ist heute durch den Einsatz von Ansible, Terraform und Kubernetes geprägt. Die Verwaltung wird transparent und skalierbar, weil alle Konfigurationen im Code dokumentiert sind.
Die Vielzahl der OpenStack-Komponenten – es gibt über 50 Projekte – erscheint auf den ersten Blick verwirrend. Moderne Distributionen und Betreiber – wie wir selbst – konzentrieren sich jedoch auf eine stabile und schlanke Kernauswahl. Dazu gehören Nova, Neutron, Cinder bzw. Ceph, Keystone, Glance und Horizon. Dadurch wird die Komplexität reduziert und das Wissen im Team auf die kritischen Services fokussiert.
Conclusion
Mit Frameworks wie OSISM und dem Fokus auf moderne, standardisierte Deployment-Ansätze ist OpenStack heute eine betriebssichere und hochgradig automatisierbare Plattform, deren Komplexität sich primär auf die initiale Architektur und nicht auf den laufenden Betrieb konzentriert. Die Notwendigkeit, OpenStack als Infrastructure-as-Code zu betreiben, hat zur Reifung von Tools wie Terraform und Ansible beigetragen. Diese Automatisierungsansätze sind heute Best Practice und machen den OpenStack-Betrieb nicht komplizierter, sondern transparenter, reproduzierbarer und skalierbarer.
Der Schritt von VMware zu OpenStack ist nicht nur eine Reaktion auf steigende Lizenzkosten, sondern ein strategischer Modernisierungsschritt in Richtung offener Standards, automatisierter Betriebsmodelle und agiler Cloud-Architekturen, die mit den Anforderungen der nächsten Jahre wachsen können. Mit strukturierter Planung, realistischen Timelines und dem Fokus auf stabile Kern-Services ist der Umstieg auf OpenStack technisch machbar und wirtschaftlich sinnvoll.
Als SCS-zertifizierter Provider betreiben wir produktive OpenStack-Umgebungen an unseren Standorten in Berlin und Nürnberg und begleiten diese Transformation von Architektur und Design über das Deployment bis zum laufenden Betrieb.
Sie evaluieren gerade, ob OpenStack für Ihre Umgebung eine sinnvolle VMWare Alternative ist? Get in touch with us für eine technische Erstanalyse Ihrer aktuellen VMware-Umgebung und einen konkreten Migrationsfahrplan.
Quellen zu den Broadcom/VMware-Entwicklungen:
- CISPE-Beschwerde und Lizenzkostensteigerungen bei Cloud-Service-Providern: cloudcomputung-insider.de (März 2026)
- VMware-Preisanalyse: Vor und nach der Broadcom-Übernahme: cristie.de (Dezember 2025)
- Responding to Broadcom/VMware Licensing Changes: intelisys.com (Oktober 2025)
