EU Data Act: Cloud-Switching und Interoperabilität

EU Data Act: Cloud-Switching und Interoperabilität –
Eine erster Einstieg

Seit dem 12. September 2025 finden wesentliche Regelungen des EU Data Act Anwendung.

Interessierte Communities tauschen sich viel zu den Anforderungen an das Produktdesign oder die Bereitstellung von Nutzungsdaten aus. Als Beispiel gern genommen wird das Auto. Eher leise kommen dagegen die Regelungen zum Cloud-Switching daher. Das ist verwunderlich, denn sie haben für Softwarehersteller und Distributoren erhebliche Auswirkungen – Kunden können Nutzen ziehen.

Veröffentlicht am 21.08.2025 – überarbeitet am 05.01.2026

Zwei sehr verschiedene Regelungsbereiche

Am 23. Februar 2022 legte die EU-Kommission ihren ersten Entwurf für den Data Act vor – eine Verordnung über fairen Datenzugang und faire Datennutzung. Über die Pläne berichtete ich bereits im September 2022 in der Sonderbeilage der Fachzeitschrift IT-Business – Cloud & Virtualisierung.

Seither habe ich die Debatten um den Data Act intensiv begleitet, unter anderem in Sitzungen der Verbände BDI und ZVEI, an denen auch Vertreter der EU-Kommission und des Bundesministeriums für Wirtschaft im Bereich Digitalisierung und Industrie 4.0 teilgenommen haben. Dort stand vor allem das Kapitel zum Data-Sharing bei IoT-Produkten im Mittelpunkt: Wem gehören die Daten, die bei der Nutzung eines Autos, eines CT-Geräts oder einer Baumaschine entstehen? Nach dem Willen der EU dürfen Hersteller diese künftig nur mit Zustimmung der Nutzer selbst verwenden. Gleichzeitig müssen sie die Daten und Metadaten Nutzern – und auf Wunsch auch Dritten – zugänglich machen, selbst wenn Geschäftsgeheimnisse betroffen sind.

Die Industrie konnte daran kaum etwas ändern. Der Data Act wurde am 22. Dezember 2023 verabschiedet und gilt in seinen wesentlichen Teilen seit dem 12. September 2025. Viele Unternehmen stehen nun vor der Herausforderung, unklare und komplexe Vorgaben in die Praxis umzusetzen. Aus meiner Beratungspraxis weiß ich: Mit einem pragmatischen Ansatz lassen sich Lösungen finden. In dem Data-Act-Projekt bei einem international ausgerichteten Baumaschinenhersteller haben wir in einem interdisziplinären Team Wege entwickelt, um die gesetzlichen Anforderungen zu erfüllen, ohne Wettbewerbsnachteile zu riskieren.

Deutlich weniger Aufmerksamkeit haben bisher die Vorgaben zu Cloud-Switching und Interoperabilität erhalten. Dabei gehören sie zu den folgenreichsten Kapiteln des Data Act – mit weitreichenden Konsequenzen nicht nur für die großen Softwarehersteller, sondern ebenso für Distributoren, Partner und Dienstleister. 

1. Was bedeutet Cloud-Switching im Kontext des Data Act?

Der Data Act greift gezielt in den Markt für Cloud-Dienste ein. Sein Ziel: Nutzer sollen nicht mehr dauerhaft an einen Anbieter gebunden sein, sondern ihre Daten, Anwendungen und Workloads einfacher zu einem anderen Provider übertragen können. Damit will die EU den „Lock-in-Effekt“ durchbrechen, der heute viele Unternehmen davon abhält, den Anbieter zu wechseln. Erfasst sind Cloud-Angebote in den bekannten Schichten:

  • Infrastructure-as-a-Service (IaaS): Infrastruktur wie Server, Netze und Speicher.
  • Platform-as-a-Service (PaaS): Entwicklungs- und Betriebsumgebungen für Anwendungen.
  • Software-as-a-Service (SaaS): Anwendungen, die der Kunde „fertig“ nutzen kann.

