Der EU-Data-Act verbessert die regulatorischen Voraussetzungen für einen Wechsel zwischen Cloud-Anbietern. Ob ein Cloud-Exit in der Praxis gelingt, entscheidet sich jedoch nicht an Vertragsbedingungen. Erfolgreiche Migrationen setzen voraus, dass Backup, Sicherheit und Prozesse auf einer neuen Plattform funktionieren.

Cloud-Portabilität entwickelt sich von einer technischen Migrationsaufgabe zu einer strategischen Disziplin der Enterprise Architecture. Im ersten Teil unserer Serie zum EU Data Act haben wir gezeigt, warum regulatorische Erleichterungen und der Wegfall von Wechselgebühren allein noch keine Cloud-Portabilität schaffen. Entscheidend sind die Architektur der Anwendungen und ihre technischen Abhängigkeiten. Teil II richtet den Blick nun auf die praktische Umsetzung: Welche technischen, betrieblichen und organisatorischen Voraussetzungen müssen Unternehmen für einen kontrollierten Cloud-Exit schaffen?

Cloud-Migrationen werden häufig mit dem eigentlichen Plattformwechsel gleichgesetzt. Tatsächlich beginnt ein erfolgreicher Cloud-Exit jedoch lange bevor die ersten Daten übertragen oder Anwendungen auf einer Zielplattform bereitgestellt werden. Maßgeblich ist, ob Unternehmen ihre IT-Landschaft so aufgebaut haben, dass sich geschäftskritische Workloads mit vertretbarem Aufwand verlagern und anschließend zuverlässig weiterbetreiben lassen.

Daten-Exit ist noch kein Cloud-Exit

In der Praxis konzentrieren sich viele Exit-Strategien zunächst auf den Datenexport. Diese Sichtweise greift jedoch zu kurz. Ein produktiver Cloud-Service besteht nicht allein aus Daten oder virtuellen Maschinen. Erst das Zusammenspiel aus Infrastruktur, Sicherheitsmechanismen, Identitäten, Automatisierung und Betriebsprozessen macht eine Anwendung tatsächlich produktionsfähig.

Genau darin unterscheidet sich ein Cloud-Exit von klassischen Migrationsprojekten. Ziel ist nicht lediglich die Übertragung einzelner Systeme, sondern die Wiederherstellung eines vollständigen Betriebsmodells auf einer anderen Plattform – einschließlich aller technischen und organisatorischen Abhängigkeiten.

Cloud-Portabilität endet nicht beim Datenexport. Recovery, Monitoring, Exit-Tests und Enterprise Architecture entscheiden darüber, ob ein Cloud-Exit tatsächlich gelingt. (Bild: speicherguide.de via DALL-E)

Backup schützt Daten – ersetzt aber keinen Exit-Plan

Diese Unterschiede zeigen sich besonders deutlich beim Thema Datensicherung. Viele Unternehmen setzen ihre Backup-Strategie mit einer Exit-Strategie gleich. Beide verfolgen jedoch unterschiedliche Ziele.

Ein Backup dient in erster Linie dazu, Daten nach einem Ausfall oder einer Cyberattacke wiederherzustellen. Ein Cloud-Exit muss dagegen nachweisen, dass eine komplette Betriebsumgebung unter den definierten Sicherheits-, Verfügbarkeits- und Compliance-Anforderungen auf einer alternativen Infrastruktur erneut produktiv betrieben werden kann.

Dafür reicht weder ein Datenbank-Dump noch der Snapshot einer virtuellen Maschine aus. Ebenso berücksichtigt werden müssen Infrastrukturdefinitionen, Netzwerkkonfigurationen, Identitäten, Zertifikate, Secrets, Automatisierungsprozesse und betriebliche Runbooks.

Besonders anspruchsvoll sind Cloud-Architekturen, die konsequent auf native Backup-Dienste eines Hyperscalers setzen. Snapshots, Immutable Storage oder Archivdienste bieten zwar ein hohes Schutzniveau gegen Ransomware und Fehlbedienungen, basieren jedoch häufig auf proprietären Schnittstellen oder cloudinternem Schlüsselmanagement. Ein vorhandenes Backup garantiert deshalb noch keine Wiederherstellung außerhalb der ursprünglichen Plattform.

