Steigende VMware-Kosten & Vendor Lock-in: Warum wir auf OpenStack umgestellt haben

Die Frage war nicht, ob wir uns verändern – sondern wie schnell wir es schaffen.

Der Verkauf von VMware und die darauffolgende Neuausrichtung von Lizenz- und Preismodellen haben bei vielen Unternehmen eine Diskussion ausgelöst, die zuvor kaum geführt wurde. Was über Jahre als stabile, kalkulierbare technologische Grundlage galt, entwickelte sich innerhalb kurzer Zeit zu einem strategischen Unsicherheitsfaktor.

Dabei ging es nicht nur um steigende Kosten. Entscheidend war die Art der Veränderung. Preislogiken wurden grundlegend angepasst, Modelle vereinfacht – jedoch nicht im Sinne der Betreiber oder Service-Provider, sondern entlang einer neuen, einseitigen Herstellersicht. Für Unternehmen, die Virtualisierung nicht als isolierte IT-Komponente, sondern als Fundament ihres Geschäfts betreiben, ist das kein Detail, sondern eine strukturelle Verschiebung.

Für uns bei UPONU war schnell klar: Die neue Kostenstruktur und fehlende Verlässlichkeit hätte unser Geschäftsmodell in der bisherigen Form massiv gefährdet. Und damit war nicht ein einzelner Service betroffen, sondern ein großer Teil unserer Infrastruktur – inklusive vieler Kundenplattformen, Dienste und Projekte, die darauf aufbauen.

Es ging nicht um Optimierung, sondern um Zukunftsfähigkeit. Und damit auch nicht um die Frage, ob wir reagieren, sondern wie schnell wir es schaffen würden.

Wenn Abhängigkeit plötzlich real wird

Vendor Lock-in ist kein theoretisches Risiko

Vendor Lock-in wird oft als ein abstraktes Risiko diskutiert: Etwas, das man kennt, einpreist und bewusst in Kauf nimmt. Solange Systeme stabil laufen, Preise moderat steigen und Roadmaps halbwegs vorhersehbar sind, wirkt diese Abhängigkeit kontrollierbar.

Doch genau hier liegt der Trugschluss.

Abhängigkeit zeigt sich aber nicht in stabilen Phasen. Sie wird erst dann real, wenn sich Rahmenbedingungen einseitig ändern. Die aktuelle weltpolitische Lage zeigt deutlich, wie schnell sicher geglaubte Strukturen wegbrechen können. Insbesondere dann, wenn Entscheidungen außerhalb des eigenen Einflussbereichs getroffen werden und unmittelbare wirtschaftliche und operative Konsequenzen haben.

In unserem Fall war die Preisentwicklung der sichtbare Auslöser. Das eigentliche Problem aber lag tiefer. Wir waren mit der zentralen technologischen Grundlage unseres Unternehmens hochgradig von einzelnen Anbietern abhängig. Planungssicherheit, Wirtschaftlichkeit und strategische Freiheit waren nicht in unserer Hand.

Dabei ist Vendor Lock-in kein Fehler. Er ist oft das Ergebnis bewusster Entscheidungen: für Komfort, für Geschwindigkeit, für vermeintliche Sicherheit. Kritisch wird er erst dann, wenn diese Entscheidung nicht regelmäßig hinterfragt wird – und sich schleichend von einem kalkulierten Risiko zu einer strukturellen Abhängigkeit entwickelt.

Preissteigerungen sind selten das eigentliche Problem

Warum es um Planbarkeit geht, nicht um einzelne Zahlen

Steigende Preise allein sind kein ausreichender Grund für einen technologischen Umbruch. Kosten verändern sich, Märkte bewegen sich, Anbieter passen ihre Modelle an. Entscheidend ist nicht die absolute Höhe, sondern die Frage, ob ein Geschäftsmodell unter den neuen Bedingungen noch planbar betrieben werden kann.

Für Betreiber von Infrastrukturen – insbesondere im B2B-Umfeld – ist Planbarkeit essenziell. Oberster Anspruch ist dabei nicht, die niedrigsten Preise zu haben, sondern die beste Planbarkeit zu bieten. Preise müssen in Relation zum Nutzen stehen und langfristig in Kunden-Geschäftsmodelle integrierbar bleiben.