Je höher die Ebene, desto komplexer ist ein Anbieterwechsel. 

Gleiche Dienstart

Der Data Act ermöglicht eine vom Anbieter kostenlos zu unterstützte Portabilität von Daten zwischen Diensten – aber nur, wenn diese Dienste gleichartig sind. Unter „Diensten gleicher Dienstart“ versteht man im Wesentlichen Datenverarbeitungsdienste, die dasselbe Hauptzieldie gleichen Hauptfunktionen und das gleiche Dienstmodell teilen.

Operative Details, wie etwa die zugrunde liegende Infrastruktur oder konkrete technische Umsetzung, spielen keine Rolle. Entscheidend ist, dass alle drei Kriterien gleichzeitig erfüllt sind: Nur wenn Hauptziel, Hauptfunktionen und Dienstmodell übereinstimmen, kann ein Nutzer seine Daten rechtlich und technisch problemlos zu einem anderen Anbieter übertragen.

Bereichsausnahmen

Nicht alle Dienste sind jedoch erfasst. Ausgenommen sind Test- und Proof-of-Concept-Angebote, da hier naturgemäß noch kein Lock-in besteht. Anders verhält es sich mit „On-Top-Angeboten“, die bestehende Kunden binden sollen – sie fallen unter die Wechselpflichten.

2. Interoperabilität: Anforderungen an Schnittstellen

Ein zentrales Element des Data Act sind die Schnittstellen, über die ein Wechsel von einem Cloud-Anbieter zum anderen technisch ermöglicht wird. Der Gesetzgeber schreibt vor, dass Anbieter von Datenverarbeitungsdiensten ihre Schnittstellen so ausgestalten müssen, dass Kunden ihre Daten in ein anderes System übertragen können – ohne übermäßigen Aufwand und ohne technische Hürden.

Offene Schnittstellen mit ausreichenden Informationen

Art. 30 Data Act verpflichtet Anbieter, offene Schnittstellen bereitzustellen. „Offen“ bedeutet hier: Die Schnittstellen sind öffentlich dokumentiert und können von Dritten genutzt werden, etwa für die Entwicklung von Migrationstools.

Diese Schnittstellen müssen mit ausreichenden Informationen angereichert sein – insbesondere mit den Metadaten, die erforderlich sind, um eine Kommunikationsfunktion zwischen Alt- und Neusystem herzustellen. Ein typisches Beispiel: Im Altsystem werden „Vorname“ und „Nachname“ getrennt gespeichert, im neuen System gibt es nur das Feld „Name“. Das Migrationstool muss anhand der bereitgestellten Metadaten in der Lage sein, die beiden Werte zusammenzuführen und korrekt im Zielsystem einzutragen. Ohne solche Informationen wären die exportierten Daten zwar vorhanden, im neuen System aber nicht sinnvoll nutzbar.

Konflikt mit Schutzrechten

Wie schon im vorherigen Kapitel dargestellt, können diese Metadaten tief in geschützte Bereiche wie Geschäftsgeheimnisse oder geistige Eigentumsrechte hineinreichen. Der Data Act stellt jedoch klar: Der Schutz endet dort, wo er den Anbieterwechsel vereiteln würde. Die genaue Abgrenzung, welche Informationen offengelegt werden müssen, bleibt in vielen Fällen eine Frage der Praxis und voraussichtlich auch der Rechtsprechung.

Interessant für SAP Kunden:

Selbstverständlich gilt das alles auch für „RISE with SAP S/4 HANA on Hyperscaler“. Kunden können – jedenfalls in der public cloud – frei wählen, ob sie im Bereich Analytics & Data die SAP Analytics Cloud (SAC) verwenden wollen oder z.B. die Power BI von Microsoft. Die Schnittstellen müssen künftig den Anforderungen des Data Act genügen. Hierzu gab es im Rahmen meines Vortrages bei den Münchner SAP-Tagen am 2. Oktober 2025 interessante Diskussionen: http://sap-tage.de/227.html.

