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. Laut Gartner sind über 70 % der Unternehmen, die Public-Cloud-Services nutzen, in mindestens einer Dimension von ihrem Provider abhängig[1]. 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 ab 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 Ausstiegspensionen, automatische Verlängerungen, Mindestabnahmemengen
  • Daten-Lock-in: Hohe Egress-Gebühren für Datentransfer, proprietäre Speicherformate, fehlende Exportfunktionen. CISPE (Cloud Infrastructure Services Providers in Europe) dokumentiert, dass Egress-Gebühren bei Hyperscalern bis zum Fünffachen der Ingress-Kosten betragen können[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[5]:

  • 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[6]
  • 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 prognostiziert, dass bis 2025 über 85 % der Unternehmen einen Cloud-First-Ansatz verfolgen, aber weniger als 10 % echte Workload-Portabilität zwischen Providern erreichen[1]:

  • 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

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 ab 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 Monate für komplexe Systeme. Laut einer IDC-Studie dauert eine vollständige Cloud-Migration im Mittelstand durchschnittlich 6–12 Monate[7]
  • 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: "Cloud Lock-In and How to Avoid It", Gartner Research, 2023.
  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): "Switching Cloud Providers — An Analysis of Barriers and Recommendations", CISPE White Paper, 2023. https://cispe.cloud
  5. Open Source Initiative / CNCF: "Open Standards for Cloud Portability", Cloud Native Computing Foundation, 2024.
  6. CNCF: "CNCF Annual Survey 2023 — Kubernetes Adoption", Cloud Native Computing Foundation, 2024. https://www.cncf.io/reports/
  7. IDC: "Cloud Migration Strategies for Midsize Enterprises in Europe", IDC Market Analysis, 2024.
  8. Bitkom: "Cloud-Monitor 2024 — Cloud Computing im Mittelstand", Bitkom/KPMG, 2024. https://www.bitkom.org/Cloud-Monitor