Vendor Lock-in vermeiden: Bindung erkennen und bewerten

Vendor Lock-in zu vermeiden heißt nicht, Bindung zu vermeiden. Jede Technologieentscheidung bindet: an ein Datenmodell, an eine Laufzeitumgebung, an eine Betriebsweise, an Menschen, die sie beherrschen. Die brauchbare Frage ist nicht „sind wir gebunden?“, sondern „was würde ein Wechsel kosten – in Geld, in Kalenderzeit, in Risiko – und kennen wir diese Zahl, bevor wir unterschreiben?“. Wer die Antwort hat, kauft Bindung bewusst ein. Wer sie nicht hat, erfährt sie erst in dem Moment, in dem der Anbieter die Preise deutlich erhöht oder ein Produkt abkündigt.

Der Unterschied ist konkret. Eine Anwendung auf einem verwalteten PostgreSQL 17 eines Cloud-Anbieters ist gebunden – aber das Wire-Protokoll, der SQL-Dialekt und das Dump-Format sind offen dokumentiert, ein Umzug ist eine Migration mit messbarer Dauer. Eine Anwendung, deren Geschäftslogik in proprietären Stored Procedures, in einem anbieterspezifischen Workflow-Editor und in Triggern einer serverlosen Datenbank liegt, ist ebenfalls gebunden – nur kostet der Exit hier nicht ein Wochenende, sondern ein Reengineering-Projekt. Als Faustregel: Bindungen, die Daten und Schnittstellen berühren, sind teuer; Bindungen, die nur den Betrieb berühren, sind meist verhandelbar.

Dieser Artikel liefert sechs Bindungsarten mit ihren erkennbaren Symptomen, eine Methode zur Bezifferung von Exit-Kosten, ein Vorgehen zum Testen von Datenportabilität statt zum Annehmen, die Bedingungen, unter denen Abstraktionsschichten sich rechnen und wann nicht, den realen Nutzen offener Standards, eine Einordnung von Multi-Cloud – und den regulatorischen Rahmen, den der EU Data Act für Wechselgebühren setzt.

Was Vendor Lock-in technisch bedeutet – und was nicht

Vendor Lock-in

Zustand, in dem die Kosten eines Anbieterwechsels so hoch sind, dass ein wirtschaftlich sinnvoller Wechsel unterbleibt, obwohl Preis, Qualität oder Verfügbarkeit des aktuellen Anbieters dies nahelegen. Lock-in ist damit keine Eigenschaft eines Produkts, sondern eine Relation zwischen Wechselkosten und Wechselnutzen – und beide Seiten sind schätzbar.

Aus dieser Definition folgt eine unbequeme Konsequenz: Auch Open Source erzeugt Bindung. Wer 60.000 Zeilen Kubernetes-Manifeste, Operatoren und Admission-Policies gebaut hat, ist an dieses Ökosystem gebunden, unabhängig von der Lizenz. Der Unterschied liegt nicht in der Abwesenheit von Bindung, sondern darin, wer über die Exit-Bedingungen verfügt: Bei offenen Komponenten sind Format, Protokoll und Quellcode verfügbar, ein Weiterbetrieb ist notfalls selbst möglich. Bei proprietären Diensten entscheidet der Anbieter, ob und wie lange es einen Weg nach draußen gibt. Diese Asymmetrie ist der eigentliche Kern der Debatte – nicht die Frage nach dem besseren Produkt, die wir in einem eigenen Beitrag zum Vergleich von Open Source und proprietärer Software behandeln.

Die sechs Bindungsarten und ihre Symptome

Lock-in ist kein Einzelphänomen, sondern eine Summe. In fast jedem gewachsenen System liegen mehrere Bindungsarten übereinander, und sie haben sehr unterschiedliche Exit-Kostenstrukturen.

