Cloud-Exit-Strategie — Vendor-Lock-in vermeiden 2026

Vendor-Lock-in galt jahrelang als akademisches Problem — bis 2024 mehrere große europäische Unternehmen mit zweistelligen Millionen-Beträgen aus einem einzelnen Hyperscaler herausmigriert sind und dabei sechs- bis neunmonatige Reengineering-Projekte stemmen mussten. Seit Januar 2025 verlangt DORA von Finanzdienstleistern und Versicherern einen dokumentierten und testbaren Exit-Plan für jeden kritischen Cloud-Anbieter. Die EU-Datenstrategie und der Data Act verstärken diese Pflicht 2026 für weitere Branchen, KRITIS-Betreiber sind über NIS2 ebenfalls erfasst. Für Geschäftsführung, CFO und IT-Leitung ist das kein optionales Architektur-Thema mehr, sondern ein regulatorisches Muss mit persönlicher Haftungsfolge. Dieser Artikel zeigt, was eine wirksame Cloud-Exit-Strategie ausmacht, welche Lock-in-Stufen es gibt, wie ein realistischer Exit-Plan aufgebaut wird, welche Architektur-Entscheidungen den Exit überhaupt erst möglich machen und mit welchen Kosten Sie rechnen müssen. Für die Einordnung in die Gesamtstrategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Warum DORA und EU-Datenstrategie 2026 Cloud-Exit zur Pflicht machen

Die regulatorische Lage hat sich in den letzten 18 Monaten dramatisch verändert. Drei Hebel greifen gleichzeitig und schaffen für einen großen Teil des deutschen Mittelstands eine Pflicht, die noch vor wenigen Jahren nicht existierte.

Erstens DORA — der Digital Operational Resilience Act ist seit dem 17. Januar 2025 unmittelbar geltendes EU-Recht für Banken, Versicherer, Zahlungsdienstleister, Krypto-Anbieter und einen großen Teil des Finanz-Mittelstands. Artikel 28 verlangt für jeden kritischen IKT-Drittdienstleister einen schriftlichen, getesteten Exit-Plan inklusive Übergangs-Architektur. Hyperscaler wie AWS, Azure und Google Cloud sind als kritisch eingestufte Drittdienstleister erfasst, sobald sie zentrale Geschäfts-Funktionen tragen. Die BaFin hat 2025 mehrere Aufsichtsgespräche zu fehlenden Exit-Plänen geführt — die Konsequenz reicht von Auflagen bis zu Sonderprüfungen.

Zweitens die EU-Datenstrategie und der Data Act, der seit September 2025 vollständig anwendbar ist. Artikel 23 bis 31 des Data Act regeln den Anbieter-Wechsel bei Datenverarbeitungsdiensten und verlangen explizit „funktionale Äquivalenz“ und „Switchability“ — ein Wechsel des Cloud-Anbieters muss innerhalb einer zugesagten Frist tatsächlich möglich sein, Daten müssen in einem strukturierten, gängigen, maschinenlesbaren Format herausgegeben werden, Wechsel-Gebühren sind ab 2027 verboten. Für betroffene Unternehmen heißt das: keine Architektur mehr, die einen Wechsel praktisch unmöglich macht.

Drittens KRITIS und NIS2. Betreiber kritischer Infrastrukturen — Energie, Wasser, Gesundheit, Verkehr, Finanzen, Telekommunikation — sind über das BSI-Gesetz und die NIS2-Umsetzung verpflichtet, ihre Abhängigkeiten von einzelnen Dienstleistern zu managen und Resilienz-Konzepte vorzuweisen. Eine reine Single-Cloud-Architektur ohne Exit-Plan ist für KRITIS-Audits nicht mehr akzeptabel.

Operativ kommt eine zweite Welle dazu, die nicht regulatorisch, aber wirtschaftlich entscheidend ist: Cyber-Versicherer fragen Reversibilität inzwischen explizit ab, Lieferanten-Audits großer Industriekunden enthalten Standard-Fragen nach Exit-Plänen, und Investoren bewerten Cloud-Lock-in in Due-Diligence-Prozessen als Risiko-Faktor. Ein Unternehmen ohne Exit-Strategie zahlt höhere Prämien, verliert Aufträge oder bekommt schlechtere Bewertungen.