Fazit

Der Data Act ist weit mehr als ein Gesetzestext – er ist ein komplexer Regelungsrahmen, der Unternehmen auf vielen Ebenen betrifft. Die hier angesprochenen Punkte zu Datenportabilität, Metadaten und Schnittstellen sind nur ein Ausschnitt. In der Praxis stellen sich zahlreiche weitere Detailfragen, die jeweils erhebliche rechtliche und technische Herausforderungen mit sich bringen.

Mit einzelnen Aspekten habe ich mich in einer Beitragsreihe von TRENCHANT tiefer auseinandergesetzt:

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/

👉 Link zu Beitrag 2: „Cloud ist nicht gleich Cloud – wie die Abstraktionsebene über den Aufwand des Exits entscheidet“
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/

Eines ist klar: Projekte zur Umsetzung des Data Act sollten unbedingt mit rechtlicher Expertise begleitet werden. Nur so lassen sich Risiken vermeiden und tragfähige Lösungen entwickeln, die den gesetzlichen Anforderungen gerecht werden und gleichzeitig die Wettbewerbsfähigkeit sichern.

Wer tiefer einsteigen möchte: Im Compliance Handbuch EU Data Act (Carl Heymanns Verlag – Wolters Kluwer), an dem ich als Co-Autorin mitgewirkt habe, finden sich umfassende Erläuterungen und Praxishinweise zu allen relevanten Kapiteln.

Wenn Sie konkrete Fragen zu Ihrem Data Act Projekt haben, sprechen Sie mich gerne an.

Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen

Cloud-Wechsel: Kostenreduktion durch offene Schnittstellen, bereitzustellende Metadaten und Informationen

Seit dem 12.09.2025 ist der Data Act EU-weit unmittelbar anwendbar. Im Fokus steht auch der wirtschaftliche lock-in beim Cloud-Computing durch zu hohe Kosten und Risiken beim Wechsel des Providers. Dafür nimmt das Gesetz jene Faktoren in den Fokus, die schon immer entscheidend waren: Schnittstellen, Metadaten und Informationszugang.

Ein Überblick.

Intro

Der Data Act wird häufig als neues Wechselrecht für Cloud-Nutzer beschrieben. Diese Perspektive greift jedoch zu kurz; der Wechsel des Anbieters war schon immer rechtlich möglich, oft aber unwirtschaftlich und stark risikobehaftet: Die Kosten der Berater für das Migrationsprojekt, die internen Aufwände und die Risikokosten – auch getrieben durch Aspekte aus der Sphäre des bisherigen Anbieters – haben den Business-Case des Wechsels selten getragen.

Bitter, wenn der Nutzer das erst im Laufe des Migrationsprojekts erkennt.

Diese wirtschaftliche Abhängigkeit möchte das Gesetz aufbrechen. Erstmals sind Anbieter verpflichtet, den Wechsel für Nutzer – vertraglich nicht abwendbar – kostenfrei und risikoärmer zu gestalten. Dafür adressiert der Data Act ganz bewusst die technische und informationelle Seite des Cloud-Exits.

Gut gemeint, aber in Teilen unglücklich gestaltet: Zahlreiche Auslegungsfragen sowie Konflikte mit bestehenden Normen erzeugen erhebliche Rechtsunsicherheiten. Besonders heikel wird es dort, wo bereitzustellende Metadaten Rückschlüsse auf Geschäftsgeheimnisse des Anbieters erlauben.

