EU Data Act 2027 (III): Strategische Konsequenzen für Unternehmen

Cloud-Portabilität wird zur Daueraufgabe

Die ersten beiden Teile der Serie behandelten die regulatorischen Grundlagen des EU Data Act sowie die technischen Herausforderungen und die praktische Umsetzung eines Cloud-Exits. Im dritten und letzten Teil der Serie stehen Governance und die strategischen Konsequenzen für die Cloud-Architektur im Mittelpunkt.

Exit-Pläne sind wertlos, wenn sie nie getestet wurden

Viele Unternehmen verfügen heute über dokumentierte Konzepte für Disaster Recovery, Business Continuity oder Incident Response. Auch Cloud-Exit-Pläne entstehen zunehmend – nicht zuletzt als Reaktion auf regulatorische Anforderungen und die Debatte um digitale Souveränität.

Die entscheidende Frage lautet jedoch nicht, ob ein Exit dokumentiert wurde, sondern ob sich geschäftskritische Anwendungen unter realen Bedingungen innerhalb der geforderten Zeit tatsächlich wieder produktiv betreiben lassen.

Genau hier liegt der Unterschied zwischen theoretischer Portabilität und operativer Exit-Fähigkeit. Ein Exit-Dokument beschreibt meist lediglich Prozesse und Verantwortlichkeiten. Ob diese im Ernstfall funktionieren, lässt sich ausschließlich durch regelmäßige Tests nachweisen.

Recovery ist der eigentliche Härtetest

Der Erfolg eines Cloud-Exits entscheidet sich selten beim eigentlichen Datentransfer. Ausschlaggebend ist vielmehr, ob Anwendungen nach der Migration vollständig und sicher wieder betrieben werden können.

Dazu gehört weit mehr als die Wiederherstellung von Daten. Authentifizierung und Autorisierung müssen funktionieren, Zertifikate, Secrets und Schlüssel korrekt eingebunden sein, Monitoring und Logging unmittelbar nach dem Start wieder arbeiten und externe Schnittstellen sowie DNS-Einträge zuverlässig umgeschaltet werden.

Erst wenn diese Komponenten zusammenspielen, ist ein produktiver Betrieb wiederhergestellt.

Genau deshalb unterscheiden sich Exit-Tests grundlegend von klassischen Backup-Tests. Während Letztere lediglich den Datenbestand überprüfen, weisen Recovery-Tests nach, dass eine komplette Betriebsumgebung unter produktiven Bedingungen wieder funktionsfähig ist.

Parallelbetrieb ist heute der Regelfall

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

Stattdessen setzen Unternehmen zunehmend auf mehrstufige Migrationsverfahren. Daten werden kontinuierlich repliziert, Zielplattformen parallel aufgebaut und Anwendungen mehrfach getestet, bevor einzelne Dienste schrittweise umgeschaltet werden.

Während dieser Übergangsphase existieren Quell- und Zielumgebung häufig über Wochen oder sogar Monate parallel. Zwar erhöht dies vorübergehend die Betriebskosten, gleichzeitig sinkt jedoch das Risiko ungeplanter Ausfälle erheblich.

Gerade für Unternehmen mit hohen Anforderungen an Verfügbarkeit, Compliance oder regulatorische Nachweise ist ein kontrollierter Parallelbetrieb inzwischen eher Standard als Ausnahme.

RTO und RPO bleiben die entscheidenden Messgrößen

Ob ein Cloud-Exit erfolgreich war, entscheidet sich letztlich an denselben Kennzahlen, die auch im Business Continuity Management gelten.

Das Recovery Time Objective (RTO) definiert die maximal zulässige Wiederanlaufzeit eines Dienstes, das Recovery Point Objective (RPO) den akzeptablen Datenverlust.

Diese Werte müssen auch nach einer Migration eingehalten werden. Eine Anwendung gilt deshalb nicht allein deshalb als portabel, weil sie grundsätzlich auf einer anderen Plattform lauffähig ist. Entscheidend ist vielmehr, ob dort dieselben Service Levels, Sicherheitsanforderungen und Wiederherstellungszeiten erreicht werden können.

Cloud-Portabilität besitzt damit immer auch eine betriebliche Dimension.

Exit-Fähigkeit wird Teil der Enterprise Architecture

Mit zunehmender Cloud-Nutzung entwickelt sich Exit-Fähigkeit von einer Infrastrukturaufgabe zu einem Bestandteil moderner Enterprise Architecture.

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

Neue Anwendungen sollten deshalb bereits während ihrer Planung hinsichtlich ihrer Portabilität bewertet werden. Dazu gehören Fragen nach proprietären Diensten ebenso wie Überlegungen zu Exit-Szenarien, Identitätsmodellen oder regulatorischen Anforderungen.

Der EU Data Act verändert den Cloud-Markt somit nicht nur regulatorisch. Er verändert langfristig auch die Kriterien, nach denen Unternehmen ihre Cloud-Architekturen entwerfen.

Cloud-Souveränität ist kein Projekt, sondern eine dauerhafte Fähigkeit