Damit wird deutlich: Datensicherung ist eine wesentliche Voraussetzung für einen Cloud-Exit – sie ersetzt ihn jedoch nicht. Entscheidend ist, ob sich aus den gesicherten Daten und Konfigurationen ein vollständiger Geschäftsbetrieb innerhalb der geforderten Wiederanlaufzeiten tatsächlich rekonstruieren lässt.Ein Cloud-Exit umfasst weit mehr als den Datenexport: Erst Backup, Identitäten, Security, Monitoring und Betriebsprozesse machen Workloads wirklich portabel. (Bild: speicherguide.de via DALL-E)

Monitoring und Security müssen den Plattformwechsel begleiten

Ein erfolgreicher Cloud-Exit endet nicht mit dem Start der Anwendungen auf der Zielplattform. Ebenso wichtig ist, dass Überwachung, Sicherheitsmechanismen und Betriebsprozesse vom ersten Moment an wieder vollständig funktionieren.

In vielen Migrationsprojekten liegt der Fokus zunächst auf Datenkonsistenz und Anwendungsverfügbarkeit. Ob Logging, Telemetrie und Alarmierung nach dem Cutover dieselbe Transparenz bieten wie zuvor, wird dagegen häufig erst im laufenden Betrieb überprüft. Gerade in dieser Phase entstehen jedoch erhebliche Risiken.

Fehlen Performance-Metriken oder zentrale Logdaten, lassen sich Konfigurationsfehler, Sicherheitsvorfälle oder unerwartete Leistungsengpässe oftmals nur eingeschränkt erkennen. Besonders kritisch wird dies, wenn SIEM-Plattformen, Detection-Regeln oder Incident-Response-Prozesse weiterhin auf die ursprüngliche Cloud-Umgebung zugeschnitten sind.

Ein Cloud-Exit kann deshalb erst dann als erfolgreich gelten, wenn die operative Überwachung auf der Zielplattform dieselbe Transparenz und Reaktionsfähigkeit bietet wie zuvor. Dazu gehören neben Monitoring und Logging auch Audit-Daten, Compliance-Nachweise sowie Sicherheitsprotokolle, die insbesondere im Umfeld von NIS2, DORA oder branchenspezifischen Regulierungen revisionssicher verfügbar bleiben müssen.

Ohne vollständige Transparenz wird jede Migration zum Risiko

Eine erfolgreiche Migration beginnt deshalb nicht erst mit dem eigentlichen Projekt, sondern mit einer umfassenden Bestandsaufnahme der bestehenden Cloud-Landschaft.

Viele Unternehmen kennen ihre produktiven Anwendungen sehr genau. Deutlich schwieriger fällt dagegen der vollständige Überblick über alle tatsächlich genutzten Plattformdienste, proprietären APIs, Sicherheitsfunktionen oder Automatisierungsprozesse, die im Laufe der Jahre entstanden sind.

Gerade in Hybrid-Cloud- und Multi-Cloud-Umgebungen wachsen solche Abhängigkeiten schrittweise. Solange der Betrieb stabil läuft, bleiben sie häufig unsichtbar. Erst wenn ein Plattformwechsel vorbereitet wird, zeigt sich, wie eng Anwendungen, Identitäten, Netzwerkarchitekturen und Sicherheitsmechanismen miteinander verflochten sind.

Aus diesem Grund gewinnt eine strukturierte »Exit-Landkarte« zunehmend an Bedeutung. Sie dokumentiert nicht nur Datenbestände, sondern sämtliche technischen und organisatorischen Abhängigkeiten eines produktiven Workloads. Dazu gehören eingesetzte Plattformdienste, Identitätsmodelle, Verschlüsselungsverfahren, Netzwerkkonzepte, Backup-Strategien sowie Betriebs- und Automatisierungsprozesse.