Für Anbieter sollte diese Beratung idealerweise vor Vertragsschluss erfolgen, denn Geschäftsgeheimnisschutz lässt sich vielfach auch technisch rechtssicher gestalten. Nur braucht dieser Weg Zeit und Mittel. Manche Anbieter verweisen statt dessen reflexartig auf die von der Kommission bereitgestellten „Standardvertragsklauseln“ – oft ohne sie im Detail zu kennen oder zu verstehen. Aus verschiedenen Gründen keine gute Idee.

Der Perspektivwechsel des Data Act: Vom Wechselrecht zur Anbieterpflicht

Auf den ersten Blick scheint es sich um recht abstrakte Pflichten zu handeln, die der Data Act vorhält. In zentralen Aspekten mit hohem Interessenwiderstreit wird es aber de facto sehr konkret.

Im Zentrum stehen:

  • die Bereitstellung offener Schnittstellen,
  • die Zurverfügungstellung von Informationen für die Herstellung der Kommunikationsfunktion des Migrationstools,
  • die Herausgabe von Unternehmensdaten und der für ihre sinnvolle Nutzung erforderlichen „Metadaten“.

Das alles adressiert den ETL-Prozess der technischen Migration der Unternehmensdaten des Nutzers in das Zielsystem (Extract-Transform-Load).

Nach meiner Erfahrung einer der kritischsten Prozesse im Projekt überhaupt. Das Migrationstool muss die Unternehmensdaten vollständig aus dem Altsystem extrahieren, sie korrekt interpretieren und dann im neuen System an der richtigen Stelle ablegen. Werden hier entstehende Fehler zu spät erkannt, kann der Schaden erheblich sein – insbesondere dann, wenn das Altsystem nicht mehr für eine Rekonstruktion zur Verfügung steht.

Das ebenso häufige Problem mangelhafter Datenqualität ist damit allerdings nicht gelöst. Das bleibt in der Verantwortung des Nutzers. Einfache Beispiele hierfür sind inkonsistente Nummernangaben als Text- und Zahl, inkonsistente Codes wie „m“, „male“ „Mann“ oder auch Namensvarianten wie „Müller“ „Mueller“.

👉 Im Einzelnen:

Offene Schnittstellen und Informationen: Rechtlich gefordert, technisch nicht eindeutig definiert

Eine zentrale Vorgabe des Data Act ist die Verpflichtung zur Bereitstellung offener Schnittstellen. Dieser Begriff ist jedoch nicht definiert. Klargestellt ist nur, dass Schnittstellen „ausreichende Informationen über den betreffenden Dienst enthalten müssen, damit die Software entwickelt werden kann, die für die Kommunikation mit den Diensten zu Zwecken der Datenübertragbarkeit und der Interoperabilität erforderlich ist.“ – also das Migrationstool.

👉 „Offen“ bedeutet damit nicht, dass die Schnittstelle standardisiert oder universell kompatibel sein muss. 

Der Data Act selbst verweist nicht auf einen konkreten verbindlichen technischen Standard (z. B. ein bestimmtes API-Protokoll). Allerdings arbeiten EU-Institutionen bzw.  Standardisierungsorganisationen bereits an harmonisierten technischen Standards. 

Eine Vorstellung davon, welche Informationen offengelegt werden müssen, kann (stark vereinfacht) ein Vergleich mit der allgemein bekannten E-Mail-Kommunikation geben: Um mit einer anderen Person per E-Mail Daten oder Datenpakete auszutauschen, ist zunächst die Kenntnis der E-Mail-Adresse erforderlich. Sie gibt an, wohin Daten und Datenpakete gesendet werden können. Darüber hinaus muss der Sender die Datenformate für Anhänge kennen, die vom Empfänger verarbeitet und gelesen werden können. Diese Informationen genügen, um Daten und Datenpakete in einen Datenverarbeitungsdienst einzubringen.

Für Anwender bedeutet das: Die Existenz offener Schnittstellen ist ein wichtiger Fortschritt, ersetzt aber nicht die Entwicklung eines Migrationstools.

