--- title: "Exit-Strategie & Portabilität" description: "Wie Organisationen Cloud-Lock-in auf STACKIT vermeiden: Open-Standards-Architektur, Datenportabilität, vertragliche Schutzklauseln und die strategischen Vorteile des offenen STACKIT-Ökosystems." sidebar: order: 7 label: "Exit-Strategie" source_url: "https://framework.stackit.cloud/de/advisory/cloud-vision-and-strategy/exit-strategy/" source_file: "docs/de/advisory/cloud-vision-and-strategy/exit-strategy.mdx" --- ## Offene Standards schaffen echte Wahlfreiheit Die stärkste Eigenschaft eines Cloud-Anbieters ist nicht die Tiefe seines Produktportfolios, sondern der Freiraum, den er seinen Kunden lässt. STACKIT baut auf offenen Standards auf — OpenStack, Kubernetes, S3 — nicht weil es technisch verpflichtend ist, sondern weil es die einzige Architektur ist, die langfristige Unabhängigkeit garantiert. Diese Unabhängigkeit ist kein theoretisches Versprechen. Sie ist konkret verankert in jeder Zeile Infrastrukturcode, in jedem Container, in jedem Backup. Wer auf STACKIT baut, baut auf Standards, die kein einzelner Anbieter beherrscht — und die daher auch kein einzelner Anbieter einseitig verändern kann. Die Dokumentation einer Exit-Strategie ist keine Vorbereitung für Misstrauen. Sie ist der Beweis, dass Ihre Architekturentscheidungen fundiert sind. Eine Organisation, die nicht erklären kann, wie sie einen Providerwechsel durchführen würde, hat einen Lock-in, den sie noch nicht bemerkt hat. ## Was Lock-in eigentlich bedeutet Lock-in ist keine binäre Entscheidung. Er entsteht sukzessive über mehrere Dimensionen hinweg. **Technischer Lock-in** entsteht, wenn Anwendungen proprietäre APIs, Datenformate oder Dienste verwenden, die nicht portierbar sind. **Datenbezogener Lock-in** entsteht durch das Volumen. Eine Organisation mit mehreren Petabyte an Daten bei einem Anbieter zahlt erhebliche Gebühren für ausgehenden Traffic, um diese zu verschieben. Manche Anbieter verlangen 8–12 Cent pro GB für den Datenausgang — bei 100 TB sind das 8.000–12.000 Euro für eine einzige Übertragung. **Vertraglicher Lock-in** entsteht durch Laufzeitverträge, Rabattstrukturen (an einen Mindestverbrauch gebundene Nutzungsbindungsrabatte) und Kündigungsfristen. **Kompetenz-Lock-in** entsteht, wenn das interne Team nur eine Plattform kennt. Ein Umzug wäre technisch möglich, aber organisatorisch zu mühsam. ## Warum STACKIT strukturell besser abschneidet STACKIT baut auf offenen Standards auf — nicht aus Marketinggründen, sondern weil die Plattform auf OpenStack, Kubernetes und S3-kompatiblen Schnittstellen basiert. Diese Entscheidung hat direkte Auswirkungen auf die Übertragbarkeit. STACKIT-Instanzen, -Netzwerke und -Storage werden über OpenStack-APIs verwaltet. Für STACKIT geschriebene Terraform-Module können mit minimalem Anpassungsaufwand auf jede andere OpenStack-Umgebung übertragen werden. STACKIT SKE (Managed Kubernetes) implementiert Upstream-Kubernetes ohne proprietäre Erweiterungen. Kubernetes-Workloads laufen auf STACKIT ohne Herstellererweiterungen und sind auf jeden anderen CNCF-zertifizierten Cluster portierbar. STACKIT Object Storage implementiert die S3-API vollständig. Anwendungen, die S3-kompatiblen Storage verwenden, können ohne Codeänderungen nach STACKIT migriert werden — und wieder zurück. Die STACKIT-Datenübertragungspreise sind transparent und regulatorisch kompatibel. Kein verstecktes Preismodell, das die Exit-Kosten künstlich in die Höhe treibt. ## Was eine Exit-Strategie konkret beinhaltet Eine Exit-Strategie ist kein Kündigungsplan. Sie ist ein Dokument, das der Organisation Klarheit darüber gibt, was ein Anbieterwechsel bedeuten würde — und ob die aktuelle Architektur dies ermöglicht. **Bestandteile einer vollständigen Exit-Strategie:** **1. Architekturprüfung auf Portabilität** Welche Dienste nutzen STACKIT-spezifische APIs? Welche basieren auf offenen Standards und sind sofort portierbar? Das Ergebnis ist eine Portabilitätsmatrix, die pro Komponente aufzeigt, wie viel Aufwand ein Wechsel erfordern würde. **2. Datenbestand mit Egress-Berechnung** Wie viele Daten befinden sich auf STACKIT? Wie hoch wären die Transferkosten bei einer Migration? Diese Kennzahl sollte jedem Führungsteam bekannt sein — nicht weil ein Umzug geplant ist, sondern weil sie die eigentliche Verhandlungsposition bestimmt. **3. Vertragliche Schutzklauseln** Was ist vertraglich vereinbart? Gibt es Laufzeitbindungen? Was sind die Kündigungsfristen? Wird der Datenübergabeprozess vertraglich sichergestellt? **4. Migration Runbook (High Level)** Ein grober Plan, wie eine Migration zu einem alternativen Anbieter aussehen würde. Nicht detailliert ausgearbeitet, aber so weit, dass Führungskräfte die Komplexität einschätzen können. **5. Regelmäßige Überprüfung** Die Exit-Strategie sollte jährlich aktualisiert werden — Architekturen entwickeln sich weiter, neue Services kommen hinzu und die Portabilitätsmatrix ändert sich. ## Vertragliche Absicherungen Unabhängig von der technischen Ausgestaltung gibt es Vertragspunkte, die in jedem Cloud-Vertrag angesprochen werden sollten. **Datenrückgabe:** Der Anbieter muss sich vertraglich dazu verpflichten, alle Daten bei Kündigung in einem standardisierten Format zurückzugeben. Typische Formate: SQL-Dumps, CSV-Export, S3-Bucket-Transfer. **Migrationsunterstützung:** Bietet der Provider aktive Unterstützung bei der Datenextraktion an? STACKIT stellt hierzu Dokumentation und technische Unterstützung zur Verfügung. **Datenlöschung:** Nach dem Datenexport muss der Anbieter die Löschung aller Daten schriftlich und nachprüfbar bestätigen. Dies ist für die Einhaltung der DSGVO relevant (Art. 17). **Laufzeit und Kündigung:** Flexible Monatsverträge oder kurze Jahresverträge sind mehrjährigen Bindungen mit hohen Rabattanreizen vorzuziehen. Langfristige Zusagen sollten nur für wirklich und verlässlich geplante Kapazitäten gemacht werden. ## Architekturentscheidungen zur Sicherstellung der Portabilität Die folgenden, von Beginn an umgesetzten Grundsätze minimieren den Lock-in ohne zusätzlichen Aufwand. **Open-Source-first für Middleware:** Kafka statt einer proprietären Message Queue. PostgreSQL anstelle eines reinen Cloud-Datenbankdienstes. Redis statt eines proprietären Caches. Alle laufen auf STACKIT, alle laufen woanders. **Infrastructure-as-Code vom ersten Tag an:** Eine Organisation, die ihre Infrastruktur in Terraform beschreibt, hat eine portierbare Beschreibung — keine Sammlung manueller Konfigurationen, die nirgendwo anders reproduziert werden können. **Container-first für Applikationen:** Containerisierte Applikationen sind per Definition portabel. Sie laufen auf jedem Kubernetes-Cluster, auf jedem Container-Host. **12-Faktor-Anwendungsdesign:** Anwendungen, die Konfiguration aus Umgebungsvariablen lesen und zustandslos sind, können ohne Umschreiben auf neue Infrastruktur übertragen werden. ## STACKIT und Portabilität — eine ehrliche Einschätzung STACKIT bietet einige Managed Services an, die auf anderen Plattformen nicht direkt 1:1 verfügbar sind. Das ist keine STACKIT-Besonderheit — es gilt für jede Managed Database bzw. jeden Managed-Kubernetes-Service. Der Unterschied: Die Schnittstellen sind offen. Ein Managed PostgreSQL auf STACKIT ist nicht dasselbe wie ein selbst gehostetes PostgreSQL-Cluster — aber die Daten und Schemata sind vollständig portierbar, da PostgreSQL ein offener Standard ist. Ein Managed Kubernetes auf STACKIT ist nicht gleichbedeutend mit einem selbst betriebenen Cluster — aber jede darauf ausgeführte Anwendung ist es, denn Kubernetes ist ein offener Standard. **Die Exit-Strategie für STACKIT-Kunden ist strukturell besser als für Kunden proprietärer US-Hyperscaler.** Dies ist kein Versprechen, sondern eine technische Konsequenz der Architekturentscheidungen, auf denen STACKIT aufbaut.