Erst diese Transparenz ermöglicht eine belastbare Bewertung der tatsächlichen Exit-Fähigkeit. In vielen Projekten zeigt sich dabei, dass nicht die Datenmigration den größten Aufwand verursacht, sondern die Vielzahl kleiner technischer Abhängigkeiten, die sich über Jahre angesammelt haben.

Ein kontrollierter Cloud-Exit erfolgt schrittweise – von der Bestandsaufnahme über Tests und Parallelbetrieb bis zum sicheren Wechsel auf die Zielplattform. (Bild: speicherguide.de via DALL-E)

Nicht jeder Workload muss portabel sein

Aus der Exit-Landkarte ergibt sich gleichzeitig eine realistische Bewertung der eigenen Anwendungen. Denn nicht jeder Workload muss oder sollte mit vertretbarem Aufwand auf eine andere Plattform migriert werden können.

Portable Workloads basieren überwiegend auf standardisierten Technologien und lassen sich vergleichsweise einfach übertragen. Deutlich komplexer wird es bei Anwendungen, die umfangreiche cloudnative Dienste wie Managed Databases, Identity Services oder proprietäre Netzwerkfunktionen nutzen.

Eine besondere Kategorie bilden strategisch gebundene Workloads. Hierzu zählen beispielsweise KI-Plattformen, umfangreiche Analytics-Umgebungen oder spezialisierte Sicherheitsdienste, die tief in das Ökosystem eines Hyperscalers integriert sind. Ihre Ablösung entspricht häufig keiner klassischen Migration mehr, sondern einer umfassenden »Replattformisierung« oder sogar einer funktionalen Neuentwicklung.

Gerade diese Differenzierung verhindert unrealistische Erwartungen hinsichtlich Projektlaufzeiten, Budgets und Ressourcen. Ziel einer Cloud-Strategie muss daher nicht sein, jede Anwendung kurzfristig portabel zu machen. Entscheidend ist vielmehr, die kritischen Systeme zu kennen, ihre Abhängigkeiten transparent zu dokumentieren und deren Auswirkungen bewusst zu bewerten.

Recovery-Tests entscheiden über die tatsächliche Exit-Fähigkeit

Ein dokumentierter Exit-Plan allein beweist noch keine Cloud-Portabilität. Entscheidend ist, ob sich geschäftskritische Anwendungen unter realen Bedingungen innerhalb der geforderten Zeit tatsächlich wieder produktiv betreiben lassen.

Der eigentliche Härtetest beginnt deshalb erst nach der Migration. Anwendungen müssen nicht nur starten, sondern auch mit denselben Sicherheits-, Verfügbarkeits- und Compliance-Anforderungen arbeiten wie zuvor. Authentifizierung, Autorisierung, Zertifikate, Secrets, Schlüsselmanagement, Monitoring und externe Schnittstellen müssen vom ersten Moment an zuverlässig funktionieren.

Aus diesem Grund unterscheiden sich Exit-Tests grundlegend von klassischen Backup- oder Restore-Tests. Während diese primär den Datenbestand überprüfen, weisen Recovery-Tests nach, dass eine vollständige Betriebsumgebung unter produktiven Bedingungen wieder funktionsfähig ist.

Parallelbetrieb reduziert Risiken

Die Vorstellung eines kurzfristigen »Big Bang«-Wechsels entspricht deshalb nur selten der Realität.

In der Praxis setzen Unternehmen zunehmend auf schrittweise Migrationsverfahren. Daten werden kontinuierlich repliziert, Zielplattformen parallel aufgebaut und Anwendungen mehrfach getestet, bevor einzelne Dienste kontrolliert umgeschaltet werden. Quell- und Zielumgebung existieren dabei häufig über Wochen oder Monate nebeneinander.

Diese Vorgehensweise verursacht zwar zunächst höhere Betriebs- und Infrastrukturkosten, reduziert jedoch das Risiko ungeplanter Ausfälle erheblich. Gerade in regulierten Branchen hat sich der Parallelbetrieb deshalb längst als bevorzugte Migrationsstrategie etabliert.

Cloud-Portabilität wird zur Aufgabe der Enterprise Architecture