👉 Die Bereitstellung einer tauglichen Schnittstelle zum Altsystem ist aus Sicht eines „Migrationsberaters“ eine Beistellung des Kunden. Ihm gegenüber ist allein der Kunde verantwortlich, nicht der bisherige Cloud-Provider.

👉 Aus der Praxis: Immer häufiger kommt es vor, dass „Migrationsberater“ das Migrationstool an Kunden gesondert vermieten, damit diese es ihm dann wieder als Beistellung überlassen. Interessante Konstellation mit unschönen rechtlichen Folgen für den Kunden.

Daten und Metadaten – und die Grenze zum Geschäftsgeheimnis

Besondere Brisanz entfaltet der Data Act bei der Pflicht zur Bereitstellung von Metadaten. Hierbei handelt es sich um eine strukturierte Beschreibung der Kundendaten. Sie sind notwendig, um die Kundendaten sinnvoll einzuordnen, zu interpretieren und weiterzuverarbeiten. Ohne sie bleiben Kundendaten formal portabel, aber wirtschaftlich kaum nutzbar.

👉 Metadaten werden u.a. benötigt für das Mapping vom Altsystem zum Zielsystem und für die Entwicklung des Migrationstools.

Gleichzeitig können Metadaten weit mehr sein als neutrale Beschreibungen. Sie können Rückschlüsse auf Systemarchitekturen, Optimierungslogiken oder interne Abläufe des Anbieters zulassen. Diese Interessenkollision hat der Data Act zu Lasten der Cloud-Anbieter gelöst:

Werden Informationen über die interne Funktionsweise des Dienstes durch die Nutzung des Datenverarbeitungsdienstes generiert und sind sie für einen ungehinderten und effizienten Wechsel notwendig, muss der Anbieter sie zum Export bereitstellen, und zwar auch dann, wenn die Gefahr der Verletzung von Geschäftsgeheimnissen besteht.

Soweit Informationen über die interne Funktionsweise des Dienstes nicht durch die Nutzung des Datenverarbeitungsdienstes generiert werden, fallen sie nicht unter die Definition von „exportierbare Daten“. Sind sie für einen ungehinderten und effizienten Wechsel notwendig, muss der Anbieter sie aber offenlegen.

In der Praxis wird es auf eine sorgfältige Abgrenzung ankommen, welche sowohl technisch als auch rechtlich gut begründet und behördentauglich dokumentiert werden muss.  

Was Anwender-Unternehmen daraus realistisch ableiten sollten

Der Data Act verbessert die Ausgangslage von Anwendern spürbar. Er schafft erstmals einen verbindlichen Rahmen für die Mitwirkungspflichten der Anbieter beim Wechsel. Gleichzeitig verlagert er Konflikte in neue Bereiche.

Für Anwender bedeutet das: Die neuen Rechte sind keine Selbstläufer. Sie müssen verstanden, eingeordnet und im konkreten Kontext durchgesetzt werden. Gerade bei komplexen Cloud-Umgebungen wird entscheidend sein, frühzeitig zu klären, welche Informationen, Schnittstellen und Metadaten tatsächlich benötigt werden – und wo legitime Grenzen der Anbieterpflichten verlaufen.

Im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2.

habe ich die technischen Aspekten des Cloud-Switchings ausführlich beschrieben. Diese Kenntnisse sind erforderlich, um qualifiziert anwaltlich beraten zu können. Insbesondere geht es um Geschäftsgeheimnisse und Datenbankrechte, Syntax und Semantik, Daten und Metadaten sowie um weitere Aspekte, die ich in den vorherigen Beiträgen dieser Reihe erläutert habe:

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/

👉 Link zu Beitrag 2: „Cloud ist nicht gleich Cloud – wie die Abstraktionsebene über den Aufwand des Exits entscheidet“
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

Kurzer Abschlussgedanke –

