Vendor Lock-in ist kein technisches Problem — es ist ein strategisches. Die Frage ist nicht, ob Abhängigkeiten entstehen, sondern ob Sie sie bewusst eingehen und steuern. Praktisch jedes Unternehmen, das Public-Cloud-Services nutzt, ist in mindestens einer Dimension von seinem Provider abhängig. Jede Entscheidung für einen Cloud-Provider, eine Datenbank oder ein SaaS-Tool schafft Bindungen. Das Ziel ist nicht totale Unabhängigkeit, sondern kalkulierte Abhängigkeit mit dokumentierten Exit-Optionen. Mit dem EU Data Act (Verordnung 2023/2854), der seit September 2025 Wechsel- und Portabilitätsrechte für Cloud-Kunden stärkt[2], gewinnt dieses Thema zusätzliche regulatorische Bedeutung.

Lock-in erkennen, bevor er zuschlägt

Lock-in wird sichtbar, wenn Abhängigkeiten in Verträgen, Daten und Schnittstellen gemeinsam betrachtet werden.
Abbildung 1: Lock-in wird sichtbar, wenn Abhängigkeiten in Verträgen, Daten und Schnittstellen gemeinsam betrachtet werden.

Vendor Lock-in hat viele Gesichter — nicht alle sind offensichtlich[3]:

  • Technischer Lock-in: Proprietäre APIs, Datenformate oder Services ohne Äquivalent bei anderen Anbietern (z.B. AWS Lambda@Edge, Azure Cosmos DB)
  • Vertraglicher Lock-in: Langfristige Verträge mit hohen Vertragsstrafen und Ausstiegsgebühren, automatische Verlängerungen, Mindestabnahmemengen
  • Daten-Lock-in: Hohe Egress-Gebühren für Datentransfer, proprietäre Speicherformate, fehlende Exportfunktionen. Der Branchenverband CISPE (Cloud Infrastructure Services Providers in Europe) dokumentiert Egress-Gebühren, die ein Vielfaches der zugrunde liegenden Kosten betragen können, als eine der zentralen Wechselbarrieren[4]
  • Kompetenz-Lock-in: Das Team beherrscht nur einen Stack. Migration würde massive Umschulung erfordern
  • Architektur-Lock-in: Microservices, die tief in provider-spezifische Messaging-Systeme integriert sind

Der gefährlichste Lock-in ist der schleichende: Jede kleine Entscheidung für einen proprietären Service erhöht die Wechselkosten unmerklich — bis eine Migration praktisch unmöglich wird.

Offene Standards als Versicherung

Offene Standards schaffen Wechseloptionen, bevor strategische Abhängigkeit entsteht.
Abbildung 2: Offene Standards schaffen Wechseloptionen, bevor strategische Abhängigkeit entsteht.

Die wirksamste Prävention gegen Lock-in ist die konsequente Nutzung offener Standards:

  • Container statt Serverless: Kubernetes läuft überall. AWS Fargate oder Azure Container Apps sind portabler als Lambda Functions. Die Cloud Native Computing Foundation (CNCF) zählt Kubernetes zu den am weitesten verbreiteten Open-Source-Projekten für Cloud-Infrastruktur[5]
  • SQL statt proprietär: PostgreSQL statt DynamoDB oder Cosmos DB — die Leistungsunterschiede sind in den meisten Anwendungsfällen irrelevant
  • Terraform statt CloudFormation: Infrastructure as Code mit provider-agnostischen Tools
  • S3-kompatible Speicher: Praktisch jeder Object Storage ist S3-kompatibel — inklusive On-Premise-Lösungen wie MinIO
  • OpenTelemetry: Vendor-neutrale Observability statt proprietärer Monitoring-Tools

Die billigste Migration ist die, die Sie nie durchführen müssen — weil Sie von Anfang an portabel gebaut haben. Jede Stunde, die Sie heute in Abstraktionsschichten investieren, spart Wochen bei einer späteren Migration.

Die Multi-Cloud-Frage

Eine Sourcing-Strategie balanciert Geschwindigkeit, Kosten und Verhandlungsmacht.
Abbildung 3: Eine Sourcing-Strategie balanciert Geschwindigkeit, Kosten und Verhandlungsmacht.