Mit dem EU Data Act reduziert die Europäische Union wirtschaftliche Wechselbarrieren und stärkt den Wettbewerb zwischen Cloud-Anbietern. Die technische und organisatorische Komplexität moderner Cloud-Architekturen bleibt davon jedoch weitgehend unberührt.

Unternehmen müssen deshalb zwischen zwei Ebenen unterscheiden: Der Data Act verbessert die Marktbedingungen und stärkt ihre Verhandlungsposition gegenüber Hyperscalern. Ob ein Cloud-Exit tatsächlich gelingt, entscheidet sich jedoch innerhalb der eigenen Architektur.

Digitale Souveränität entsteht daher nicht durch regulatorische Vorgaben allein. Sie muss technisch vorbereitet, organisatorisch verankert und regelmäßig überprüft werden.

Nicht jede Abhängigkeit ist ein Problem

In der Diskussion über digitale Souveränität entsteht mitunter der Eindruck, jede Anwendung müsse jederzeit ohne größeren Aufwand zwischen verschiedenen Cloud-Plattformen migriert werden können.

Diese Erwartung greift zu kurz.

Moderne Cloud-Dienste entfalten ihren größten Nutzen gerade durch ihre tiefe Integration in das jeweilige Plattformökosystem. Hochskalierende Datenbanken, serverlose Architekturen, KI-Dienste oder spezialisierte Sicherheitsfunktionen bieten Unternehmen Mehrwerte, die sich mit vollständig standardisierten Komponenten häufig nur mit erheblichem Mehraufwand erreichen lassen.

Die Herausforderung besteht daher nicht darin, jede Form von Vendor Lock-in vollständig zu vermeiden. Entscheidend ist vielmehr, bewusst zwischen strategisch akzeptierten Abhängigkeiten und ungewolltem Lock-in zu unterscheiden.

Eine Architektur ist nicht deshalb souverän, weil sie keinerlei Bindungen kennt. Sie ist souverän, wenn ihre Abhängigkeiten dokumentiert, bewertet und bei Bedarf kontrolliert verändert werden können.

Der Data Act verändert vor allem die Planung

Die größte Wirkung des EU Data Act dürfte deshalb nicht in einer kurzfristigen Welle von Cloud-Migrationen liegen.

Seine eigentliche Bedeutung besteht darin, dass Unternehmen Exit-Fähigkeit künftig wesentlich früher in ihre Architekturentscheidungen einbeziehen müssen.

Cloud-Portabilität entwickelt sich damit zu einem festen Bestandteil moderner IT-Governance. Neue Plattformen werden künftig nicht nur nach Leistung, Skalierbarkeit oder Kosten bewertet, sondern ebenso hinsichtlich ihrer langfristigen Portabilität, ihrer regulatorischen Anforderungen und ihrer Auswirkungen auf Recovery, Identitäten und Schlüsselmanagement.

Damit verändert sich auch die Rolle der Enterprise Architecture. Sie definiert künftig nicht mehr nur technologische Zielbilder, sondern muss gleichzeitig sicherstellen, dass diese auch unter veränderten wirtschaftlichen, regulatorischen oder geopolitischen Rahmenbedingungen handlungsfähig bleiben.

Dauerhafte Unternehmensaufgabe: partielle Portabilität statt kompletter Ad-hoc-Exit-Strategien

Der EU Data Act schafft einen wichtigen regulatorischen Rahmen für mehr Wettbewerb und erleichtert künftig den Wechsel zwischen Cloud-Anbietern. Die eigentlichen Herausforderungen liegen jedoch weiterhin in der Architektur.

Ob ein Cloud-Exit gelingt, entscheidet sich selten an Vertragsklauseln oder Transfergebühren. Maßgeblich sind vielmehr Plattformdienste, Identitäten, Schlüsselmanagement, Backup-Konzepte, Monitoring und Betriebsprozesse – also Entscheidungen, die häufig Jahre vor einer Migration getroffen wurden.

Cloud-Souveränität ist deshalb weder ein einmaliges Projekt noch ein regulatorischer Endzustand. Sie entwickelt sich zu einer dauerhaft nachweisbaren Fähigkeit, kritische Workloads unter definierten Sicherheits-, Compliance- und Betriebsanforderungen kontrolliert zu verlagern oder wiederherzustellen.

Der EU Data Act setzt dafür den regulatorischen Rahmen. Die eigentliche Umsetzung beginnt jedoch lange vor dem ersten Datenexport – bei einer Architektur, die Portabilität von Anfang an mitdenkt.

Wird digitale Souveränität überschätzt – oder zu plakativ diskutiert?

Die Debatte um 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 Anbieter 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, KI, 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. Eine moderne Cloud-Strategie muss nicht jede Abhängigkeit vermeiden, sondern sie transparent machen und beherrschbar halten.

Vielleicht sollten wir deshalb weniger über den schnellen Cloud-Exit diskutieren und häufiger über gute Architektur. Digitale Souveränität entsteht nicht durch den Verzicht auf Plattformdienste, sondern durch die Fähigkeit, deren Folgen zu kennen und bei Bedarf kontrolliert handeln zu können.

Genau darin liegt die eigentliche strategische Aufgabe für Unternehmen. Souveränität ist damit kein Endzustand – sondern das Ergebnis vorausschauender Architekturentscheidungen.