Bindungsart	Symptom im Alltag	Exit-Kostentreiber	Gegenmaßnahme
Datenbindung	Export nur als PDF, CSV ohne Relationen, Historie und Anhänge fehlen	Rekonstruktion von Beziehungen, Nachpflege manuell, Datenverlust	Vollexport regelmäßig ziehen und in ein neutrales Schema laden
API-Bindung	Anbieterspezifische SDKs quer über den Code, keine dokumentierte Schnittstellendefinition	Umschreiben von Aufrufstellen, erneutes Testen der Fachlogik	Aufrufe hinter einer schmalen Naht bündeln, OpenAPI-Beschreibung einfordern
Betriebsbindung	Deployment nur über die Konsole des Anbieters, keine reproduzierbare Umgebung	Neuaufbau von Netz, Rechten, Backups, Monitoring	Infrastruktur als Code, Container-Images nach OCI, portable Backups
Wissensbindung	Nur zwei Personen können das System ändern, Schulungen sind produktspezifisch	Einarbeitung, Beratertage, Fehlerrate in der Übergangsphase	Betriebsdokumentation im Repository, Rotation, Konzepte statt Produktschulung
Lizenzbindung	Preis je Nutzerstaffel, Metriken vom Anbieter erhoben, Audit-Klausel im Vertrag	Nachlizenzierung, Strafzahlungen, erzwungene Upgrades	Lizenzmetriken selbst messen, Staffelgrenzen im Monitoring abbilden
Vertragsbindung	Mehrjährige Laufzeit, Rabatt gegen Mindestabnahme, Egress-Tarife	Restlaufzeit, Egress-Volumen, Parallelbetrieb während der Migration	Kündigungsfristen und Datenrückgabe verhandeln, Volumen nicht überbinden

Datenbindung ist die teuerste und die stillste

Datenbindung entsteht nicht durch das Fehlen eines Export-Knopfes, sondern durch Exportlücken. Typisch: Der Export enthält die aktuellen Datensätze, aber keine Änderungshistorie; er enthält Dateianhänge nur als Links auf einen Speicher, der beim Vertragsende gelöscht wird; er enthält Fremdschlüssel als anbieterinterne IDs ohne Auflösung; oder er ist auf 10.000 Zeilen je Aufruf begrenzt, was bei 40 Millionen Datensätzen einen Skript-Marathon mit Rate-Limits bedeutet.

API-, Betriebs- und Wissensbindung wachsen unbemerkt

API-Bindung ist selten eine bewusste Entscheidung. Sie entsteht, wenn ein anbieterspezifisches SDK an 340 Stellen im Code importiert wird, weil es bequem ist. Betriebsbindung entsteht, wenn Konfiguration über Web-Oberflächen entsteht und nirgends versioniert wird – wer eine Umgebung nicht aus einem Repository neu aufbauen kann, kann sie auch nicht bei einem anderen Anbieter aufbauen. Wissensbindung entsteht durch produktzentrierte Qualifizierung: Wer nur die Oberfläche eines Werkzeugs gelernt hat, aber nicht das darunterliegende Konzept – Netzwerksegmentierung, Transaktionsisolation, Zustellsemantik einer Queue –, kann das Wissen nicht übertragen.

Exit-Kosten beziffern statt schätzen

„Zu teuer zum Wechseln“ ist keine Zahl. Eine belastbare Bezifferung braucht fünf Posten, die sich getrennt schätzen und getrennt senken lassen.

Diese fünf Posten gehören in ein versioniertes Exit-Register, das pro Dienst gepflegt wird – ein einziges Dokument im Repository, das jede Beschaffungsentscheidung begleitet und bei jeder Architekturprüfung aktualisiert wird.

# exit-register.yaml – pro Dienst gepflegt, im Repository versioniert
- dienst: object-storage
  anbieter: Anbieter A
  schnittstelle: S3-kompatibel
  datenbestand: 41 TB / 12,4 Mio. Objekte
  exportweg: rclone sync auf eigenen MinIO-Cluster
  letzter_testlauf: 2026-06-14
  gemessene_exportdauer: 38 h bei 2,5 Gbit/s
  egress: laut Preisliste, Volumen 41 TB
  bindungsgrad: niedrig
  offene_punkte: Objekt-Metadaten und Versionierung nicht im Test enthalten

- dienst: workflow-engine
  anbieter: Anbieter B
  schnittstelle: proprietär, kein dokumentiertes Austauschformat
  datenbestand: 1.850 Prozessdefinitionen
  exportweg: keiner, nur Screenshot-Dokumentation
  letzter_testlauf: nie
  bindungsgrad: hoch
  offene_punkte: Neuimplementierung geschätzt 120 Personentage

Der zweite Eintrag ist der interessante. Er ist nicht per se falsch – vielleicht spart die Engine tatsächlich mehr, als ihr Exit kostet. Aber die Zahl steht jetzt da und kann gegen den Nutzen gestellt werden, statt als vage Sorge zu existieren.

Datenportabilität testen statt annehmen

Ein Portabilitätstest ist eine wiederkehrende Übung, kein einmaliges Projekt. Für eine relationale Datenbank sieht er im Kern so aus: logischen Dump ziehen, in eine fremde Instanz zurückspielen, danach nicht auf „keine Fehlermeldung“ vertrauen, sondern inhaltlich vergleichen.

