EU Data Act 2027 (II): Cloud-Migration in der Praxis

Backup, Monitoring und Security entscheiden über den Erfolg einer Migration

Der EU Data Act erleichtert künftig den Wechsel zwischen Cloud-Anbietern. Für Unternehmen bleiben Exit und Migration dennoch ein komplexes Infrastrukturprojekt. Entscheidend sind nicht nur Datenexport und Vertragsbedingungen, sondern Backup, Identitäten, Monitoring und eine Architektur, die den Wechsel überhaupt ermöglicht.

Viele Exit-Strategien beginnen mit der Frage, wie sich Daten möglichst schnell exportieren lassen. Diese Perspektive greift jedoch zu kurz. Ein produktiver Cloud-Service besteht nicht allein aus Daten oder virtuellen Maschinen. Erst das Zusammenspiel von Backup, Monitoring, Sicherheitsmechanismen und Betriebsprozessen macht einen Dienst tatsächlich betriebsfähig.

Viele Unternehmen setzen ihre Backup-Strategie mit einem Exit-Plan gleich. Tatsächlich verfolgen beide Konzepte unterschiedliche Ziele. Ein Backup schützt vor Datenverlust. Ein Cloud-Exit muss dagegen nachweisen, dass ein vollständiger Geschäftsbetrieb auf einer alternativen Plattform wieder aufgenommen werden kann.

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

Besonders anspruchsvoll sind 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 APIs oder cloudinternem Schlüsselmanagement. Ein vorhandenes Backup garantiert deshalb noch keine Wiederherstellung außerhalb der ursprünglichen Cloud-Plattform.

Ohne Monitoring fehlt nach der Migration die Transparenz

Ebenso häufig unterschätzt werden Monitoring und Security Operations. Während einer Migration konzentrieren sich viele Projekte zunächst auf Datenkonsistenz und Anwendungsverfügbarkeit. Ob Logging, Telemetrie und Alarmierung unmittelbar nach dem Cutover vollständig funktionieren, wird dagegen oft erst später überprüft.

Gerade in den ersten Stunden nach einer Migration entsteht dadurch eine kritische Phase eingeschränkter Transparenz. Fehlen Performance-Metriken oder zentrale Logdaten, lassen sich Konfigurationsfehler und Sicherheitsvorfälle nur eingeschränkt erkennen. Besonders problematisch wird dies, wenn SIEM-Plattformen, Detection-Regeln oder Incident-Response-Prozesse weiterhin ausschließlich auf die ursprüngliche Cloud-Umgebung ausgerichtet sind.

Ein Cloud-Exit gilt deshalb erst dann als erfolgreich, wenn der operative Betrieb vom ersten Moment an mit derselben Transparenz überwacht werden kann wie zuvor.

Auch Audit- und Compliance-Daten gehören in eine Exit-Strategie. Unternehmen müssen sicherstellen, dass Protokolle, Sicherheitsereignisse und Nachweise auch nach einer Migration vollständig und revisionssicher verfügbar bleiben. Gerade im Umfeld von NIS2, DORA oder branchenspezifischen Vorgaben reicht es nicht aus, lediglich produktive Anwendungen wiederherzustellen.

Exit-Fähigkeit beginnt lange vor der Migration

Ein Cloud-Exit lässt sich nicht erst während eines Migrationsprojekts planen. Er muss bereits im laufenden Betrieb vorbereitet werden.

Der wichtigste Schritt besteht darin, Transparenz über die eigene Cloud-Landschaft herzustellen. Viele Unternehmen kennen ihre produktiven Anwendungen, verfügen jedoch nicht über einen vollständigen Überblick darüber, welche Plattformdienste tatsächlich genutzt werden oder welche Sicherheitsfunktionen und APIs unmittelbar an einen bestimmten Hyperscaler gebunden sind.

Gerade in gewachsenen Hybrid-Cloud- und Multi-Cloud-Umgebungen entstehen über Jahre technische Abhängigkeiten, die im Alltag kaum sichtbar sind. Erst wenn eine Migration vorbereitet wird, zeigt sich, wie eng Anwendungen, Identitäten und Betriebsprozesse miteinander verflochten sind.

Ohne Exit-Landkarte bleibt jede Migration ein Risiko

Während Notfall- und Disaster-Recovery-Pläne in vielen Unternehmen etabliert sind, fehlt häufig eine strukturierte Exit-Landkarte.

Sie dokumentiert nicht nur exportierbare Daten, sondern sämtliche technischen und organisatorischen Abhängigkeiten eines produktiven Workloads. Dazu gehören unter anderem eingesetzte Plattformdienste, proprietäre APIs, Identitäten, Schlüsselmanagement, Netzwerkarchitekturen und cloudnative Betriebsprozesse.

Erst diese Transparenz ermöglicht eine realistische Bewertung der tatsächlichen Exit-Fähigkeit. In der Praxis zeigt sich dabei häufig, dass nicht die Daten den größten Migrationsaufwand verursachen, sondern die Vielzahl kleiner technischer Abhängigkeiten, die sich über Jahre angesammelt haben.

Nicht jeder Workload muss portabel sein

Ebenso wichtig ist eine realistische Bewertung der einzelnen Anwendungen. Nicht jeder Workload lässt sich mit vertretbarem Aufwand migrieren.

Portable Workloads basieren überwiegend auf Standardtechnologien und lassen sich vergleichsweise einfach auf alternative Plattformen übertragen. Schwieriger wird es bei Anwendungen, die zusätzlich cloudnative Dienste wie Managed Databases, Identity Services oder proprietäre Netzwerkfunktionen nutzen.

Eine dritte Gruppe bilden strategisch gebundene Workloads. Hierzu zählen beispielsweise KI-Plattformen, umfangreiche Analytics-Dienste oder spezialisierte Sicherheitsfunktionen, 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 Unterscheidung verhindert unrealistische Erwartungen an Zeitpläne und Projektbudgets. Nicht jeder Workload muss kurzfristig portabel werden. Entscheidend ist vielmehr, dass Unternehmen ihre kritischen Systeme kennen und deren Abhängigkeiten bewusst bewerten.

Exit beginnt nicht beim Vertrag, Migration endet nicht beim Daten-Export

Der EU Data Act verbessert die regulatorischen Rahmenbedingungen für einen Anbieterwechsel. Die eigentliche Herausforderung bleibt jedoch technischer Natur.

Ein erfolgreicher Cloud-Exit endet nicht beim Export von Daten und beginnt auch nicht mit der Kündigung eines Vertrags. Er setzt voraus, dass Backup, Identitäten, Monitoring, Schlüsselmanagement und Betriebsprozesse auf einer alternativen Plattform ebenso zuverlässig funktionieren wie in der bisherigen Umgebung.

Cloud-Souveränität entsteht deshalb nicht allein durch die Möglichkeit eines Providerwechsels. Sie beruht auf der Fähigkeit, geschäftskritische Dienste kontrolliert, sicher und nachvollziehbar auf einer anderen Infrastruktur betreiben zu können.

Ausblick: Wird digitale Souveränität überschätzt?

Im dritten und letzten Teil der Serie geht es um die strategischen und operativen Konsequenzen eines Cloud-Exits. Im Mittelpunkt stehen Recovery-Tests, Parallelbetrieb, RTO- und RPO-Ziele sowie die Frage, wie Unternehmen Cloud-Portabilität dauerhaft nachweisen können. Außerdem beleuchten wir, ob die öffentliche Debatte digitale Souveränität überschätzt – und die Bedeutung einer vorausschauenden IT-Architektur unterschätzt.