Multi-Cloud wird oft als Lösung für Lock-in gepriesen. Die Realität ist komplexer — Gartner prognostizierte bereits 2021, dass bis 2025 über 85 % der Unternehmen einen Cloud-First-Ansatz verfolgen würden[1]; echte Workload-Portabilität zwischen Providern bleibt dagegen die Ausnahme:

  • Echtes Multi-Cloud (gleiche Workloads auf mehreren Providern) ist teuer, komplex und selten sinnvoll
  • Polyglot Cloud (verschiedene Workloads bei verschiedenen Providern) ist pragmatischer — nutzen Sie die Stärken jedes Anbieters
  • Cloud + On-Premise Hybrid ist für viele Mittelständler der realistischste Ansatz — sensible Daten lokal, elastische Workloads in der Cloud. Wie verbreitet Cloud-Nutzung im deutschen Mittelstand inzwischen ist, dokumentiert der jährliche Bitkom Cloud-Monitor[6]

Die Faustregel: Nutzen Sie managed Services für Commodity-Funktionen (Compute, Storage, Networking) und eigene Abstraktionsschichten für Differenzierungs-Features.

Exit-Strategie dokumentieren

Exit-Fähigkeit muss vor dem Vertragsabschluss geplant werden, nicht erst im Konfliktfall.
Abbildung 4: Exit-Fähigkeit muss vor dem Vertragsabschluss geplant werden, nicht erst im Konfliktfall.

Der EU Data Act verpflichtet Cloud-Anbieter seit September 2025, Wechselprozesse transparent zu gestalten und Egress-Gebühren schrittweise abzubauen[2]. Doch auch ohne regulatorischen Druck brauchen Sie für jeden kritischen Anbieter einen dokumentierten Exit-Plan:

  • Datenexport: Wie kommen Ihre Daten raus? In welchem Format? Wie lange dauert das? Was kostet es?
  • Alternativen: Welcher alternative Anbieter könnte die Funktion übernehmen? Gibt es eine Open-Source-Alternative?
  • Migrationszeitrahmen: Realistische Schätzung — nicht Wochen, sondern typischerweise mehrere Monate bis über ein Jahr für komplexe Systeme
  • Kostenrahmen: Was würde eine Migration kosten? Diese Zahl ist Ihr Verhandlungshebel bei Vertragsgesprächen

Dieser Plan muss nicht perfekt sein. Aber er muss existieren. Ein dokumentierter Exit-Plan verändert die Machtdynamik in Vendor-Verhandlungen fundamental.

Was das für Ihre IT-Strategie bedeutet

  1. Erstellen Sie ein Vendor-Abhängigkeitsregister — für jeden kritischen Anbieter die Art des Lock-ins und geschätzte Wechselkosten dokumentieren
  2. Definieren Sie eine Abstraktionsschicht-Policy: Jede neue Architekturentscheidung muss die Portabilitätsfrage beantworten
  3. Bevorzugen Sie offene Standards und Open-Source-kompatible Lösungen bei Neuanschaffungen
  4. Dokumentieren Sie Exit-Pläne für Ihre Top-5-Anbieter und aktualisieren Sie diese jährlich
  5. Nutzen Sie die Exit-Pläne aktiv als Verhandlungsinstrument — Vendor wissen, dass wechselbereite Kunden bessere Konditionen bekommen
  6. Prüfen Sie die Anforderungen des EU Data Act[2] und fordern Sie von Ihren Cloud-Anbietern transparente Wechselbedingungen ein

Quellen und Referenzen

  1. Gartner: "Gartner Says Cloud Will Be the Centerpiece of New Digital Experiences", Pressemitteilung, November 2021. https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences
  2. Europäische Union: "Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates — Data Act", Amtsblatt der Europäischen Union, 2023. https://eur-lex.europa.eu/eli/reg/2023/2854/oj
  3. Opara-Martins, J. et al.: "Critical Analysis of Vendor Lock-in and Its Impact on Cloud Computing Migration", Journal of Cloud Computing, 2016.
  4. CISPE (Cloud Infrastructure Services Providers in Europe): "Cloud Switching Framework V1.0", CISPE, August 2024. https://cispe.cloud/website_cispe/wp-content/uploads/2024/08/01082024_CISPE_CloudSwitchingFramework-V1.0.pdf
  5. CNCF: "CNCF Annual Survey 2023 — Kubernetes Adoption", Cloud Native Computing Foundation, 2024. https://www.cncf.io/reports/
  6. Bitkom: "Cloud-Monitor 2024 — Cloud Computing im Mittelstand", Bitkom/KPMG, 2024. https://www.bitkom.org/Cloud-Monitor