# 1. Vollständigen logischen Dump ziehen und die Dauer messen
time pg_dump --format=custom --no-owner --no-privileges \
     --file="/backup/prod-$(date +%F).dump" "$SOURCE_URL"

# 2. In eine leere Zielinstanz zurückspielen (anderer Anbieter, andere Region)
createdb -h "$TARGET_HOST" restore_test
time pg_restore --dbname="postgresql://$TARGET_HOST/restore_test" \
     --no-owner --jobs=4 "/backup/prod-$(date +%F).dump"

# 3. Zeilenzahl und Inhaltsprüfsumme je Tabelle vergleichen
for t in kunden auftraege buchungen; do
  q="select count(*), md5(string_agg(t::text, '|' order by t::text)) from $t t"
  s=$(psql -tAX "$SOURCE_URL" -c "$q")
  d=$(psql -tAX "postgresql://$TARGET_HOST/restore_test" -c "$q")
  if [ "$s" = "$d" ]; then echo "$t ok"; else echo "$t ABWEICHUNG: $s != $d"; fi
done

Der Test liefert drei Zahlen, die im Exit-Register landen: Dauer des Dumps, Dauer der Wiederherstellung, Anzahl abweichender Tabellen. Er deckt zuverlässig auf, was Dokumentation verschweigt – Sequenzen, die nach dem Import falsch stehen, Erweiterungen, die in der Zielumgebung nicht verfügbar sind, Zeitzonen- und Kollationsunterschiede, Berechtigungen, die nicht mitkommen. Für Objektspeicher gilt dasselbe Prinzip mit anderen Werkzeugen: einmal vollständig synchronisieren, Objektanzahl und Prüfsummen vergleichen, Metadaten und Versionierung ausdrücklich mitprüfen.

Abstraktionsschichten: wann sie sich rechnen

Die reflexhafte Antwort auf Lock-in ist eine eigene Abstraktionsschicht. Sie ist oft die schlechtere Wahl. Eine Schicht, die den vollen Funktionsumfang mehrerer Anbieter abdecken soll, wird zur eigenen Plattform mit eigenen Fehlern, eigener Dokumentation und eigenem Wartungsaufwand – und sie reduziert die Nutzbarkeit auf den kleinsten gemeinsamen Nenner. Der Preis für theoretische Portabilität wird dann jeden Tag bezahlt, der Nutzen vielleicht nie.

Was sich rechnet, ist eine schmale Naht: genau die Operationen, die die Anwendung tatsächlich braucht, als Schnittstelle formuliert, dahinter ein dünner Adapter je Anbieter.

// Schmale Naht: nur die vier Operationen, die die Anwendung wirklich nutzt.
// Adapter je Anbieter bleiben unter 100 Zeilen und sind vollständig testbar.
export interface ObjectStore {
  put(key: string, body: Uint8Array, contentType: string): Promise<void>;
  get(key: string): Promise<Uint8Array>;
  remove(key: string): Promise<void>;
  presignedUrl(key: string, ttlSeconds: number): Promise<string>;
}

Der Unterschied zur großen Abstraktion ist der Umfang. Vier Methoden bedeuten: Der Wechsel des Objektspeichers ist ein Adapter und ein Integrationstest, nicht eine Suche nach 340 Importen. Gleichzeitig bleibt die Anwendung frei, an einer bewusst benannten Stelle anbieterspezifische Funktionen direkt zu nutzen, wenn sie den Aufwand wert sind. Solche Entscheidungen gehören dokumentiert – als Architekturentscheidung mit Begründung und benannter Alternative, wie wir es in der Softwarearchitektur grundsätzlich handhaben.

Ansatz	Laufende Zusatzkosten	Erwartete Exit-Dauer	Sinnvoll wenn
Direkte Nutzung, kein Exit-Konzept	keine	unbekannt	Datenbestand klein, Dienst leicht ersetzbar
Direkte Nutzung plus getesteter Exportweg	gering (Testläufe)	Wochen, belegt	Standardfall für die meisten Dienste
Schmale Naht plus zweiter Adapter im Test	mittel	Tage bis Wochen	Dienst zentral, Anbieterrisiko real
Vollständige Abstraktion über mehrere Anbieter	hoch, dauerhaft	Tage	regulatorische Pflicht zum Zweitanbieter

Offene Standards und Formate als Gegengewicht

Der wirksamste Hebel gegen Lock-in liegt vor der ersten Zeile Code: die Wahl von Formaten und Protokollen, die mehrere Implementierungen haben. Ein Format mit zwei unabhängigen, produktiv genutzten Implementierungen ist praktisch portabel; eines mit einer ist es nicht, egal wie gut es spezifiziert ist.

