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