Lock-in-Effekt: woran Sie ihn erkennen und wie Sie ihn auflösen

Was der Lock-in-Effekt ist und in welchen Formen er auftritt

Der Lock-in-Effekt beschreibt eine Abhängigkeit, die sich nicht mehr auflösen lässt, ohne dass der Wechsel teurer wird als das Bleiben. Im englischen Sprachgebrauch heißt das Vendor Lock-in. Entscheidend ist nicht, ob ein Anbieter marktbeherrschend ist, sondern ob er seine Konditionen einseitig ändern kann, während die andere Seite nicht ausweichen kann.

In der IT tritt der Effekt in vier Formen auf, die selten allein kommen:

• Technischer Lock-in. Proprietäre Schnittstellen, herstellereigene Formate und Funktionen ohne Entsprechung. Ein Anbieterwechsel in der Virtualisierung kommt de facto einer Neuarchitektur gleich.
• Vertraglicher Lock-in. Laufzeiten, Bündelzwang und Mindestabnahmen. Sie zahlen für einen Funktionsumfang, den Sie nicht brauchen, und die Verhandlung wird alle drei Jahre neu geführt.
• Daten-Lock-in. Daten liegen in einem Format oder hinter einer Schnittstelle, die nur dieser Anbieter bedient. Bei Hyperscalern kommt der Abfluss der Daten als Kostenposten dazu, der erst beim Ausstieg sichtbar wird.
• Wissens-Lock-in. Die Betriebsprozesse funktionieren nur mit dem Tooling eines bestimmten Herstellers. Die Lizenz zu wechseln ist billig, die Routinen zu ändern ist die eigentliche Investition.

Die vierte Form ist die unterschätzte. Sie erklärt, warum Organisationen bei einem Anbieter bleiben, dessen Preis sie längst für unangemessen halten: Nicht die Software hält sie fest, sondern die Art, wie sie damit arbeiten.

Woran Sie einen Lock-in erkennen, bevor der Vertrag ausläuft

Ein Lock-in meldet sich nicht von selbst. Er steht in keinem Monitoring und in den meisten Organisationen auch in keinem Risikoregister: keine Bewertung, kein Eigentümer, kein Termin. Sichtbar wird er erst, wenn die Verlängerung ansteht und die Frage nach der Alternative zum ersten Mal ernsthaft gestellt wird. Dann ist die Antwort Teil des Problems.

Es gibt aber Warnzeichen, die früher auftreten. Die Kosten der kommenden Vertragsperiode lassen sich nicht beziffern, weil die Gegenseite den Rahmen setzt. Für die drei kritischsten Komponenten kann niemand sagen, was ein Wechsel an Zeit und Geld kosten würde. Betriebsprozesse sind an das Tooling eines Herstellers gebunden, und die Konfiguration liegt als gewachsener Zustand auf laufenden Systemen statt als Code im Repository. Aus der Dokumentation heraus ließe sich die Plattform nicht neu aufbauen.

Wer mehr als eine dieser Fragen nicht sicher beantworten kann, hat kein Technikproblem, sondern eine offene Position im Risikoregister.

Broadcom und VMware: das Lehrstück, an dem sich alles zeigt

Kein Fall der letzten Jahre erklärt den Lock-in-Effekt besser. VMware war zwanzig Jahre lang eine stabile Position: eine Lizenz, ein Preis, eine Planung. Mit der Übernahme durch Broadcom im November 2023 hat sich das verschoben. Unbefristete Lizenzen gibt es nicht mehr, neue Verträge sind im Kern dreijährige Abonnements.

Die Folgen sind dokumentiert, nicht behauptet. Der europäische Cloud-Verband CISPE hat bei Vertragsverlängerungen Preissteigerungen von 800 bis 1.500 Prozent erfasst und im März 2026 Wettbewerbsbeschwerde bei der EU-Kommission eingereicht. Der IT-Anwenderverband VOICE hat wegen derselben Lizenzpolitik Beschwerde wegen Marktmachtmissbrauchs eingelegt. Gartner erwartet, dass bis 2028 rund 70 Prozent der VMware-Enterprise-Kunden mindestens die Hälfte ihrer Workloads verlagern.

