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 ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Exits entscheidet

Wer über Cloud-Abhängigkeit spricht, spricht häufig abstrakt. In der Praxis entscheidet sich der spätere Aufwand und der Erfolg eines Exit jedoch an einer sehr konkreten Frage: Auf welcher Ebene nutzt das Unternehmen Cloud-Leistungen?

Infrastructure-, Platform- und Software-as-a-Service unterscheiden sich nicht nur im Funktionsumfang, sondern vor allem darin, in welcher Tiefe Teile der IT- und Prozesslandschaft vom Unternehmen gesteuert werden – und welche nicht.

Infrastruktur: Technisch austauschbar – organisatorisch beherrschbar

Infrastructure as a Service beschränkt sich im Kern auf die Bereitstellung technischer Ressourcen wie Rechenleistung, Speicher und Netzwerkinfrastruktur. Die Verantwortung für Applikationen, Datenstrukturen und Geschäftslogiken verbleibt weitgehend beim Unternehmen.

Diese Trennung ist für den Exit entscheidend. Beim Anbieterwechsel müssen zwar Systeme migriert und Betriebsumgebungen neu aufgebaut werden, die grundlegende Struktur der Applikationen bleibt jedoch erhalten. Daten behalten ihre Bedeutung, weil sie nicht durch plattformspezifische Funktionen oder Anwendungskontexte geprägt sind, sondern durch unternehmenseigene Modelle und Prozesse.

Der Wechsel ist damit primär eine technische und organisatorische Aufgabe. Er erfordert Planung, Koordination und Ressourcen, verändert jedoch nicht die Art und Weise, wie das Unternehmen arbeitet. Die Abhängigkeit vom Anbieter betrifft nur den Betrieb, nicht die Logik des Geschäfts. Sie ist daher vergleichsweise gering.

👉 Infrastruktur ermöglicht Skalierung und Flexibilität, ohne die Architektur oder die Prozesse des Unternehmens tiefgreifend zu prägen. Der Exit ist aufwendig, aber strukturell beherrschbar, weil das Unternehmen die Kontrolle über Applikationen und Datenmodelle behält.

Plattform: Wenn technische Entscheidungen strategische Wirkung entfalten

Platform as a Service verschiebt die Verantwortung weiter vom Unternehmen zum Anbieter. Neben der reinen Infrastruktur werden zentrale technische Bausteine genutzt, etwa Datenbankdienste, Laufzeitumgebungen oder Integrationskomponenten. Diese Dienste geben nicht nur technische Möglichkeiten vor, sondern definieren den Rahmen, in dem Softwareanwendungen entwickelt und betrieben werden.

Applikationen werden dadurch nicht „proprietär“ gestaltet. Vielmehr orientieren sich Architektur- und Designentscheidungen an den Funktionen und Standards der jeweiligen Plattform. Datenmodelle, Schnittstellen und Verarbeitungslogiken entstehen innerhalb dieses Rahmens, weil er Effizienz, Skalierbarkeit und Betriebssicherheit verspricht.

Dieses Setting hat Konsequenzen für den Exit. Zwar lassen sich Applikationen grundsätzlich portieren. Funktionen, die innerhalb der Plattform selbstverständlich verfügbar sind – etwa bestimmte Datenbankmechanismen, Event- oder Messaging-Strukturen oder integrierte Sicherheits- und Identitätsdienste – müssen jedoch bei einem Wechsel entweder nachgebildet oder neu konzipiert werden.

Der Wechsel betrifft damit nicht nur den Betrieb, sondern die Struktur der Apps selbst. Was technisch als Plattformwechsel erscheint, wird organisatorisch zu einem Architekturprojekt. Der Aufwand liegt weniger im Transfer von Daten oder Code als in der Wiederherstellung der Funktionslogik unter anderen technischen Voraussetzungen.