Der Data Act ist kein Befreiungsschlag, aber ein Instrument. Wie wirkungsvoll es ist, entscheidet sich nicht im Gesetzestext, sondern in seiner Anwendung. Genau dort beginnt die eigentliche Arbeit. 

Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen

Cloud-Wechsel: Warum weder der EU Data Act noch gute Verträge allein vor Abhängigkeit schützen – Ein Realitätscheck.

Seit dem 12. September 2025 sind die Regelungen des Data Act über den Wechsel von Cloud-Services anwendbar. Sie sollen Anwender vor Abhängigkeiten und unfairen Verträgen schützten, die diese Abhängigkeit noch verstärken. Was der Data Act übersieht: Abhängigkeiten haben ihre Wurzeln in erheblichem Ausmaß auch im Unternehmen der Anwender.

Was zu beachten ist:

Cloud-Abhängigkeit entsteht nicht beim Einstieg – sondern im Laufe der Zeit

Unternehmen verlagern ihre IT in die Cloud, um flexibler, effizienter und resilienter zu werden. In den meisten Fällen funktioniert das – zumindest am Anfang.

Ernsthafte Probleme zeigen sich Jahre später. Dann, wenn sich Geschäftsmodelle ändern, regulatorische Anforderungen steigen oder ein Anbieterwechsel strategisch sinnvoll erscheint. Plötzlich wird aus einer erfolgreichen Cloud-Nutzung eine unerwartete Abhängigkeit.

Auffällig ist dabei: Diese Abhängigkeit basiert selten nur auf schlechten Verträgen, fehlenden Rechten oder proprietären Datenformaten und Schnittstellen. In der Praxis scheitert der Exit an der Realität – an technischen Verflechtungen, organisatorischem Know-how-Verlust und fehlenden Strukturen für den Ausstieg.

 ☞ Cloud-Abhängigkeit ist in erheblichem Ausmaß das Ergebnis von Entscheidungen, die früh getroffen wurden – oft ohne den Exit mitzudenken.

Die unternehmerische Realität als „Root-Cause“ für die Abhängigkeit 

Die wirtschaftlich und technologisch sinnvolle Entscheidung für die Cloud entfaltet über die Zeit eine Bindungswirkung, die beim Einstieg und über die Laufzeit nicht nur vertraglich, sondern auch organisatorisch berücksichtigt werden muss:

 ☞ Der Kontrollverlust gegenüber dem Anbieter muss so weit wie möglich vermieden werden. 

Ein zentraler Faktor hierbei ist die Kontrolle über die eigenen Daten. Zwar lassen sich diese regelmäßig während und am Ende einer Vertragslaufzeit exportieren. Ihre wirtschaftliche Nutzbarkeit hängt jedoch davon ab, ob ihre Struktur, ihre Bedeutung und ihr Zusammenhang mit Geschäftsprozessen auch außerhalb des bestehenden Systems verständlich bleibt. In der Praxis ist das häufig nicht der Fall. Ein typisches Beispiel: Über Jahre werden die Standardprozesse der Anwendung an kundenspezifische Abläufe angepasst, Felder ergänzt, Verknüpfungen verändert, Automatisierungen aufgebaut. Die Daten und Prozesse „passen“ immer besser zum bestehenden System – verlieren aber gleichzeitig ihre Eigenständigkeit. Daten sind oft nur noch im Rahmen der Prozesse verständlich. Formal sind sie portabel. Faktisch sind sie ohne erheblichen Analyse- und Mapping-Aufwand kaum weiterverwendbar.

Diese technische Entwicklung wird durch organisatorische Effekte verstärkt. Mit der Auslagerung von IT-Leistungen verlagert sich auch Wissen: über Systemlogiken, Abhängigkeiten, Schnittstellen und Sonderfälle. Was im Unternehmen nicht mehr täglich benötigt wird, wird nicht weiter gepflegt.

☞ Dokumentationen veralten, interne Expertise schrumpft, Verantwortung diffundiert zwischen Anbieter, Dienstleistern und internen Teams.

