Vendor Lock-in: Abhängigkeiten erkennen und Auswege prüfen

Was bedeutet Vendor Lock-in?

Vendor Lock-in ist eine Anbieterbindung, bei der ein Wechsel erhebliche zusätzliche Arbeit, Kosten oder Betriebsrisiken verursacht. Das kann eine kommerzielle Bindung durch Verträge sein, aber auch eine technische Bindung an ein Datenmodell, eine Plattform oder bestimmte Funktionen. Die aktuelle Cloud-Guidance des britischen Government Digital Service unterscheidet diese Formen und beschreibt ausdrücklich, dass eine technische Bindung auch bei kündbaren Cloud-Verträgen bestehen kann.

Nicht jede Migration ist deshalb schon ein problematischer Lock-in. Mitarbeitende müssen sich bei fast jedem Systemwechsel umstellen; Daten müssen häufig zugeordnet werden. Kritisch wird die Bindung, wenn diese Hürden Ihre Handlungsmöglichkeiten unverhältnismäßig beschneiden: etwa wenn eine benötigte Änderung nicht verfügbar ist und Sie den betroffenen Prozess trotzdem nicht an anderer Stelle betreiben können.

Hilfreich ist außerdem die Unterscheidung zwischen Anbieter und Technologie. Können Sie die gleiche Anwendung durch einen anderen Dienstleister betreiben lassen, haben Sie möglicherweise eine personelle oder vertragliche Abhängigkeit. Müssen Sie dafür große Teile der Anwendung neu schreiben, liegt die Hürde tiefer. Eine andere Vertragspartei allein löst sie nicht.

Wo Ihre Abhängigkeit steckt

Beginnen Sie mit einem wichtigen Geschäftsprozess und verfolgen Sie ihn vom Eingang bis zum Ergebnis. Ein allgemeines Etikett wie „offene Plattform“ hilft dabei weniger als die Frage, was für diesen einen Ablauf außerhalb des Anbieters fehlen würde. Die folgende Prüftabelle ist ein Arbeitsmodell: Sie ersetzt eine pauschale Risikonote durch konkrete Nachweise.

Markieren Sie fehlende Nachweise als „offen“. Ein zugesagter Export ist noch kein geprüfter Export; eine vorhandene Dokumentation ist noch keine gelungene Übergabe. Halten Sie außerdem fest, wer eine Lücke klärt. Sonst bleibt ausgerechnet die Stelle ungeprüft, an der der spätere Wechsel scheitern könnte.

Diese Untersuchung sollte auch angrenzende Systeme umfassen. Eine scheinbar eigenständige Anwendung kann beispielsweise eine zentrale Anmeldung, ein Dokumentenarchiv oder eine Automationsplattform voraussetzen. Entscheidend ist, ob der benötigte Zusammenhang erhalten bleibt, wenn Sie den betrachteten Anbieter ersetzen.

Beispiel: Ein Export ist noch kein Ausstieg

Illustratives Beispiel: Ein Unternehmen bearbeitet Reklamationen in einer SaaS-Anwendung. Der Export enthält Kundennummer, Reklamationsgrund und Bearbeitungsstatus. Damit lässt sich eine Liste der Vorgänge übernehmen. Im laufenden Prozess entscheidet die Anwendung aber zusätzlich, wer eine Gutschrift freigeben darf, welche Unterlagen benötigt werden und wann ein Vorgang an die Buchhaltung übergeben wird.

Nach dem Import der Liste kann das neue System deshalb noch keinen vollständigen Fall bearbeiten. Es fehlen womöglich die Freigaberegel, eine verlässliche Verknüpfung zu den Belegen und die Bedeutung der bisherigen Statuswechsel. Auch die fachliche Frage, ob eine Gutschrift bereits übermittelt wurde, muss beantwortbar bleiben. Das Problem steckt hier nicht allein im Dateiformat.

Ein sinnvoller Gegencheck lautet daher: Kann ein berechtigter Mitarbeiter einen übernommenen Reklamationsfall prüfen, eine Gutschrift freigeben und die korrekte Rückmeldung aus dem Finanzsystem sehen? Und lässt sich nachvollziehen, was vorher passiert ist? Wenn das gelingt, haben Sie einen wesentlich aussagekräftigeren Nachweis als einen erfolgreichen Dateidownload.

Wählen Sie für diesen Test bewusst auch eine Ausnahme: etwa einen Fall mit fehlendem Beleg oder bereits erfolgter Teilbearbeitung. Ein glücklicher Standardablauf verdeckt sonst genau die Regeln, die außerhalb der SaaS erst rekonstruiert werden müssen. Der Testfall belegt den Ablauf; Vollständigkeit und Qualität des gesamten Datenbestands müssen Sie zusätzlich prüfen.