Bemerkenswert ist nicht die Preiserhöhung. Bemerkenswert ist, dass sie möglich war. Eine Komponente im Zentrum des Rechenzentrums war über Jahre so selbstverständlich geworden, dass ihre Ersetzbarkeit niemand mehr geprüft hatte. Genau das ist der Mechanismus: Ein Anbieter gewinnt Marktmacht oder wird übernommen, und das Risiko materialisiert sich sprunghaft.

Die zweite Lehre betrifft das Abwarten. Die laufenden Verfahren bei der EU-Kommission bringen kurzfristig keine Entlastung. Wer auf eine regulatorische Lösung wartet, gibt die Kontrolle über den eigenen Zeitplan ab und verhandelt am Ende ohne Alternative in der Hand. Wer eine VMware-Alternative vorbereitet hat, verhandelt anders, selbst wenn er am Ende bleibt.

Kostenloses Whitepaper · 7 Seiten

Open Source für den Betrieb

Von Andreas Hankel, CTO onehundred. Download gegen E-Mail-Adresse, ohne Vertriebsanruf.

Whitepaper laden

Proxmox und KVM: die offene Alternative in der Virtualisierung

Wer eine Alternative zu VMware sucht, landet in der klassischen Virtualisierung bei KVM und Proxmox VE. KVM ist Teil des Linux-Kernels und damit keine Beigabe eines Herstellers, sondern Bestandteil des Betriebssystems. Proxmox VE ist die Management-Ebene darüber.

Was die Plattform mitbringt

Proxmox VE liefert Cluster-Verbund, Hochverfügbarkeit, Live-Migration laufender Maschinen, rollenbasierte Rechte und eine integrierte Backup-Kette. Als Speicher kommen Ceph oder ZFS in Frage, für die Netzsegmentierung gibt es Proxmox SDN. Für die Sicherung existiert mit dem Proxmox Backup Server eine eigene Komponente mit Deduplizierung und inkrementellen Sicherungen. Ein Import-Assistent übernimmt virtuelle Maschinen aus bestehenden ESXi-Umgebungen.

Wo die Übersetzung nötig wird

Eine Mikrosegmentierung aus NSX lässt sich nicht eins zu eins übernehmen, sie wird konzeptionell übertragen. Ältere Gastsysteme brauchen passende Treiber, und Spezialfälle wie GPU-Durchreichung oder Hardware-Dongles gehören in die Bestandsaufnahme, nicht in die erste Migrationswelle. Das ist der Kern der Sache: kein Lift-and-Shift, sondern Übersetzung.

Das Lizenzmodell

Proxmox VE ist vollständig quelloffen. Die Software ist nicht an eine Mindestabnahme von Kernen und nicht an ein Bündel gekoppelt; die Subscription steuert den Zugang zum Enterprise-Repository und die Support-Stufe. Die Frage nach Proxmox-Lizenz und Proxmox-Kosten hat damit eine andere Qualität als bei einem proprietären Hypervisor: Sie kaufen Support, nicht das Recht, die Software zu betreiben.

Open Source im Betrieb: wo Lizenzen wegfallen und wo Arbeit entsteht

Die Virtualisierung ist nur eine von vier Schichten, in denen sich Abhängigkeit festsetzt. Das Bild wird erst vollständig, wenn man den ganzen Betriebs-Stack ansieht.

• Monitoring und Observability. Dashboards, Alerting-Regeln und Datenmodelle sind in proprietären Werkzeugen an den Anbieter gebunden. Wer nach einer Grafana-Alternative oder einem Ersatz für ein geschlossenes Monitoring sucht, sollte zuerst fragen, ob die Regeln portabel sind, nicht ob die Oberfläche gefällt.
• Automatisierung und CI/CD. Eine geschlossene Plattform mit eigenem Pipeline-Format baut mit jeder neuen Pipeline Migrationsschulden auf. Bei offenen Werkzeugen liegen Pipelines, Playbooks und Infrastructure-as-Code als Textartefakte im eigenen Repository: versionierbar, auditierbar, portabel. Auch bei der Suche nach einer Ansible-Alternative ist das die eigentliche Frage.
• Virtualisierung und Container. Hier sitzt die teuerste Abhängigkeit, weil ein Wechsel die Architektur berührt.
• Datenbanken. Wer auf Standardprotokolle setzt, kann den Anbieter wechseln, ohne die Anwendungen umzuschreiben.

