Cloud Exit · Portabilität · Anbieterwechsel
Cloud Exit und Anbieterwechsel technisch vorbereiten
Sie wissen erst, ob ein Anbieterwechsel realistisch ist, wenn Sie ihn einmal durchgespielt haben. Wir inventarisieren Ihre Abhängigkeiten, bauen das Ziel als Code auf, testen die Migration und übergeben einen Exit-Plan, den Ihr Team selbst ausführen kann.
- Abhängigkeitsinventar je Dienst
- Zielumgebung als Code
- Testmigration ohne Eingriff in die Produktion
- Exit-Plan für Ihr Team
01Ausgangslage
Ein Ausstieg, den es nur im Vertrag gibt, hilft im Ernstfall nicht
SKAFFON hilft Unternehmen, den Wechsel von einem Cloud-Anbieter zu einem anderen (oder zurück ins eigene Rechenzentrum) technisch beherrschbar zu machen. Gedacht ist das für IT-Leitung, CTOs und Einkauf, die Abhängigkeit abbauen wollen, sei der Wechsel schon beschlossen oder zunächst nur die Fähigkeit dazu gefragt.
Ist der Zielanbieter entschieden und der Wechsel beschlossen, führt die Cloud-Migration ihn aus. Dieses Projekt davor stellt sicher, dass ein Wechsel überhaupt realistisch ist, und liefert die Grundlage.
02Auslöser
Fünf Gründe, warum der Wechsel auf die Agenda kommt
-
Vertrag und Konditionen ändern sich
Vertragsende, Preisänderung oder geänderte Konditionen beim aktuellen Anbieter.
-
Datenstandort und Betreiberkontrolle
Anforderungen, die der aktuelle Anbieter nicht erfüllt, siehe souveräne Cloud.
-
Nachweisbar vorbereiteter Ausstieg
Eine interne oder regulatorische Anforderung, etwa im Rahmen von DORA.
-
Konsolidierung nach Zukäufen
Zwei Cloud-Landschaften sollen zu einer werden.
-
Verhandlungsposition mit Substanz
Eine echte Wechselmöglichkeit statt einer Drohung.
03EU Data Act
Was Kapitel VI des Data Act Anbietern beim Wechsel auferlegt
Kapitel VI der Verordnung (EU) 2023/2854 (Data Act) verpflichtet Anbieter von Datenverarbeitungsdiensten, Hindernisse für den Wechsel zu beseitigen. Die Verordnung gilt ab dem 12. September 2025 (Art. 50). Grundlage ist der Verordnungstext auf EUR-Lex, Stand 13. November 2026.
| Thema | Regel | Fundstelle |
|---|---|---|
| Hindernisse | Wechsel und parallele Nutzung mehrerer Anbieter dürfen nicht durch vorvertragliche, kommerzielle, technische, vertragliche oder organisatorische Hindernisse erschwert werden. | Art. 23 |
| Kündigungsfrist | Der Vertrag regelt eine Frist für die Einleitung des Wechsels von höchstens zwei Monaten. | Art. 25 Abs. 2 Buchst. d |
| Übergangszeitraum | Höchstens 30 Kalendertage; ist das technisch nicht durchführbar, lässt Art. 25 Abs. 4 einen abweichenden Zeitraum von bis zu sieben Monaten zu. | Art. 25 Abs. 2 Buchst. a, Abs. 4 |
| Datenabruf und Löschung | Datenabrufzeit von mindestens 30 Kalendertagen, danach vollständige Löschung der exportierbaren Daten und digitalen Vermögenswerte. | Art. 25 Abs. 2 Buchst. g und h |
| Wechselentgelte | Bis zum 12. Januar 2027 nur ermäßigte Entgelte, die die unmittelbar mit dem Wechsel verbundenen Kosten nicht übersteigen. Ab dem 12. Januar 2027 dürfen keine Wechselentgelte mehr erhoben werden. | Art. 29 |
| Funktionale Gleichwertigkeit | Bei Infrastrukturdiensten (IaaS) alle angemessenen Maßnahmen, damit der Kunde im Zieldienst funktionale Gleichwertigkeit erreichen kann. Das ist eine Pflicht zu angemessenen Maßnahmen, keine Ergebniszusage. | Art. 30 Abs. 1 |
| Paralleler Betrieb | Datenübertragungsentgelte nur in Höhe der tatsächlichen Kosten. | Art. 34 Abs. 2 |
Ob ein konkreter Dienst in den Anwendungsbereich fällt und wie Ihre Verträge im Einzelnen zu bewerten sind, klären Ihre Rechtsabteilung oder Ihre Rechtsberatung; wir liefern die technische Seite.
Ein Exportrecht macht Ihre Daten noch nicht im Zielsystem lauffähig
Ein Recht auf Datenexport ersetzt keine technische Vorbereitung. Ob exportierte Daten im Zielsystem verwendbar sind, entscheidet Ihre Architektur, nicht der Vertrag.
04Exit-Readiness-Matrix
Wie leicht sich welche Abhängigkeit mitnehmen lässt
Die Matrix zeigt, wie wir Abhängigkeitsklassen einordnen. Der Portabilitätsgrad ist eine Einschätzung für die Diskussion im Assessment; Datenmenge, Kompetenz im Team und Termine verschieben ihn.
| Abhängigkeitsklasse | Beispiele | Portabilität | Typische Maßnahme |
|---|---|---|---|
| Virtuelle Maschinen und Standardbetriebssysteme | Anwendungs- und Webserver | Hoch | Neuaufbau per Code, Daten und Konfiguration übertragen |
| Container und Kubernetes | Workloads auf verwaltetem oder eigenem Kubernetes | Hoch bei offenen Standards; anbieterspezifische Annotationen, Storage-Klassen und Load-Balancer-Integrationen prüfen | Manifeste bereinigen, GitOps-Repository auf das neue Cluster ausrichten, siehe Kubernetes-Beratung |
| Relationale Datenbanken auf offener Engine | PostgreSQL | Mittel bis hoch | Logische oder physische Replikation, Cutover mit Synchronisationsfenster, siehe PostgreSQL-Migration |
| Objektspeicher | Zugriff über S3-kompatible Schnittstellen | Mittel | Schnittstellen-Kompatibilität des Ziels an der Dokumentation prüfen, Kopierlauf, Berechtigungs- und Lebenszyklusregeln nachbauen |
| Verwaltete Dienste mit offener Entsprechung | Message-Broker, Cache | Mittel | Entsprechung im Ziel betreiben oder beziehen; Client-Kompatibilität testen |
| Identität und Berechtigungen | Anbieterspezifische IAM-Richtlinien | Gering | Rollenmodell neu entwerfen, siehe IAM und Zero Trust |
| Proprietäre Dienste ohne Entsprechung | Spezialisierte Datenbank-Engines, anbieterspezifische KI- oder Analyse-Dienste | Gering | Ablösung oder Verbleib bewusst entscheiden, Aufwand ausweisen |
| Daten selbst | Datenbestände, Backups, Protokolle | Abhängig von Format und Volumen | Exportformat prüfen, Übertragungsdauer und Entgelte rechnen |
05
Der Weg vom Inventar zum Exit-Plan auf einen Blick
Die Testmigration wird nach der Übergabe in vereinbarten Abständen wiederholt.
06Vorgehen im Projekt
Sieben Schritte von der Bestandsaufnahme bis zur Übergabe
- 01
Bestandsaufnahme und Inventar
Alle genutzten Dienste, Daten und Schnittstellen, einschließlich der Abhängigkeiten zu anbieterspezifischen Funktionen (Identität, Verschlüsselung, Warteschlangen, Funktionen-als-Dienst, proprietäre Datenbank-Engines). Siehe auch Cloud Readiness Assessment.
- 02
Quell- und Zielarchitektur
Pro Abhängigkeit eine Zielentsprechung oder eine begründete Ablösung. Zielumgebung als Code (OpenTofu oder Terraform), aufbauend auf einer Landing Zone.
- 03
Risiken und Abhängigkeiten
Priorisierte Liste mit Eigentümer, getrennt in „lösbar durch Konfiguration“, „lösbar durch Umbau“ und „nicht ohne Funktionsverlust lösbar“.
- 04
Pilot und Testmigration
Ein repräsentativer Workload samt Daten wird vollständig in die Zielumgebung verschoben und dort abgenommen, ohne die Produktion anzufassen.
- 05
Cutover und Rollback
Drehbuch je Anwendung, mit Entscheidungspunkt „weiter oder zurück“.
- 06
Abnahmetests
Funktion, Daten (Vollständigkeit, Konsistenz), Leistung, Berechtigungen, Backup und Wiederherstellung im Ziel.
- 07
Übergabe des Exit-Plans
Reihenfolge, Zuständigkeiten, Dauer aus der Testmigration, Kostenübersicht. Der Plan ist ein lebendes Dokument; wir empfehlen die Testmigration in vereinbarten Abständen zu wiederholen.
07Sicherheit im Umzug
Was während der Migration geschützt bleibt
Ein Exit bewegt Daten und Zugriffe. Diese Grenzen gelten dabei.
- Exportierte Daten sind in Übertragung und Ablage verschlüsselt; Schlüsselhoheit klären wir vor dem Export.
- Zugriffe für die Migration sind befristet und rollenbasiert, Zugangsdaten bleiben bei Ihnen.
- Der Parallelbetrieb erzeugt Kosten und Angriffsfläche; wir planen eine feste Stilllegungsfrist für Quelle und Zwischenablagen.
- Eine Löschbestätigung des Altanbieters ist vertragliche Sache, wir helfen, die technische Löschung zu belegen.
08Startunterlagen
Womit wir in das Inventar einsteigen
- Zugang zu Konten, Architektur-Unterlagen und Infrastruktur-Code; ohne Code dokumentieren wir den Ist-Zustand zunächst aus dem Konto
- Verträge, Laufzeiten, Preislisten des aktuellen Anbieters
- Liste der Anwendungen mit Kritikalität und zulässiger Ausfallzeit beim Wechsel
- Zielvorstellung: konkreter Zielanbieter, Auswahlkriterien oder „offen“
- Datenvolumen und Änderungsrate der Datenbestände
09Zielplattformen
Wohin der Wechsel führen kann
Der Zielort kann ein anderer Hyperscaler, eine europäische Plattform oder die eigene Infrastruktur sein. Wenn Sie zu STACKIT wechseln, kann das separate Produkt StackToIT bei der Vorbereitung helfen. Es ist keine Voraussetzung.
-
AWS
Wechsel zu Amazon Web Services.
-
Azure
Wechsel zu Microsoft Azure.
-
Google Cloud
Wechsel zu Google Cloud.
-
STACKIT
Europäische Plattform als Ziel.
-
Private Cloud
Zurück in die eigene Infrastruktur.
-
Proxmox
Eigene Virtualisierungsplattform als Ziel.
10
Für wen sich ein Exit-Projekt lohnt und wo es nicht greift
Dann lohnt sich das Exit-Projekt
- Sie wollen einen Wechsel technisch vorbereiten, ob beschlossen oder nur als Fähigkeit.
- Es gibt je Anwendung einen Verantwortlichen, der Abnahmekriterien festlegt.
- Sie akzeptieren eine Testmigration als festen Bestandteil.
Dann ist es das falsche Projekt
- Sie suchen eine Rechtsberatung zum Data Act oder zu Ihren Verträgen. Wir liefern die technische Grundlage, keine Rechtsbewertung.
- Ihre Anwendung beruht im Kern auf einem proprietären Dienst ohne Entsprechung, und ein Ersatz kommt nicht in Frage. Dann ist ein Exit keine Portabilitätsaufgabe, sondern eine Produktentscheidung.
- Sie erwarten einen Exit ohne Testmigration oder mit zugesagter Ausfallzeit „null“.
11
Was ein Angebot für den Exit bestimmt
Ein Angebot entsteht nach einer kurzen Bestandsaufnahme, mit Phasen, Ergebnissen und Annahmen. Der Aufwand richtet sich nach den Treibern unten; daraus ergibt sich das Preismodell.
Prüfen wir, wie beweglich Ihre Cloud wirklich ist
Nennen Sie uns aktuellen Anbieter, Auslöser, Zielvorstellung und die wichtigsten Anwendungen.