Die vier Lock-in-Stufen verstehen

„Vendor-Lock-in“ ist kein Schwarz-Weiß-Zustand, sondern verteilt sich über vier eigenständige Dimensionen. Wer Exit plant, ohne diese Stufen zu trennen, plant am Problem vorbei.

Stufe	Was es bedeutet	Typische Symptome
Workload-Lock-in	Anwendungen nutzen proprietäre Services des Anbieters — Lambda, Step Functions, EventBridge, Azure Functions, Cloud Run-spezifische Trigger	Code lässt sich nicht ohne Reengineering auf einer anderen Plattform betreiben
Daten-Lock-in	Daten liegen in proprietären Formaten oder Datenbanken — DynamoDB, Cosmos DB, BigQuery, Aurora-spezifische Features, S3-Glacier-Strukturen	Migration erfordert Export-Transformation-Reimport und Schema-Anpassung, Egress-Kosten sind erheblich
Skill-Lock-in	Das Team kennt nur die Werkzeuge eines Anbieters, alle Automatisierungen sind in vendor-spezifischen CLIs und SDKs geschrieben	Migration scheitert an Re-Skilling und am Aufwand, gewachsene Tooling-Landschaft zu portieren
Contract-Lock-in	Mehrjährige Reserved-Instance-Buchungen, Enterprise-Discount-Programme, Marketplace-Verträge an einen Anbieter gebunden	Kündigung führt zu Restwert-Verlust und zu Konventionalstrafen, Wechsel ist betriebswirtschaftlich unattraktiv

Eine wirksame Exit-Strategie adressiert alle vier Stufen. Aus unserer Beratungs-Praxis ist Workload-Lock-in der häufigste Engpass — viele Mittelständler haben in den letzten Jahren proprietäre Managed Services intensiv genutzt, weil sie kurzfristig produktiver waren. Daten-Lock-in ist der teuerste Engpass, weil Egress-Kosten und Schema-Transformationen schnell sechsstellige Beträge erreichen. Skill-Lock-in ist der unterschätzte Engpass — selbst wenn Architektur portabel ist, scheitert ein Exit, wenn niemand im Team die alternative Plattform betreiben kann. Contract-Lock-in ist der einfachste Engpass — er lässt sich durch kürzere Vertragsläufe und bewusste Begrenzung von Reserved-Buchungen vermeiden.

Welche Services besonders lock-in-trächtig sind

Nicht alle Cloud-Services sind gleich problematisch. Aus Exit-Sicht teilen sich die Angebote der Hyperscaler grob in drei Klassen.

Stark lock-in-trächtig — bewusste Vermeidung empfohlen. Diese Services binden so tief in den Anbieter, dass ein Wechsel monatelanges Reengineering bedeutet.

• Managed AI und ML — SageMaker, Azure ML, Vertex AI, Bedrock mit anbieter-spezifischen Modellen
• Proprietäre Datenbanken — DynamoDB, Cosmos DB, BigQuery, Aurora-spezifische Features, Spanner
• Vendor-Auth — Cognito, Azure AD B2C, Firebase Auth — schwer ersetzbar, weil sie tief in Anwendungs-Logik einsickern
• Serverless mit anbieter-spezifischen Triggern — Lambda mit EventBridge-Patterns, Logic Apps, Cloud Run mit spezifischen Pub/Sub-Bindungen
• Proprietäre Datenanalyse-Stacks — Redshift, Synapse, BigQuery — Migrations-Aufwand erheblich

Moderat lock-in-trächtig — mit Reversibilitäts-Wrapper akzeptabel. Diese Services lassen sich mit überschaubarem Aufwand ersetzen, wenn die Abstraktion sauber gehalten wird.

• Managed Postgres und Managed MySQL — RDS, Azure Database, Cloud SQL — Wechsel auf offene Self-Managed-Variante möglich
• Managed Kubernetes — EKS, AKS, GKE — der Cluster selbst ist portabel, die Add-ons (IAM, Load Balancer) müssen jeweils neu verdrahtet werden
• Objekt-Storage — S3, Blob Storage, Cloud Storage — über die S3-API weitgehend kompatibel, mit Tools wie rclone migrierbar
• Managed Message Queues mit offenen Protokollen — Managed Kafka, RabbitMQ