In unserem Fall war genau das nicht mehr gegeben. Die neue Preislogik führte zu einer Situation, in der zukünftige Kostenentwicklungen kaum noch verlässlich abschätzbar waren. Das machte strategische Planung schwierig und unternehmerische Entscheidungen riskant.

Der Punkt war erreicht, an dem „Aushalten“ keine Option mehr war. Abwarten hätte bedeutet, eine Abhängigkeit zu akzeptieren, deren Konsequenzen wir nicht mehr kontrollieren konnten.

Eine Entscheidung unter massivem Zeitdruck

Warum wir keine Übergangsphase hatten

Die Entscheidung zur Umstellung betraf nicht nur einzelne Services oder neue Projekte, sondern unseren gesamten Rechenzentrumsbetrieb – das Fundament der internen Systeme und von Kundensystemen. Eine parallele Testumgebung über Jahre hinweg aufzubauen oder schrittweise zu migrieren, war zeitlich unrealistisch, da durch den bisherigen Anbieter nur ein Fenster von 12 Monaten bis zur Anpassung der Konditionen eingeräumt wurde.

Der laufende Betrieb musste stabil bleiben. Kunden erwarteten Verfügbarkeit, Sicherheit und Verlässlichkeit – unabhängig von internen Umstrukturierungen. Gleichzeitig war klar: Jede Verzögerung erhöhte das Risiko, in eine noch stärkere Abhängigkeit zu geraten.

Wir mussten unter Unsicherheit entscheiden. Nicht alle Details waren zu Beginn vollständig geklärt, nicht jede Abhängigkeit sofort sichtbar. Dennoch war Handeln erforderlich. In solchen Situationen zeigt sich, ob ein Unternehmen in der Lage ist, Verantwortung zu übernehmen – auch ohne perfekte Informationslage.

Was ein kompletter Infrastrukturwechsel wirklich bedeutet

Es ging nicht um eine Plattform – sondern um das Fundament

Ein Wechsel dieser Größenordnung ist kein klassisches Migrationsprojekt. Er ist ein Eingriff in das Fundament des eigenen Unternehmens.

Wir haben unser Rechenzentrum im Kern neu aufgebaut. Technische Architekturen, Betriebsprozesse und gewachsene Strukturen mussten hinterfragt werden. Abhängigkeiten, die zuvor kaum sichtbar waren, traten plötzlich deutlich zutage.

Viele Annahmen, die über Jahre als gesetzt galten, hielten einer genaueren Prüfung nicht stand. Das war unbequem, aber notwendig.

Neubau statt Umbau

Schnell wurde klar: Ein einfaches „Umschalten“ ist eine Illusion. Stattdessen war ein strukturierter Neubau erforderlich – technisch, organisatorisch und prozessual. Das bedeutete mehr Aufwand, aber auch die Chance, Altlasten nicht weiter mitzuschleppen. Auch musste die finanzielle Doppelbelastung mit betrachtet werden. Sowohl die gestiegenen Kosten der bestehenden Lösung als auch die massiven Investitionen in einen neuen Aufbau mussten berücksichtigt werden.

Risiken, Rückschläge und Korrekturen

Nicht alles lief reibungslos. Entscheidungen, die theoretisch sinnvoll erschienen, erwiesen sich in der Praxis als unzureichend. Einzelne Ansätze mussten verworfen, andere nachgeschärft werden. Diese Rückschläge waren zeitaufwendig und fordernd – aber sie haben uns gezwungen, tiefer zu analysieren und sauberer zu planen.

Migrationen sind nie nur ein internes Thema

Abhängigkeiten von Drittdienstleistern als kritischer Faktor

Ein Aspekt, der bei vielen Migrationen unterschätzt wird, sind Abhängigkeiten von externen Dienstleistern und Partnern. Kaum eine Systemlandschaft ist vollständig autark. Schnittstellen, angebundene Services, spezialisierte Anbieter – all das beeinflusst Zeitplanung und Komplexität erheblich.

In Migrationsprojekten zeigt sich schnell: Zeitpläne lassen sich intern definieren, aber nicht vollständig kontrollieren. Externe Abhängigkeiten haben eigene Prioritäten, eigene Prozesse und eigene Reaktionszeiten. Das ist kein Vorwurf, sondern Realität.