Der wichtigste Satz dazu lautet: Open Source verschiebt Kosten, es beseitigt sie nicht. Die Lizenz fällt weg, Versionspflege, Sicherheitsupdates und Bereitschaft bleiben. In der Praxis scheitert eine Open-Source-Einführung nicht an der Software, sondern an fehlender Betriebszuständigkeit: Das Projekt hatte ein Team, der Betrieb danach läuft nebenher. Nach dem ersten Jahr ist die Versionslage auseinandergelaufen, und die Befreiung vom Lock-in schlägt in Wartungsschulden um. Deshalb gehört zu jeder Komponente eine namentliche Zuständigkeit, und die Rechnung enthält Betriebs- und Personalkosten, nicht nur die gesparte Lizenz.

Was ein Lock-in kostet, jenseits der Lizenzrechnung

Die Lizenzrechnung ist der Teil, den alle sehen. Sie ist nicht der teuerste.

Zwangskosten. Preiserhöhungen, Bündeländerungen und kurzfristig gekündigte Verträge lassen sich nur ablehnen, wenn es eine Alternative gibt. Ohne Alternative sind es keine Angebote, sondern Rechnungen. Der Betrag steht in keinem Business Case, weil er erst entsteht, wenn die Abhängigkeit schon besteht.

Verhandlungsposition. Wer technisch migrieren könnte, verhandelt anders, auch gegenüber den Anbietern, die er behalten will. Das ist der am meisten unterschätzte Ertrag einer Ablösefähigkeit: Sie zahlt sich auch dann aus, wenn Sie nie ablösen.

Planbarkeit. Offene Projekte veröffentlichen ihre Roadmap, und die Entwicklung wird von einer Gemeinschaft getragen statt von der Produktstrategie eines Eigentümers. Was in drei Jahren gilt, lässt sich abschätzen. Bei einem proprietären Anbieter hängt dieselbe Frage an einer Übernahme, die niemand vorhersagt.

Wiederverwendbarkeit. Eine offene Toolchain lässt sich über mehrere Vorhaben hinweg nutzen. Das Monitoring der Virtualisierung ist dasselbe wie das der Datenbanken, die Automatisierung des einen Projekts trägt das nächste. Aus Betriebswissen werden Skaleneffekte statt Insellösungen.

Anschlussfähigkeit. Offene Automatisierungs- und Datenbankschichten lassen sich an neue Lasten anbinden, KI-Workloads eingeschlossen. Geschlossene Plattformen können das auch, aber zu den Bedingungen des Anbieters und in seinem Zeitplan.

Diesen fünf Posten steht eine Zahl gegenüber, die sich leicht ausrechnen lässt und deshalb gern allein stehen bleibt: die gesparte Lizenz. Eine ehrliche Rechnung stellt daneben, was der offene Betrieb an Personal, Versionspflege und Bereitschaft bindet. Erst danach ist zu sehen, ob sich eine Ablösung lohnt. In manchen Fällen tut sie das nicht, und dann ist das Ergebnis der Prüfung genauso brauchbar.

Exit-Fähigkeit ist das einzige Kriterium, das sich prüfen lässt

Unabhängigkeit als Selbstbeschreibung ist nicht widerlegbar. Jeder Anbieter schreibt sie auf seine Website. Prüfbar wird sie erst als Frage nach der Exit-Fähigkeit: Wie lange und zu welchen Kosten wäre diese Komponente ersetzbar, und wer hat das zuletzt nachgerechnet?

Ein Exit-Test braucht kein Projekt. Er lässt sich auf dem Papier durchspielen und bringt in wenigen Tagen mehr Klarheit als eine Grundsatzdebatte über Open Source. Der praktische Rat dazu: Machen Sie ihn an der unwichtigsten kritischen Komponente. Dort muss niemand das Ergebnis verteidigen, und genau deshalb kommt ein ehrliches heraus.