Die Folge ist eine schleichende Verschiebung der Steuerungsfähigkeit. Das Unternehmen bleibt rechtlich handlungsfähig, verliert aber faktisch an Überblick. Entscheidungen über Anpassungen, Erweiterungen oder einen späteren Wechsel können nur noch auf Basis der Informationen getroffen werden, die der bestehende Anbieter bereitstellt. Genau hier entsteht der eigentliche Lock-in-Effekt: nicht als bewusste Bindung, sondern als Nebenfolge effizienter Zusammenarbeit. Verträge bilden diese Entwicklung i.d.R. nur unvollständig ab. Sie bleiben – bedauerlicherweise – meist statisch, während sich Technik, Prozesse und Organisation dynamisch weiterentwickeln.

Aus unternehmerischer Sicht ist das kein Versagen, sondern ein realistisches Szenario. Problematisch wird es erst dann, wenn diese Realität beim Exit auf eine Erwartung trifft, die von formaler Austauschbarkeit ausgeht. Der Aufwand, die gewachsene Struktur zu entflechten, wird dann regelmäßig unterschätzt – in Zeit, Kosten und Managementaufmerksamkeit.

Warum der Exit der teuerste Moment eines Cloud-Vertrags ist

Der Exit aus einem Cloud-Vertrag ist selten ein ausreichend langfristig vorbereitetes Projekt. Erfahrungsgemäß erfolgt er nicht aus einer Position der Ruhe, sondern unter Zeit- und Entscheidungsdruck. Dann zeigt sich, dass auch vom bisherigen Anbieter bereitgestellte Daten samt Metadaten nicht ausreichen, um das Projekt erfolgreich abzuschließen. Der tatsächliche Aufwand beginnt erst dann – im Migrationsprojekt mit dem neuen Anbieter.

Die Daten müssen bereinigt, analysiert und neu zugeordnet werden. Die neue Zuordnung übernehmen oft so genannte „Migrationsroutinen“ automatisch. Aber nicht nur die vorher erforderliche Bereinigung der Daten, sondern auch die Dokumentation bestehender Geschäftsprozesse und damit der Anforderungen an die neue Software überfordern viele Unternehmen.

Geschäftslogiken, die über Jahre in der Anwendung abgebildet wurden, lassen sich nicht ohne Weiteres in eine neue Umgebung übertragen. Was technisch möglich ist, erweist sich organisatorisch und wirtschaftlich als hochkomplex.

Der Aufwand hierfür wird häufig unterschätzt – insbesondere, wenn internes Know-how in den Jahren zuvor abgebaut wurde.

Der regulatorische Rahmen verschärft diese Situation sogar. 

Nach dem Data Act muss der Wechsel zwischen Cloud-Anbietern grundsätzlich innerhalb eines klar begrenzten Zeitraums von bis zu 7 Monaten vollzogen sein. Für komplexe, historisch gewachsene Cloud-Umgebungen ist diese Frist kaum einzuhalten, wenn der Exit bzw. der Anbieterwechsel nicht frühzeitig vorbereitet wurde. Was als Schutz vor Lock-in gedacht ist, kann sich dann in einen erheblichen zusätzlichen Zeit- und Steuerungsdruck verwandeln.

Hinzu kommt, dass der bestehende Anbieter in dieser Phase faktisch zum Engpass wird. Selbst bei kooperativer Unterstützung bleibt das Unternehmen auf Informationen angewiesen, die nur dort verfügbar sind. Der Handlungsspielraum ist formal vorhanden, praktisch aber eingeschränkt. Kosten entstehen nicht nur durch technische Leistungen, sondern auch durch verlängerte Vertragslaufzeiten, Parallelbetrieb oder kurzfristige Übergangslösungen.

Der Exit wird damit zum teuersten Moment des Cloud-Vertrags – nicht, weil er überraschend ist, sondern weil seine Voraussetzungen lange nicht aktiv gestaltet wurden.