Gerade bei größeren Umstellungen wird deutlich, dass technische Machbarkeit allein nicht ausreicht. Erfolgreiche Migrationen benötigen realistische Zeitplanung, klare Kommunikation und die Bereitschaft, Puffer einzuplanen. Wer diese Abhängigkeiten ignoriert, riskiert Verzögerungen und unnötigen Druck – intern wie extern.

Warum wir uns bewusst für Open Source entschieden haben

Kontrolle statt Abhängigkeit

Unsere Entscheidung für OpenStack war keine Kostenentscheidung. Sie war eine strategische.

Open Source bedeutet für uns vor allem eines: Kontrolle. Kontrolle über die eigene Infrastruktur, über Weiterentwicklung, über Abhängigkeiten. Keine einseitigen Lizenzänderungen, keine Blackbox, keine fremdbestimmten Roadmaps.

Diese Kontrolle bringt Verantwortung mit sich. Betrieb, Wartung und Weiterentwicklung lassen sich nicht delegieren. Aber genau darin liegt der Gewinn: Entscheidungen werden wieder im eigenen Haus getroffen – auf Basis der eigenen Anforderungen und Prioritäten.

Gemeinschaft statt Blackbox

Ein weiterer zentraler Aspekt ist die Gemeinschaft hinter Open Source. Wissen ist zugänglich, Probleme sind transparent, Weiterentwicklung ist nachvollziehbar. Statt passiver Nutzung beteiligen wir uns aktiv, bringen Erfahrungen ein und profitieren vom Austausch mit anderen.

Open Source ist kein Gegenmodell zu Enterprise. Es ist ein anderes Verantwortungsmodell.

Wir haben uns gezielt dazu entschieden, die OpenStack-Betriebsplattform des Sovereign Cloud Stack zu nutzen.

Was wir aus der Migration gelernt haben

Und warum wir heute anders arbeiten und beraten

Die Umstellung hat unsere Arbeitsweise nachhaltig verändert.

Planung ist heute deutlich detaillierter und langfristiger. Gerade bei komplexen Systemlandschaften reicht es nicht, technische Machbarkeit zu prüfen. Abhängigkeiten, Betriebsmodelle und zukünftige Entwicklung müssen von Anfang an mitgedacht werden.

Wir bewerten Systemlandschaften heute tiefer, bevor wir über Migrationsstrategien sprechen. Nicht jede Umgebung benötigt sofort einen vollständigen Wechsel. Aber jede sollte verstanden sein.

Und wir missionieren nicht mehr. Wir erzählen unsere Geschichte. Wer darin keinen Schmerz erkennt, hat das Thema für sich bereits gelöst – oder spürt die Auswirkungen noch nicht.

Was das für Unternehmen bedeutet, die heute noch abhängig sind

Nicht jeder muss oder kann sofort migrieren – aber jeder braucht einen Plan

Dieser Artikel ist keine Aufforderung zum sofortigen Plattformwechsel. Er ist eine Einladung, sich aktiv mit Datensouveränität und Abhängigkeiten auseinanderzusetzen.

Unternehmen sollten wissen:

• Wie abhängig sie wirklich sind
• Welche Faktoren sie im Ernstfall handlungsfähig machen oder blockieren
• Welche Alternativen realistisch sind
• Wie lange ein Ausstieg dauern würde – und wovon diese Dauer abhängt

Diese Fragen zu stellen, bevor äußerer Druck entsteht, ist kein Aktionismus. Es ist unternehmerische Verantwortung.

Unser Fazit

Wir haben die Umstellung unserer gesamten Infrastruktur erfolgreich gemeistert. Nicht, weil sie einfach war – sondern weil sie notwendig war. Heute betreiben wir unsere OpenStack-Plattform vollständig autark, verfügen über tiefgreifende Migrationserfahrung und sind in der Lage, Kunden aus unterschiedlichsten Umgebungen sicher zu begleiten.

Wir bieten keine Blaupause und kein Patentrezept. Aber wir zeigen, dass ein kontrollierter Ausstieg möglich ist – wenn man ihn bewusst, realistisch und mit Weitblick angeht.