Gering lock-in-trächtig — bedenkenlos nutzbar. Diese Services sind im Wesentlichen standardisierte Bausteine.

• VMs und Container-Hosting mit OCI-Standard — EC2, Azure VMs, Compute Engine
• Standard-Kubernetes ohne Vendor-spezifische Operatoren
• Standard-Netzwerk-Bausteine — VPCs, Subnets, Load Balancer in Standard-Layer-4/7-Konfiguration

Bausteine eines belastbaren Exit-Plans

Ein Exit-Plan ist kein Word-Dokument, das einmal jährlich vom Wirtschaftsprüfer abgehakt wird, sondern ein lebendes, mehrteiliges Konstrukt aus Inventar, Mapping, Architektur-Entscheidungen und Test-Restores. Die folgenden fünf Bausteine gehören in jeden DORA-konformen Plan.

• Workload-Inventar mit Kritikalitäts-KlassifikationVollständige Liste aller Cloud-Workloads, klassifiziert nach Geschäfts-Kritikalität, Datenschutz-Klasse und Lock-in-Tiefe. Ohne dieses Inventar ist kein Exit planbar — und es ist regelmäßig die größte Lücke in DORA-Prüfungen. Jedes Workload bekommt eine RTO- und RPO-Vorgabe und einen Ziel-Anbieter für den Fall des Exits.
• Daten-Repatriation-PlanFür jeden Daten-Bestand ein dokumentierter Export-Pfad — Format, Werkzeug, geschätzte Dauer, Egress-Kosten. Besonders wichtig: Backup-Daten in proprietären Formaten (S3 Glacier, Azure Archive) brauchen vorab definierte Restore-Pfade, sonst sind sie im Exit-Fall verloren oder verteuern den Exit dramatisch.
• Service-Substitutions-MappingTabelle, die für jeden genutzten proprietären Service eine offene oder anbieter-übergreifende Alternative benennt — Lambda zu OpenFaaS oder Knative, DynamoDB zu Postgres mit JSONB, Cognito zu Keycloak, Aurora zu PostgreSQL mit Patroni. Das Mapping ist die Grundlage für Aufwands-Schätzungen.
• Architektur-Reversibilitäts-PrinzipienSchriftlich festgehaltene Architektur-Regeln, die Lock-in begrenzen — OCI-Container statt vendor-spezifischer Serverless, Postgres statt proprietärer Datenbanken, Kubernetes statt ECS oder Fargate, OIDC-Standard statt Vendor-Auth. Diese Prinzipien gehören in das Architecture Decision Record jeder neuen Anwendung.
• Getesteter Restore in zweite CloudMindestens einmal jährlich wird ein kritisches Workload tatsächlich in einer zweiten Cloud-Umgebung wiederhergestellt — entweder bei einem zweiten Hyperscaler oder bei einem deutschen Anbieter wie OVHcloud, IONOS oder Stackit. Ohne diesen Test ist der Plan nicht DORA-konform und auch nicht belastbar.

Daten-Migrationspfade

Die Daten-Schicht ist der mit Abstand teuerste und langsamste Teil eines Exits. Drei Migrations-Muster haben sich in der Praxis bewährt.

Online-Migration mit Change Data Capture. Geeignet für Datenbanken mit hoher Verfügbarkeits-Anforderung. Tools wie Debezium oder pgAudit replizieren Änderungen in Echtzeit in die Ziel-Datenbank, die nach einem mehrtägigen Sync-Lauf konsistent ist. Der Umschalt-Moment ist eine kurze Lese-Sperre. Vorteil: minimale Downtime. Nachteil: aufwendige Vorbereitung, doppelte Lizenz-Kosten während der Migration.

Snapshot-Restore mit kontrolliertem Cutover. Geeignet für Datenbanken mit planbarer Wartungs-Fenster. Snapshot exportieren, in Ziel-Umgebung wiederherstellen, Cutover mit DNS-Switch oder Load-Balancer-Umstellung. Vorteil: simpel, gut testbar. Nachteil: längere Downtime, typischerweise 2 bis 12 Stunden.

