Exit-Strategie nach EU Data Act: Was der Cloud-Wechsel wirklich kostet
Ab 12. Januar 2027 sind Wechselentgelte in der EU verboten. Warum das den Lock-in nicht löst und wie eine Exit-Strategie aussieht, die im Ernstfall trägt.
Seit September 2025 gilt der EU Data Act, und sein Kapitel VI beschäftigt gerade viele IT-Abteilungen. Es regelt, wie Kunden ihren Cloud-Anbieter wechseln können. Ab dem 12. Januar 2027 dürfen Anbieter dafür auch keine Entgelte mehr verlangen.
In Strategiepapieren lesen wir seitdem häufiger, das Thema Lock-in sei damit „regulatorisch gelöst“. Wir halten das für einen Kurzschluss. Der Data Act räumt vertragliche und finanzielle Hürden ab. Die technischen Hürden liegen woanders, und um die kümmert sich keine Verordnung.
Was im Gesetz steht
Die Pflichten treffen alle Anbieter von Datenverarbeitungsdiensten, also IaaS, PaaS und SaaS gleichermaßen. Kunden müssen einen Wechsel mit höchstens zwei Monaten Vorlauf einleiten können (Art. 25 Abs. 2 lit. d). Danach hat der Anbieter 30 Tage Zeit, den Übergang zu unterstützen (lit. a). Hält er das für technisch nicht machbar, muss er das binnen 14 Arbeitstagen begründen und darf eine Frist von höchstens sieben Monaten vorschlagen (Abs. 4). Nach dem Übergang bleiben mindestens 30 Tage, um die eigenen Daten abzurufen (Abs. 2 lit. g).
Bei den Kosten gilt eine Übergangsregel: Bis zum 11. Januar 2027 dürfen Anbieter höchstens ihre direkten Kosten berechnen, ab dem 12. Januar 2027 gar nichts mehr (Art. 29). Eine Ausnahme betrifft alle, die mehrere Anbieter parallel nutzen. Für den Datentransfer zwischen parallel genutzten Diensten bleiben kostendeckende Entgelte erlaubt (Art. 34).
Der Teil, der in der Diskussion oft untergeht, steht in Art. 30. Nur IaaS-Anbieter müssen dazu beitragen, dass ein Dienst beim neuen Anbieter „funktional gleichwertig“ weiterläuft. Für PaaS und SaaS beschränken sich die Pflichten im Wesentlichen auf offene Schnittstellen und Exportformate.
Die Lücke zwischen Export und Betrieb
Übersetzt heißt das: Sie bekommen Ihre Daten heraus. Ob Ihre Anwendung beim nächsten Anbieter läuft, ist Ihr Problem.
Nehmen wir eine typische Fachanwendung, gebaut in den letzten fünf Jahren bei einem großen Hyperscaler. Sie nutzt dessen verwaltete PostgreSQL-Datenbank, eine Message Queue, den Objektspeicher, das Identitätsmanagement und ein paar Serverless-Funktionen für die Schnittstellen. Der Anbieter wird Ihnen nach dem Data Act den Export aller Daten ermöglichen, und zwar kostenlos. Er wird Ihnen aber weder die Queue noch die Serverless-Funktionen noch die IAM-Policies in ein Format übersetzen, das ein anderer Anbieter versteht. Das ist Umbau, und den bezahlen Sie.
Dazu kommt die Physik. Angenommen, die Anwendung hat 50 TB Daten. Über eine 10-Gbit/s-Leitung dauert die reine Übertragung bei voller Auslastung rund elf Stunden (50 × 10¹² Byte × 8 / 10¹⁰ bit/s ≈ 40.000 s). In der Praxis erreicht man selten die volle Bandbreite, die Daten ändern sich während der Migration weiter, und irgendjemand muss am Ende prüfen, ob alles konsistent angekommen ist. Machbar ist das, aber eben nicht „nebenbei“ in einem 30-Tage-Fenster, wenn es vorher nie geübt wurde.
Lock-in ist eine Abwägung
Wir empfehlen nicht, Lock-in um jeden Preis zu vermeiden. Wer jeden verwalteten Dienst meidet, baut Datenbanken, Queues und Monitoring selbst nach und betreibt sie auch selbst. Das kostet Geld und Personal, und es ist nicht automatisch sicherer.
Die sinnvollere Frage lautet: Wo binden wir uns bewusst, und was würde uns der Auszug kosten? Eine verwaltete Datenbank mit Standard-PostgreSQL bindet wenig, denn die Daten lassen sich mit pg_dump oder logischer Replikation umziehen. Eine proprietäre Serverless-Plattform mit anbieterspezifischen Triggern bindet stark. Beides kann die richtige Entscheidung sein. Wichtig ist, dass jemand sie getroffen hat und nicht nur die Bequemlichkeit des ersten Sprints.
Wie wir Exit-Strategien aufbauen
Am Anfang steht eine ehrliche Inventur: welche Anwendung welche anbieterspezifischen Dienste nutzt. Daraus ergibt sich eine grobe Schätzung pro Anwendung, wie viel umgebaut werden müsste und wie viele Daten umziehen. Die Liste ist selten schön, aber sie macht sichtbar, wo ein Exit realistisch ist und wo nicht.
Für die Anwendungen, bei denen es darauf ankommt, ziehen wir eine portable Schicht ein. Kubernetes ist dafür die naheliegende Wahl, weil die API standardisiert und bei allen großen Anbietern verfügbar ist. Unterschiede bleiben trotzdem, vor allem bei Storage-Klassen, Load Balancern und Identitäten. Die kapseln wir in der Plattform, damit die Anwendung sie nicht kennen muss. Die Infrastruktur darunter beschreiben wir mit Terraform, ausgerollt über CI/CD-Pipelines. Eine zweite Umgebung bei einem anderen Anbieter ist dann im Wesentlichen eine weitere Konfiguration im selben Repository.
Die Daten planen wir gesondert: Formate, Replikation, Verschlüsselung, Transferzeiten. Sie sind fast immer der langsamste Teil.
Und dann üben wir den Exit. Regelmäßig, zum Beispiel einmal im Quartal, entsteht aus dem Code eine Umgebung beim zweiten Anbieter, eine Anwendung läuft darauf, und das Team misst, wie lange es gedauert hat und was gehakt hat. Eine Exit-Strategie, die nie geprobt wurde, ist ein Dokument. Mehr nicht.
Banken und Versicherungen haben keine Wahl
Für Finanzunternehmen ist das alles keine Kür. DORA verlangt seit Januar 2025 dokumentierte Exit-Strategien für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen (Art. 28 Abs. 8 der Verordnung (EU) 2022/2554). Der Data Act liefert dafür die vertragliche Seite. Die technische Seite muss die eigene Architektur liefern.
Der Data Act macht den Wechsel billiger. Einfacher macht er ihn nicht. Ob Ihre Anwendungen einen Umzug ohne Neubau überstehen, entscheidet sich in der Architektur, lange bevor jemand die Kündigung schreibt.