Konkret bewährt: SQL und das PostgreSQL-Wire-Protokoll für relationale Daten, die S3-API für Objektspeicher (implementiert unter anderem von MinIO und Ceph), OCI-Images und -Registries für Auslieferungsartefakte, OTLP und OpenTelemetry für Metriken, Traces und Logs, OpenAPI für HTTP-Schnittstellen, OIDC und SAML für Authentifizierung, ODF für Dokumente und iCalendar für Termine. Für Infrastrukturbeschreibungen ist die HCL-Ebene mit OpenTofu als offener Implementierung ein Beispiel dafür, wie eine Lizenzänderung des Originalprojekts durch einen Fork abgefedert wurde – ein Vorgang, der bei proprietärer Software keine Entsprechung hat.

Multi-Cloud ist meist die teure Antwort auf die falsche Frage

Multi-Cloud – der gleichzeitige, gleichwertige Betrieb derselben Anwendung bei zwei Anbietern – wird häufig als Lock-in-Vermeidung verkauft. In der Praxis verdoppelt es Betriebsaufwand, Bereitschaft, Sicherheitsprüfungen und Kostenkontrolle, erzwingt die Beschränkung auf gemeinsame Fähigkeiten und erzeugt Datenverkehr zwischen den Anbietern, der nach Egress abgerechnet wird. Es senkt die Wechselkosten erst dann, wenn beide Seiten tatsächlich dauerhaft produktiv laufen – und genau das ist der teure Teil.

Die praktikable Alternative heißt Portabilität statt Gleichzeitigkeit: Ein Anbieter im Betrieb, aber reproduzierbare Umgebungsbeschreibung, portable Artefakte, getesteter Datenexport und ein zweiter Adapter, der im Integrationstest läuft, nicht in Produktion. Damit ist der Wechsel eine geplante Migration von Wochen statt eine Neuentwicklung – bei einem Bruchteil der laufenden Kosten. Ein Zweitanbieter im echten Parallelbetrieb ist gerechtfertigt, wenn eine Aufsichtsbehörde ihn verlangt oder wenn ein Ausfall in Minuten und nicht in Stunden gemessen wird. Welche Variante zu welcher Betriebsrealität passt, ist eine Frage der DevOps- und Cloud-Architektur und keine reine Beschaffungsentscheidung.

Der regulatorische Rahmen: Wechselgebühren nach dem EU Data Act

Seit dem 12. September 2025 gilt die Verordnung (EU) 2023/2854 (Data Act). Ihr Kapitel VI regelt den Wechsel zwischen Datenverarbeitungsdiensten und verschiebt einen Teil der Verhandlungslast zugunsten der Kunden: Anbieter müssen Wechsel vertraglich ermöglichen, unterstützen und mit einer maximalen Übergangsfrist arbeiten, die grundsätzlich 30 Kalendertage beträgt und nur bei technischer Undurchführbarkeit verlängert werden darf. Für Wechselgebühren sieht Artikel 29 einen stufenweisen Abbau vor: Bis zum 12. Januar 2027 dürfen nur reduzierte, an den tatsächlich entstandenen Kosten orientierte Gebühren verlangt werden, danach keine mehr.

Für die eigene Planung folgt daraus wenig Entspannung und ein klarer Auftrag. Die Regelung senkt bestimmte Ausgangskosten, sie beseitigt aber weder Migrationsaufwand noch Datenbindung, noch Wissensbindung – und sie greift nur, wenn im Vertrag die passenden Ansprüche verankert und die eigenen Datenbestände überhaupt ausleitbar sind. Rechtliche Wechselrechte ersetzen keinen getesteten Exportweg; sie machen ihn nur billiger.

Fazit

Lock-in ist kein Fehler in der Architektur, sondern ein Posten in der Kalkulation. Wer für jeden zentralen Dienst benennen kann, wie lange ein Export dauert, wann er zuletzt zurückgelesen wurde und welche fünf Kostenposten ein Wechsel auslöst, verhandelt aus einer anderen Position als jemand, der nur ein Unbehagen formulieren kann. Die wirksamen Maßnahmen sind unspektakulär: Formate mit mehreren Implementierungen wählen, Konfiguration versionieren, Aufrufstellen an einer schmalen Naht bündeln, Portabilität regelmäßig messen statt annehmen. Große Abstraktionen und Multi-Cloud-Aufbauten sind dagegen selten die Antwort – sie verlagern die Kosten nur vom hypothetischen Exit in den laufenden Betrieb. Wenn Sie diese Bewertung für einen konkreten Bestand vornehmen wollen, ist die Open-Source-Beratung der passende Einstieg.