Wann Behalten vernünftig ist

Abhängigkeit hat einen Preis, kann aber auch Leistungen bündeln, die Sie sonst selbst verantworten müssten. Eine gut passende Lösung mit abgestimmtem Support und einem tragfähigen Wechselverfahren kann sinnvoller sein als ein aufwendiger Umbau. Auch die GDS-Abwägung von Nutzen und Portabilität lässt ausdrücklich zu, eine geringere Wechselbarkeit bewusst zu akzeptieren.

Behalten ist besonders gut begründbar, wenn der Prozess fachlich passt, die Kostenentwicklung nachvollziehbar ist und die verbleibenden Hürden bekannt sind. Dokumentieren Sie dann, welche Bindung Sie akzeptieren und warum. Damit wird die Entscheidung überprüfbar, statt auf der Hoffnung zu beruhen, dass nie etwas geändert werden muss.

Vorbereitung wird dringlicher, wenn wichtige Anforderungen von der Produktplanung des Anbieters abhängen, eine Vertragsverlängerung bevorsteht oder eine zentrale Schnittstelle verändert wird. Fragen Sie dabei nicht nur, ob ein Wechsel teuer wäre. Fragen Sie auch, welchen Schaden ein nicht möglicher Wechsel für diesen Prozess verursachen könnte und wie viel Vorbereitungszeit Sie dann hätten.

Verhandeln, den Funktionsumfang reduzieren, eine Integration entkoppeln oder eine begrenzte eigene Ergänzung bauen sind mögliche Zwischenschritte. Ein vollständiger Ersatz ist nur eine Option. Welche davon trägt, hängt von Ihrem konkreten Prozess, der erreichbaren Alternative und der Fähigkeit zum künftigen Betrieb ab.

Abhängigkeiten gezielt reduzieren

Setzen Sie zuerst an der Bindung an, die Ihre wichtigste Handlungsoption blockiert. Wenn die Datenzuordnung unklar ist, hilft Ihnen eine zweite Cloud wenig. Wenn niemand die Freigabelogik erklären kann, schafft ein anderer Hostingvertrag noch keine fachliche Unabhängigkeit.

Daten und Schnittstellen verständlich halten

Dokumentieren Sie die Bedeutung Ihrer wichtigen Datenobjekte, Identifikatoren und Beziehungen. Verzeichnen Sie auch, welche Angaben im Export fehlen oder gesondert abgerufen werden müssen. Prüfen Sie mit einem tatsächlichen Export, ob Formate, Zugriffsrechte und Umfang zu Ihrem vorgesehenen Ziel passen.

Bei Integrationen kann eine abgegrenzte Übersetzungsschicht verhindern, dass überall in Ihrer Anwendung die besondere Logik eines Fremdsystems steckt. Das Anti-Corruption-Layer-Muster im Microsoft Architecture Center beschreibt diese Trennung unterschiedlicher Datenmodelle und Bedeutungen. Es benennt zugleich den zusätzlichen Betrieb und die Wartung der Schicht. Nutzen Sie sie an einer echten fachlichen Grenze; eine unnötige zusätzliche Komponente schafft eigene Arbeit.

Rechte, Wissen und Betriebsfähigkeit zusammen prüfen

Klären Sie bei eigener oder beauftragter Software, welche Quelltexte, Konfigurationen, Dokumentationen und Zugänge ein übernehmendes Team erhalten soll. Lassen Sie sich eine Änderung und einen Wiederanlauf erklären, statt ausschließlich einen Dokumentenordner abzunehmen. So erkennen Sie, ob die Übergabe praktisch funktioniert.

Open Source kann den Handlungsspielraum erweitern: Die Open Source Definition der OSI verlangt unter anderem verfügbaren Quellcode und Rechte für Änderungen und Weitergabe. Daraus folgt jedoch kein Nachweis, dass Ihr Team die konkrete Anwendung betreiben kann. Ebenso sollten Sie bei Eigenentwicklung die verwendeten Plattformdienste, Bibliotheken und das verfügbare Wissen mitprüfen.

Auch mehrere Cloudanbieter sind kein Ersatz für einen konkreten Wechseltest. Zwei getrennte Systeme können jeweils fest an ihren eigenen Anbieter gebunden sein. Definieren Sie deshalb zuerst, welcher Prozess oder welche Komponente austauschbar sein soll. Erst danach lässt sich beurteilen, ob zusätzliche Plattformen den Aufwand rechtfertigen.