Bulk-Export mit Format-Transformation. Notwendig bei proprietären Datenbanken wie DynamoDB, Cosmos DB oder BigQuery. Export in CSV oder Parquet, Schema-Transformation auf relationale oder dokumentbasierte Ziel-Struktur, Bulk-Import. Vorteil: einzige Option bei tiefem Lock-in. Nachteil: aufwendig, fehleranfällig, deutliche Downtime.

Egress-Kosten sind ein zentraler Posten. Hyperscaler verlangen historisch zwischen 0,02 und 0,09 Euro pro Gigabyte ausgehenden Traffic — bei einem 50-Terabyte-Datenbestand sind das 1.000 bis 4.500 Euro pro Vollexport. Der Data Act schafft hier ab 2027 Erleichterungen, aktuell sind die Kosten aber noch real und gehören in jede Wirtschaftlichkeits-Rechnung.

Architektur-Entscheidungen die Reversibilität sichern

Die wichtigste Erkenntnis aus durchgeführten Exits: Reversibilität wird nicht beim Exit hergestellt, sondern beim Build. Architektur-Entscheidungen, die heute bewusst getroffen werden, bestimmen, ob ein Exit in drei Jahren 200.000 oder 2 Millionen Euro kostet.

Bereich	Lock-in-Variante	Portable Alternative
Compute	Lambda, Azure Functions, Cloud Run mit vendor-spezifischen Triggern	OCI-Container auf Kubernetes oder Knative, mit standardisierten Event-Quellen
Datenbank	Aurora-spezifische Features, DynamoDB, Cosmos DB, BigQuery	PostgreSQL mit Standard-Erweiterungen, Postgres mit JSONB statt NoSQL, ClickHouse für Analytics
Container-Orchestrierung	ECS, Fargate, Azure Container Apps	Standard-Kubernetes (EKS, AKS, GKE oder Self-Managed) mit gleichen Manifests
Identität	Cognito, Azure AD B2C, Firebase Auth	Keycloak oder Authentik, OIDC-Standard, portabel zwischen Clouds
Messaging	EventBridge, Azure Service Bus mit proprietären Filtern	Apache Kafka, NATS, RabbitMQ
Infrastructure-as-Code	CloudFormation, ARM Templates, Deployment Manager	Terraform oder OpenTofu mit anbieter-übergreifenden Modulen

Die portable Architektur kostet typischerweise 5 bis 15 Prozent mehr Betrieb als die voll auf einen Anbieter zugeschnittene Variante — eigene Datenbank-Betriebs-Verantwortung, Self-Managed Authentication, eigenes Kafka-Cluster statt Managed Eventing. Diese Mehrkosten sind die Versicherungsprämie für Reversibilität. Detaillierter zu den IaC-Entscheidungen siehe unseren Cluster zu Terraform IaC Best Practices, zur grundsätzlichen Anbieter-Wahl unseren Vergleich AWS vs. Azure vs. GCP und zur Multi-Cloud-Diskussion Multi-Cloud vs. Single-Cloud.

Vertrags-Klauseln die in jedem Cloud-Vertrag stehen sollten

Die rechtliche Seite des Exits wird in vielen Mittelstands-Verträgen unterschätzt — Standard-AGB der Hyperscaler sind nicht DORA-konform und enthalten keine ausreichenden Exit-Garantien. Mindestens fünf Klauseln gehören in jedes Verhandlungs-Mandat.

• Daten-Repatriation in offenem Format. Vertraglich zugesichertes Recht, alle Kundendaten in einem strukturierten, gängigen, maschinenlesbaren Format zu exportieren — ohne Zusatzkosten, mit ausreichender Bandbreite, in einem definierten Zeitfenster.
• Garantierte Exit-Frist. Mindestens sechs Monate Übergangs-Phase ab Kündigung, in denen Daten und Services weiter verfügbar bleiben — DORA verlangt 12 Monate für kritische Dienste.
• Daten-Löschung mit Nachweis. Vollständige, dokumentierte Löschung aller Daten nach Exit-Abschluss mit schriftlicher Bestätigung — relevant für DSGVO und für Lieferanten-Audits.
• Service-Abkündigungs-Vorlauf. Pflicht zur Vorab-Information bei Abkündigung oder größeren Preis-Erhöhungen mit ausreichendem Vorlauf — typisch 12 bis 24 Monate für kritische Services.
• Audit- und Subunternehmer-Transparenz. Zugriff auf Audit-Reports (SOC 2, ISO 27001), Offenlegung aller Subunternehmer und ihrer Standorte, Pflicht zur Information bei Subunternehmer-Wechseln — DORA verlangt das explizit.