Aus der Übung folgt ein zweites Kriterium, diesmal für die Wahl des Dienstleisters. Fragen Sie nicht, ob er Open Source einsetzt, sondern was am Tag nach der Kündigung passiert. Liegen die Konfigurationen als Git-Repositories bei Ihnen oder in einem Portal, auf das Sie nach Vertragsende keinen Zugriff mehr haben? Ist der Stack so gewählt, dass ein anderer kompetenter Dienstleister ihn übernehmen kann, oder gibt es eine Eigenbau-Orchestrierung, die nur dieser Anbieter bedient? Steht ein überprüfbares Exit-Versprechen im Vertrag oder nur ein Bekenntnis auf der Website?

Der Nebennutzen ist erheblich. Dokumentierte, reproduzierbare Konfiguration bedient zugleich die Anforderung aus Artikel 21 Absatz 2 Buchstabe c der NIS2-Richtlinie beziehungsweise Paragraf 30 Absatz 2 Nummer 3 BSIG an Konfigurationsdokumentation und Wiederanlauf. Wer wechseln könnte, kann auch wiederanlaufen.

So lösen Sie eine Abhängigkeit auf, ohne die nächste einzugehen

Eine Ablösung ist ein Architektur- und Organisationsprojekt, kein Lizenzthema. In dieser Reihenfolge geht sie auf:

1. Bestandsaufnahme. Vollständiges Inventar der Workloads samt Abhängigkeiten. Regelmäßig der aufwendigste Teil, und der, den niemand überspringen sollte. Nebenbei fallen die Systeme auf, die nur noch aus Vorsicht laufen.
2. Bewertung und Zielbild. Was ist unkompliziert migrierbar, wo entsteht Anpassungsaufwand, was bleibt vorerst, weil sich der Wechsel nicht rechnet? Eine Ablösung, die sich nicht rechnet, ist keine.
3. Testumgebung. Ein Pilot auf der Zielplattform, belastet und geprüft, während der Bestand unangetastet weiterläuft. Backup und Wiederanlauf werden hier getestet, nicht später.
4. Migration in Wellen. Nach Kritikalität, mit Rückfallweg je Dienst. Eine Umstellung des gesamten Rechenzentrums an einem Wochenende ist selten sinnvoll und hat keinen Rückweg.
5. Betrieb. Monitoring, Backup, Rechtevergabe und Wiederanlauf müssen auf der neuen Plattform so verlässlich laufen wie vorher. Erst dann ist die Ablösung abgeschlossen.

Zwischen allen Übergängen gehört eine Go/No-Go-Entscheidung. Sie ist der eigentliche Schutz: Solange nichts Produktives umgestellt ist, bleibt der Ausstieg aus dem Projekt selbst möglich. Und der Zeitpunkt entscheidet über die Verhandlungsposition. Eine frühzeitige, geplante Transition ist günstiger und risikoärmer als eine erzwungene Migration unter Kostendruck.

Fünf Fehler, die eine Ablösung teuer machen

Die Ablösung als Lizenzthema behandeln. Der Preisvergleich ist schnell gemacht, die Betriebsroutinen sind die eigentliche Investition. Wer nur die Lizenz vergleicht, plant die Hälfte des Projekts nicht ein.

Die Lizenzersparnis als reine Einsparung buchen. Betriebs- und Personalkosten der offenen Toolchain gehören gegengerechnet. Sonst entsteht eine Zahl, die im ersten Betriebsjahr nicht hält.

Ohne Betriebszuständigkeit starten. Ein Projektteam führt ein, danach läuft der Betrieb nebenher. Nach einem Jahr ist die Versionslage auseinandergelaufen, und die Sicherheitsupdates sind ein Rückstand statt einer Routine.

Den Umzug für das Ende halten. Die Arbeit verlagert sich mit dem letzten Workload in den Betrieb, ohne dass dort Kapazität eingeplant wurde. Der kritische Moment kommt Monate später, bei der ersten größeren Störung.

Auf eine Lösung von außen warten. Ein laufendes Kartellverfahren, ein Marktgerücht, die Hoffnung auf ein besseres Angebot bei der nächsten Runde: Jede dieser Erwartungen verschiebt den Zeitpunkt nach hinten, und mit jedem Monat wächst der technische Rückstand. Mehr Systeme, mehr Integrationen, mehr Gewöhnung.

Der gemeinsame Nenner: Ein Lock-in entsteht nicht durch eine Entscheidung, sondern durch das Ausbleiben von Entscheidungen. Aufgelöst wird er genauso, Schritt für Schritt.