Vendor Lock-in im Mittelstand: Warum „Später" das teuerste Wort im IT-Betrieb ist
Vendor Lock-in klingt dramatisch. In der Praxis beginnt er selten mit einem lauten Crash. Es ist ein stilles Scheitern: „Das geht gerade nicht." „Der Export? Später." „Die Schnittstelle? Kommt noch." Im IT-Betrieb mittelständischer Unternehmen passiert dieses Irgendwann oft nie. Und wenn es darauf ankommt – beim Anbieterwechsel, bei der Fusion, bei einer regulatorischen Anforderung – stellt sich heraus: Das Unternehmen ist gefangen.
Was Vendor Lock-in wirklich bedeutet
Lock-in ist nicht das Problem, dass ein Anbieter gut ist. Lock-in ist das Problem, dass man nicht mehr herauskommt, ohne großen Schaden zu nehmen – auch wenn man es wollen würde. Die klassischen Manifestationen im Mittelstand: Daten in proprietären Formaten, die nirgendwo anders lesbar sind. Workflows, die tief in Plattformlogik verankert sind. Identitätskonzepte, die nicht portierbar sind. Monitoring und Alerting, das nur innerhalb des Anbieters funktioniert.
Einzeln ist jedes dieser Probleme lösbar. In Kombination erzeugen sie eine Abhängigkeit, die teuer zu überwinden ist – und die oft erst dann bewusst wird, wenn es zu spät für eine kostengünstige Lösung ist.
Warum „Später" das teuerste Wort im IT-Betrieb ist
Das Tückische an Vendor Lock-in ist sein schleichender Charakter. Kein Entscheider unterschreibt bewusst einen Vertrag in die Abhängigkeit. Die Abhängigkeit entsteht durch Entscheidungen, die nie getroffen wurden – durch das Aufschieben von Exit-Planung, Formatdokumentation und Übergangsszenarien. „Wir klären das, wenn es relevant wird" ist die teuerste Form der Planung.
Wer einen Exit erst dann plant, wenn er nötig wird, zahlt dreifach: für den ungeplanten Prozess, für die fehlende Dokumentation und für die Zeit, in der das Unternehmen handlungsunfähig ist. In regulierten Branchen kommt dazu noch das Compliance-Risiko einer unkontrollierten Abhängigkeit.
Exit-Governance als Teil des IT-Betriebs
Die gute Nachricht: Lock-in ist kein Schicksal. Er ist ein Governanceproblem – und lösbar mit den richtigen Prozessen. Was gute Exit-Governance konkret bedeutet:
Datenexport in offenen Formaten sicherstellen – nicht nur „API existiert", sondern regelmäßig getestete, vollständige Exportpfade. Der Unterschied ist entscheidend: Eine API, die in der Theorie existiert, aber in der Praxis nie genutzt wurde, ist kein echter Exitpfad.
Abhängigkeiten dokumentieren – Identitäten, Workflows, Automationen, Integrationen. Was würde beim Herausziehen des Anbieters reißen? Diese Frage sollte jede Organisation mindestens einmal jährlich durchdenken und die Antwort dokumentieren.
Betriebsübergabe vorbereiten – Runbooks, Zugriffskonzepte, Monitoring-Konfigurationen so gestalten, dass ein anderes Team oder ein anderer Anbieter übernehmen könnte. Exit-Übungen durchführen: Was kostet uns ein Anbieterwechsel? Wie lange dauert er? Diese Fragen sollten keine theoretischen sein. Eine echte Übung deckt Stolpersteine auf, die kein Architekt auf dem Papier sieht.
Lock-in und regulatorische Realität
Für Unternehmen unter NIS-2, DORA oder ISO-27001-Anforderungen ist Exit-Governance keine Kür, sondern Pflicht. Business Continuity und Vendor Management verlangen explizit, dass Abhängigkeiten bekannt, dokumentiert und managebar sind. Wer bei einem Audit nicht sagen kann, wie lang ein Anbieterwechsel dauern würde, hat ein Compliance-Problem – unabhängig von der Qualität der technischen Dokumentation.
Wo liegt der echte Lock-in?
In der Praxis zeigt sich: Der schwerste Lock-in ist selten der technische. Er liegt in Datenformaten – proprietäre Strukturen, die Migrationen aufwändig machen. Er liegt in Betriebsprozessen – Teams, die ausschließlich mit den Werkzeugen eines Anbieters arbeiten können. Und er liegt in Identität und Zugang – IAM-Konzepte, die plattformgebunden sind und nicht migriert werden können.
Die erste Frage sollte deshalb nicht „Wo liegen unsere Daten?" sein, sondern: „Können wir sie morgen exportieren, wenn wir müssen?" Vendor Lock-in beginnt selten laut. Er endet laut. Wer IT-Governance ernst nimmt, behandelt Exit-Fähigkeit nicht als optional – sondern als Standardbaustein jeder Cloud-Entscheidung. „Später" ist kein Plan. Es ist ein Risiko.