Den Exit testen — sonst existiert er nicht

Der größte Unterschied zwischen einem Word-Dokument-Exit-Plan und einem belastbaren Exit-Plan ist der Test. DORA verlangt explizit, dass Exit-Pläne regelmäßig „getestet, überprüft und aktualisiert“ werden — und die BaFin liest das ernst. In der Praxis bedeutet das mindestens einen jährlichen Exit-Test mit einer dieser drei Tiefen.

Tier-1: Tabletop-Übung. Geschäftsführung und IT-Leitung gehen den Exit-Plan in einem mehrstündigen Workshop durch — wer macht was, wann, mit welchen Werkzeugen. Aufwand: 1 bis 2 Personentage. Nutzen: deckt Lücken im Plan auf, validiert Zuständigkeiten. Reicht für niedrige Kritikalität.

Tier-2: Partielles Restore eines Workloads. Ein nicht-kritisches Workload wird tatsächlich in der zweiten Cloud wiederhergestellt — End-to-End, mit Daten und Anwendungs-Schicht. Aufwand: 5 bis 15 Personentage. Nutzen: validiert Daten-Pfade und Architektur-Annahmen. Standard für DORA-konforme Programme.

Tier-3: Vollständige Failover-Übung mit Last. Ein kritisches Workload wird vollständig in der zweiten Cloud betrieben, inklusive Produktiv-Last und Cutover. Aufwand: 20 bis 60 Personentage. Nutzen: validiert wirklichen Exit-Pfad inklusive Performance und Kosten. Empfohlen alle zwei bis drei Jahre für KRITIS- und DORA-Pflichtige.

Was kostet ein echter Cloud-Exit?

Die Kosten eines vollständigen Cloud-Exits hängen stark von Lock-in-Tiefe, Daten-Volumen und Zeitdruck ab. Die folgende Tabelle zeigt typische Spannen für mittelständische Unternehmen — sie ist als Orientierung gedacht, präzise Schätzungen brauchen einen Inventar-Workshop.

Exit-Szenario	Einmal-Kosten gesamt	Dauer	Personentage extern
Container- und Postgres-Stack ohne proprietäre Services (50–200 MA)	120.000–280.000 €	6–9 Monate	60–140
Standard-Mix mit moderater Managed-Service-Nutzung (200–500 MA)	280.000–620.000 €	9–15 Monate	140–320
Tiefer Lock-in mit Serverless und proprietären DBs (500–1.500 MA)	620.000–1.400.000 €	15–24 Monate	320–700
Reine Reversibilitäts-Vorbereitung ohne tatsächlichen Exit	40.000–120.000 €	3–6 Monate	20–60

Hauptkostenposten sind das Reengineering proprietärer Services, der Parallel-Betrieb während der Migration, Daten-Egress-Gebühren, externe Beratung und das interne Personal. Die laufenden Mehrkosten einer portablen Architektur gegenüber einer voll auf einen Anbieter zugeschnittenen Variante liegen bei rund 5 bis 15 Prozent Betriebskosten. Das ist die Versicherungsprämie für Reversibilität — und sie ist im Vergleich zu den Einmal-Kosten eines ungeplanten Exits unter Druck immer die günstigere Variante.

Reepa Cloud-Exit-Audit

Wir bieten ein strukturiertes Cloud-Exit-Audit, das in drei bis sechs Wochen die DORA- und Data-Act-Konformität Ihrer aktuellen Cloud-Architektur bewertet. Der Audit umfasst ein vollständiges Workload-Inventar mit Lock-in-Klassifikation, ein Service-Substitutions-Mapping, eine Bewertung der bestehenden Verträge gegen die fünf zentralen Klauseln, einen schriftlichen Exit-Plan in DORA-konformer Struktur und einen einseitigen Geschäftsführungs-Bericht mit Risiko-Bewertung und Aufwands-Schätzung. Optional führen wir den ersten Tier-2-Test in einer zweiten Cloud durch.

Häufige Fragen