👉 Für Unternehmen bedeutet das: Entscheidungen, die auf Plattformebene getroffen werden, wirken strategisch, auch wenn sie operativ motiviert sind. Die Wahl einer Plattform bestimmt nicht nur Effizienz und Geschwindigkeit der Entwicklung, sondern auch die Komplexität eines späteren Wechsels.

Software: Wenn Anwendungen die Organisation strukturieren

Software as a Service unterscheidet sich grundlegend von Infrastruktur- und Plattformdiensten. Das Unternehmen nutzt hier nicht lediglich technische Ressourcen oder Entwicklungsumgebungen, sondern Softwareanwendungen, in denen Geschäftsprozesse, Entscheidungslogiken und Datenstrukturen unmittelbar und zunächst standardisiert abgebildet sind.

Unternehmensdaten werden dabei nicht isoliert gespeichert. Sie sind Teil eines funktionalen Gesamtzusammenhangs. Ihre Bedeutung ergibt sich aus der Art, wie die App sie verarbeitet, miteinander verknüpft und in Prozesse einbettet.

Mit der Zeit werden die Standards konfiguriert, erweitert und an individuelle Abläufe angepasst. Die Software übernimmt zunehmend Funktionen, die zuvor organisatorisch geregelt waren. Die Grenze zwischen IT-System und Organisation wird unscharf. Mit der Zeit bilden Workflows, Berechtigungen, Automatisierungen und Auswertungen die gesamte konkrete Arbeitsweise des Unternehmens ab.

Beim Exit zeigt sich die Konsequenz. Zwar lassen sich Daten regelmäßig exportieren, ihre wirtschaftliche Nutzbarkeit hängt jedoch davon ab, ob ihre Bedeutung außerhalb der Anwendung rekonstruierbar ist. Prozesse, die bislang implizit im System abgebildet waren, müssen nun – weil die gesonderte Dokumentation im Unternehmen selbst regelmäßig fehlt – explizit beschrieben werden. Entscheidungen, die die Software bislang automatisiert getroffen hat, müssen neu verortet werden.

Der Wechsel einer SaaS-Lösung ist daher kein reines Migrationsprojekt. Er betrifft Abläufe, Verantwortlichkeiten und Steuerungsmechanismen. Der Aufwand liegt weniger im technischen Transfer als in der Entflechtung einer über Jahre gewachsenen Struktur, in der Software und Organisation eng miteinander verwoben sind.

👉 Für Unternehmen bedeutet das: SaaS schafft nicht nur Effizienz, sondern strukturiert das Unternehmen mit. Diese Bindungswirkung ist kein Fehlverhalten, sondern die logische Folge intensiver Nutzung. Sie lässt sich nicht vollständig vermeiden – aber sie muss verstanden und gesteuert werden, wenn ein späterer Wechsel realistisch möglich bleiben soll.

Fazit

Cloud ist nicht gleich Cloud. Der Aufwand und das Risiko eines Anbieterwechsels hängen maßgeblich davon ab, auf welcher Ebene Cloud-Leistungen genutzt werden. Während Infrastruktur vor allem den Betrieb betrifft, prägen Plattformen die Architektur und SaaS-Anwendungen zunehmend die Organisation selbst. Mit jeder Abstraktionsebene verändert sich damit auch die Intensität der Abhängigkeit.

Warum diese Abhängigkeiten häufig erst beim Exit sichtbar werden, habe ich im ersten Beitrag dieser Reihe näher erläutert. Der vorliegende Beitrag zeigt, wodurch sie sich bei den jeweiligen Ebenen konkret unterscheiden und warum sie sich nicht allein durch vertragliche Regelungen beherrschen lassen.

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.

Dies ist der zweite Beitrag einer Reihe –

👉 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/

Schlagwort: #Rechtsberatung

Cloud ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Wechsels entscheidet

Cloud ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Exits entscheidet

Infrastruktur: Technisch austauschbar – organisatorisch beherrschbar

Plattform: Wenn technische Entscheidungen strategische Wirkung entfalten

Software: Wenn Anwendungen die Organisation strukturieren

Fazit