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ß.