Für Geschäfts- IT-Leitungen ist das eine kritische Erkenntnis. Denn in dieser Phase geht es nicht mehr um Optimierung, sondern um Schadensbegrenzung.

Der Data Act ändert die Rechtslage – aber nicht die Ausgangssituation

Der Data Act macht den Anbieterwechsel rechtlich erzwingbar. Er setzt allerdings voraus, dass Unternehmen ihre Daten, Prozesse und Systemzusammenhänge in einer Form beherrschen, die einen strukturierten Übergang erlaubt. Wo diese Voraussetzungen fehlen, entsteht kein rechtliches Hindernis, sondern ein praktisches.

Der Data Act schützt vor formaler Blockade, nicht vor gewachsener Komplexität. Er erleichtert den Wechsel dort, wo er vorbereitet ist – und erhöht den Druck dort, wo er es nicht ist.

☞ Für Unternehmen bedeutet das: Regulierung ersetzt keine Exit-Strategie.

Was Geschäfts- und IT-Leitungen daraus ableiten sollten

Cloud-Nutzung ist heute eine strategische Notwendigkeit. Entscheidend ist jedoch, ob sie als dauerhaftes Abhängigkeitsverhältnis oder als steuerbares Geschäftsmodell verstanden wird. Der Unterschied liegt nicht im Vertrag, sondern in der Art, wie Entscheidungen über Technik, Organisation und Verantwortung getroffen werden.

Für Geschäfts- und IT-Leitungen bedeutet das vor allem eines: Der Exit ist kein Randthema, sondern Teil der Cloud-Strategie. Wer ihn erst am Vertragsende betrachtet, reagiert auf Entwicklungen, die längst stattgefunden haben. Wer ihn früh mitdenkt, behält Handlungsfähigkeit – auch unter regulatorischem und wirtschaftlichem Druck.

Der Data Act kann diese Handlungsfähigkeit unterstützen. Er ersetzt sie nicht. Unternehmen, die ihre Abhängigkeiten kennen und steuern, werden von neuen Wechselrechten profitieren. Unternehmen, die den Exit der Technik überlassen, werden auch durch Regulierung nicht beweglicher.

Fazit:

Abhängigkeit entsteht nicht durch einzelne Entscheidungen, sondern durch deren Zusammenspiel über Zeit. Sie lässt sich nicht vollständig vermeiden – aber sie lässt sich gestalten. Dafür braucht es keinen radikalen Kurswechsel, sondern einen nüchternen Blick auf die eigene Realität.

Verträge allein helfen hier wenig. Sie können Rechte, Pflichten und Risikokosten regeln. Aber auch eine wirksame Exit-Strategie ist rechtlich gebotene Governance-Aufgabe, die nach zahlreichen Gesetzen über Unternehmensführung und EU-Digitalrecht gestaltet werden muss.

Abschließend

Die hier dargestellten Zusammenhänge basieren auf meiner vertieften Auseinandersetzung mit Cloud-Wechseln und Exit-Szenarien im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2

Die Analyse verbindet rechtliche Vorgaben mit der technischen und organisatorischen Realität von Unternehmen – genau an dieser Schnittstelle entstehen in der Praxis die entscheidenden Risiken.

Es handelt sich um den ersten Beitrag einer Reihe –

👉 Beitrag 2: Cloud ist nicht gleich Cloud – wie die Abstraktionsebenen über den Aufwand des Wechsels entscheiden.
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/

Vor diesem Hintergrund bedarf der Projektvertrag mit dem neuen Anbieter einer gründlichen Vorbereitung in Kenntnis der eigenen Rechte und Pflichten. Ein erfolgreiches Migrationsprojekt kann keine Fußnote im SaaS-Vertrag mit dem neuen Anbieter sein. Dafür sind die Risiken zu groß.