Was der EU Data Act verändert

Der Data Act ist seit dem 12. September 2025 anwendbar. Kapitel VI erleichtert den Wechsel zwischen Datenverarbeitungsdiensten, einschließlich Cloud- und SaaS-Diensten. Die Erläuterung der EU-Kommission beschreibt die vorgesehenen Wechsel- und Portabilitätsanforderungen.

Nach Artikel 25 und 30 der Verordnung (EU) 2023/2854 gehören unter anderem das Wechselverfahren und die übertragbaren Datenkategorien in den Vertrag; technische Pflichten betreffen Schnittstellen und Datenexport. Das ist kein allgemeiner Anspruch auf eine identische SaaS-Anwendung beim neuen Anbieter.

Prüfen Sie für Ihren Dienst das anwendbare Regelwerk und die konkreten Vertragsstellen. Technischer Export, fachliche Übernahme und Betrieb bleiben getrennte Aufgaben.

Einen SaaS-Exit nachweisen

Eine Exit-Strategie beschreibt hier den Anbieterwechsel oder die Übernahme eines Prozesses, nicht den Verkauf eines SaaS-Unternehmens. Ihr Ergebnis sollte ein überprüfbarer Übergangsplan sein: Was verlässt das bisherige System, was bleibt und welche Voraussetzungen fehlen noch?

1. Den Umfang festlegen. Beschreiben Sie den betroffenen Prozess, seine Nutzer, Datenobjekte und angrenzenden Systeme. Trennen Sie benötigte Funktionen von selten genutztem oder inzwischen unnötigem Umfang. Bestimmen Sie, welches fachliche Ergebnis die Alternative liefern muss.
2. Die Übernahme prüfen. Rufen Sie die erforderlichen Daten und digitalen Inhalte tatsächlich ab. Prüfen Sie Datensatzumfang, Beziehungen, Anhänge und Historie gegen den zuvor festgelegten Bedarf. Notieren Sie Exportbeschränkungen und ungeklärte Kategorien, statt sie im Projekt stillschweigend vorauszusetzen.
3. Den Zielprozess erproben. Führen Sie Standard- und Ausnahmefälle durch. Prüfen Sie Berechtigungen, Regeln, Schnittstellenrückmeldungen und nachvollziehbare Änderungen. Erhalten Sie Daten aus einem Export, ohne den Ablauf ausführen zu können, ist der Prozessnachweis noch offen.
4. Den Betrieb vorbereiten. Benennen Sie Verantwortliche für Support, Fehleranalyse, Änderungen und Wiederherstellung. Erproben Sie den Wiederanlauf mit dem künftigen Team. Halten Sie fest, welche Zugänge und Informationen von bisherigen oder neuen Partnern benötigt werden.
5. Umschaltung und Rückfall festlegen. Entscheiden Sie, wie Änderungen während der Übergangsphase nachgeführt werden, welches System dann führend ist und unter welchen Bedingungen Sie abbrechen. Kündigung, Datenabruf, Archivierung und Abschaltung müssen zu diesem Ablauf passen.

Bewerten Sie die Nachweise erneut, wenn sich Ihr Datenmodell, ein wichtiger Ablauf oder eine zentrale Integration verändert. Ein Test aus einer früheren Systemversion ist kein Beleg für alle späteren Änderungen. Der nächste Prüftermin sollte deshalb an konkrete Veränderungen und Vertragsentscheidungen gekoppelt sein.

Welche Unterlagen Ihre Entscheidung tragen

Für eine belastbare Abstimmung brauchen Sie kein fertiges Ersatzsystem. Bringen Sie einen beschriebenen Geschäftsfall, den bisherigen Funktionsumfang, eine geeignete Datenprobe und die wichtigen Integrationen zusammen. Ergänzen Sie die relevanten Vertragsstellen, bekannte Kostenpositionen, vorhandene Exportnachweise und die offenen Fragen mit Verantwortlichen.

Damit können Sie konkret entscheiden: Bleibt die Lösung mit bewusst akzeptierter Bindung? Reicht eine gezielte Entkopplung? Oder trägt eine alternative Software beziehungsweise ein eigener Fachkern? Halten Sie auch fest, welche Information die Entscheidung noch verändern würde.

Wenn Sie diese Fragen für eine bestehende Anwendung fachlich und wirtschaftlich prüfen möchten, beschreibt das SaaS Replacement Assessment von eBiz den passenden nächsten Schritt. Es bewertet Kosten, Funktionskern, Daten, Integrationen und Betriebsmodell als Grundlage für Behalten, Ersetzen oder Neubau.