Mit zunehmender Cloud-Nutzung verändert sich auch die Verantwortung innerhalb der Unternehmen. Cloud-Portabilität ist heute keine reine Infrastruktur- oder Betriebsaufgabe mehr. Sie entwickelt sich zu einem festen Bestandteil moderner Enterprise Architecture und IT-Governance.

Architektur, Informationssicherheit, Compliance, Einkauf und Risikomanagement müssen gemeinsam bewerten, welche Plattformdienste eingesetzt werden, welche technischen Abhängigkeiten dadurch entstehen und welche Auswirkungen diese langfristig auf die Handlungsfähigkeit des Unternehmens haben.

Neue Anwendungen sollten deshalb bereits in der Planungsphase hinsichtlich ihrer Portabilität bewertet werden. Dabei geht es nicht darum, jede Form von Vendor Lock-in zu vermeiden. Viel wichtiger ist die bewusste Entscheidung, welche Abhängigkeiten strategisch sinnvoll sind und welche künftig Risiken für Flexibilität oder Resilienz darstellen könnten.

Cloud-Portabilität wird zur strategischen Daueraufgabe

Der EU-Data-Act verbessert die regulatorischen Voraussetzungen für einen Anbieterwechsel und stärkt den Wettbewerb im europäischen Cloud-Markt. Die eigentliche Herausforderung bleibt jedoch technischer Natur.

Ein erfolgreicher Cloud-Exit beginnt weder mit der Kündigung eines Vertrags noch endet er beim Export von Daten. Er setzt voraus, dass Anwendungen, Identitäten, Sicherheitsmechanismen, Monitoring und Betriebsprozesse auf einer alternativen Plattform mit derselben Zuverlässigkeit weiterbetrieben werden können.

Die größte Wirkung des EU-Data-Act dürfte deshalb weniger in einer kurzfristigen Welle von Cloud-Migrationen liegen als in einem grundlegenden Wandel der Architekturplanung. Cloud-Portabilität entwickelt sich zunehmend zu einem festen Bewertungskriterium moderner IT-Architekturen – neben Leistung, Skalierbarkeit, Sicherheit und Wirtschaftlichkeit.

Anmerkung der Redaktion:

Michael Baumann, speicherguide.deDigitale Souveränität leicht überschätzt – und braucht mehr Architektur als Symbolpolitik

Die Debatte über digitale Souveränität konzentriert sich häufig auf den möglichst einfachen Wechsel zwischen Cloud-Anbietern. Das greift zu kurz. Entscheidend ist weniger, ob ein Unternehmen den Provider wechseln darf, sondern ob es seine geschäftskritischen Anwendungen unter realen Bedingungen auf einer anderen Plattform betreiben kann.

Vollständige Portabilität ist dabei nicht zwangsläufig das wirtschaftlich sinnvollste Ziel. Hyperscaler bieten hochintegrierte Dienste für Datenanalyse, Künstliche Intelligenz, Automatisierung und Sicherheit, die Unternehmen bewusst nutzen, um Innovationen schneller umzusetzen. Solche Entscheidungen schaffen Abhängigkeiten – sie sind jedoch nicht automatisch problematisch.

Die eigentliche Herausforderung besteht darin, zwischen strategisch gewollten Bindungen und ungewolltem Vendor Lock-in zu unterscheiden. Moderne Cloud-Strategien müssen deshalb nicht maximale Unabhängigkeit anstreben, sondern Transparenz über bestehende Abhängigkeiten schaffen und deren Auswirkungen beherrschbar halten.

Vielleicht sollte sich die Diskussion künftig weniger um den schnellen Cloud-Exit drehen als um die Qualität der zugrunde liegenden Architektur. Digitale Souveränität entsteht nicht durch den Verzicht auf Plattformdienste, sondern durch die Fähigkeit, ihre Folgen zu kennen und bei Bedarf kontrolliert handeln zu können.

Genau darin liegt die eigentliche strategische Konsequenz des EU-Data-Act: Nicht der Anbieterwechsel wird zur Daueraufgabe, sondern der Aufbau von Cloud-Architekturen, die auch unter veränderten technologischen, regulatorischen und geopolitischen Rahmenbedingungen dauerhaft handlungsfähig bleiben.