EU Data Act: Cloud-Anbieter wechseln und Exit-Plan umsetzen

Kurzantwort: Was der Data Act beim Cloud-Wechsel verändert

Stand 22. September 2026 müssen Anbieter von Datenverarbeitungsdiensten Wechselhindernisse abbauen und den vertraglich sowie technisch geregelten Übergang zu einem anderen Anbieter, zu eigener Infrastruktur oder zu einer parallelen Nutzung unterstützen. Kapitel VI der Verordnung (EU) 2023/2854 gilt seit 12. September 2025. Es erfasst typischerweise IaaS-, PaaS- und SaaS-Angebote, sofern sie die Merkmale eines Datenverarbeitungsdienstes erfüllen.

Die Verordnung schafft Rechte und Pflichten für den Wechsel, aber keine automatische Migration. Der bisherige Anbieter kann Daten und digitale Vermögenswerte bereitstellen; das Zielsystem muss sie dennoch korrekt aufnehmen, auf sein Datenmodell abbilden und mit Identitäten, Schnittstellen und Betriebsprozessen verbinden. Genau diese Lücke schließt ein technischer Exit-Plan.

Dieser Beitrag ordnet betriebliche und technische Anforderungen ein und ersetzt keine Rechtsberatung. Vertragsauslegung, Anwendungsbereich und besondere regulatorische Anforderungen sollten im konkreten Fall fachkundig geprüft werden.

SaaS, PaaS und IaaS nicht über einen Kamm scheren

Ob ein Dienst unter die Wechselregeln fällt, hängt nicht allein vom Wort „Cloud“ im Produktnamen ab. Relevant sind die Merkmale des Datenverarbeitungsdienstes und die konkrete Leistungsarchitektur. Die Bundesnetzagentur nennt Cloud-Infrastruktur, Plattformen und Softwaredienste als typische Ausprägungen. Für einen Anbieterwechsel ist außerdem zu prüfen, ob der Zieldienst derselben Dienstleistungsart entspricht; daneben sieht die Verordnung die Übertragung auf eigene IT-Infrastruktur vor.

Bei PaaS und SaaS stehen offene Schnittstellen, hinreichende Dokumentation und die Bereitstellung exportierbarer Daten in einem strukturierten, gängigen und maschinenlesbaren Format im Mittelpunkt. Bei IaaS muss der bisherige Anbieter angemessene Maßnahmen unterstützen, damit funktionale Gleichwertigkeit in der Zielumgebung erreicht werden kann. Das ist keine Garantie, dass proprietäre Dienste, Laufzeitverhalten oder Kosten im Ziel identisch sind.

• SaaS: Geschäftsdaten, Anhänge, Beziehungen, Historien und nutzerdefinierte Konfigurationen abgrenzen
• PaaS: Laufzeit, Datenbanken, Queues, Funktionen, Deployments und Plattformabhängigkeiten inventarisieren
• IaaS: Rechenleistung, Speicher, Netzwerk, Images, Identitäten und Betriebsparameter auf Zielkompatibilität prüfen
• Hybride Nutzung: Quelle, Ziel und verbleibende Dienste samt Datenflüssen und Verantwortung ausdrücklich trennen

Anbieterpflicht und Kundenaufgabe sauber voneinander trennen

Der Ausgangsanbieter muss die vertraglich vorgesehenen Wechselinformationen bereitstellen und darf keine unzulässigen technischen, vertraglichen oder organisatorischen Hindernisse errichten. Dazu gehören je nach Dienst Exportmechanismen, Schnittstellen, Dokumentation und Unterstützung. Welche Daten und digitalen Vermögenswerte übertragen werden können, sollte der Vertrag eindeutig beschreiben.

Das Kundenunternehmen bleibt für seine Zielarchitektur verantwortlich. Es entscheidet, welche Bestände übernommen werden, wie sie im Zielmodell abgebildet werden und wann die neue Umgebung fachlich freigegeben ist. Auch der Zielanbieter trägt Mitwirkungspflichten, doch weder eine erfolgreiche Exportdatei noch eine akzeptierte API-Anfrage beweist, dass Aufträge, Dokumente, Berechtigungen oder Automatisierungen im Ziel vollständig funktionieren.

• Anbieterleistung: exportierbare Bestände, Formate, Schnittstellen und Unterstützung vertraglich konkretisieren
• Kundenleistung: Zielmodell, Zuordnung, Bereinigung, Testfälle, Fachabnahme und Cutover steuern
• Zielanbieterleistung: Importmöglichkeiten, technische Grenzen, Protokolle und Fehlerbehandlung offenlegen
• Gemeinsame Grenze: Verantwortlichkeit für Vollständigkeit und fachliche Richtigkeit an jedem Übergabepunkt festlegen

Fristen rückwärts vom Cutover planen

Der Vertrag muss eine maximale Vorbereitungsfrist von zwei Monaten vorsehen. Danach folgt grundsätzlich eine maximale Übergangsfrist von 30 Kalendertagen. Der Kunde kann die Übergangsfrist einmal um einen von ihm für angemessener gehaltenen Zeitraum verlängern. Sind 30 Tage aus technischen Gründen nicht machbar, muss der Anbieter dies innerhalb von 14 Arbeitstagen nach der Wechselanfrage begründet mitteilen und einen alternativen Zeitraum nennen; dieser darf sieben Monate nicht überschreiten.

Nach Abschluss des Wechsels muss eine Abruffrist von mindestens 30 Kalendertagen bestehen. Danach sind die exportierbaren Daten und digitalen Vermögenswerte zu löschen, soweit keine unions- oder nationalrechtliche Aufbewahrungspflicht entgegensteht. Für die Projektplanung bedeutet das: Inventar, Zielarchitektur und Testmigration sollten nicht erst mit der formalen Wechselanfrage beginnen.

• vor der Kündigung: Vertrag, Datenumfang, Zielarchitektur und Abhängigkeiten klären
• Vorbereitungsphase: Zugänge, Exportweg, Testbestand, Rollen und Zeitplan verbindlich machen
• Übergangsphase: Delta-Übernahme, Cutover, Abnahme und kontrollierten Rückfall ausführen
• Abruffrist: fehlende Objekte nachziehen, Nachweise sichern und Löschbestätigung vorbereiten

Keine Wechselentgelte bedeutet nicht: Migration ohne Kosten

Bis einschließlich 11. Januar 2027 darf der Ausgangsanbieter nur reduzierte, unmittelbar durch den Wechsel verursachte und kostenbasierte Entgelte verlangen. Ab 12. Januar 2027 dürfen Anbieter nach Artikel 29 grundsätzlich keine Wechselentgelte mehr erheben. Die Bundesnetzagentur betont zugleich, dass reguläre Standardentgelte, Gebühren wegen vorzeitiger Vertragsbeendigung oder vom Kunden zusätzlich verlangte Leistungen davon zu unterscheiden sind.

Auch nach Wegfall der Wechselentgelte entstehen auf Kundenseite Aufwände für Inventarisierung, Datenbereinigung, Zielsystem, Transformation, Tests, Parallelbetrieb und Fachabnahme. Ein Business Case sollte diese Arbeiten getrennt ausweisen, statt die gesetzliche Entgeltregel mit einer kostenlosen Gesamtmigration gleichzusetzen.

Den Exit bereits im Cloud-Vertrag ausführbar machen

Ein Exit-Abschnitt ist nur hilfreich, wenn er technisch ausführbar ist. Allgemeine Zusagen wie „Daten können exportiert werden“ reichen nicht. Benötigt werden eine Liste der exportierbaren Kategorien, Ausschlüsse, Formate, Schnittstellen, Limits, Mitwirkungsschritte, Fristen und Verantwortlichkeiten. Sicherheits- und Geschäftskontinuitätspflichten müssen während des Wechsels fortgelten.

Die Europäische Kommission hat am 19. November 2025 unverbindliche Standardvertragsklauseln für Cloud-Computing-Verträge veröffentlicht. Sie behandeln unter anderem Wechsel und Exit, Beendigung, Sicherheit und Geschäftskontinuität. Unternehmen können diese Klauseln als Prüfraster nutzen, müssen sie aber auf Dienst, Systemlandschaft und eigenen Vertrag zuschneiden.

• welche Kundendaten, Metadaten und digitalen Vermögenswerte exportierbar sind
• welche Konfigurationen, Protokolle, Rollen und Verknüpfungen enthalten oder ausgeschlossen sind
• welche Formate, APIs, Bandbreiten, Limits und Dokumentationen verfügbar sind
• wie Testexport, produktiver Export, Delta-Übernahme und Fehlerkorrektur ablaufen
• wer Sicherheit, Verfügbarkeit, Support und fachliche Freigabe während des Wechsels verantwortet
• wann Zugänge enden, Daten gelöscht werden und welche Nachweise bereitgestellt werden

Das Exit-Inventar über Datenexporte hinaus aufbauen

Der sichtbare Datenbestand ist oft nur der erste Teil. Ein SaaS-Prozess kann Dokumente, Kommentare, Statushistorien, benutzerdefinierte Felder, Rollen, Webhooks, Zeitpläne und externe Identitäten verbinden. Fehlt eine dieser Beziehungen, erscheinen Datensätze im Ziel zwar vollständig, der Prozess arbeitet aber anders oder verliert seine Nachvollziehbarkeit.

Erstellen Sie deshalb ein Exit-Inventar mit stabilen Kennungen für jedes übertragene Objekt und jede Abhängigkeit. Geheimnisse und private Schlüssel werden nicht ungeprüft exportiert; sie werden im Ziel neu erzeugt, kontrolliert hinterlegt und nach dem Cutover im Ausgangssystem widerrufen. Für jede Kategorie wird festgelegt, ob sie migriert, neu aufgebaut, archiviert oder bewusst beendet wird.

• Fachdaten, Anhänge, Versionen, Beziehungen und unveränderbare Originale
• Metadaten, Taxonomien, benutzerdefinierte Felder, Status und Aufbewahrungsregeln
• Benutzer, Rollen, Gruppen, technische Identitäten und Freigabematrizen
• APIs, Webhooks, Dateischnittstellen, Ereignisse, Zeitpläne und Wiederholungslogik
• Dashboards, Berichte, Suchindizes, Audit-Protokolle und Betriebsnachweise
• Lösch-, Archivierungs- und Stilllegungsentscheidung einschließlich Verantwortlichem

Beispielprozess: SaaS-Wechsel mit ERP-, CRM- und DMS-Anbindung

Ein Anwendungsszenario: Ein Unternehmen ersetzt einen Cloud-Dienst, der Aufträge aus dem CRM übernimmt, Belege im DMS ablegt und Buchungsinformationen an das ERP sendet. Zuerst wird ein repräsentativer Testexport in eine isolierte Annahmezone geladen. Prüfroutinen vergleichen Objektzahlen, stabile IDs, Beziehungen, Anhänge, Zeitstempel und Statushistorien. Abweichungen werden nicht in der Importlogik verborgen, sondern als begründete Transformationsregel oder fachliche Ausnahme dokumentiert.

Danach werden Zielobjekte angelegt und Schnittstellen zunächst ohne produktive Schreibwirkung verbunden. CRM-, ERP- und DMS-Teams bestätigen anhand konkreter Testfälle, dass dieselben fachlichen Zustände entstehen. Kurz vor dem Cutover folgt ein Delta-Export seit dem letzten Teststand. Während eines begrenzten Änderungsfensters werden alte Schreibwege gestoppt, das Delta eingespielt, Identitäten umgeschaltet und die neue Verarbeitung freigegeben.

Der alte Dienst wird nicht sofort gelöscht. Innerhalb der Abruffrist werden offene Vorgänge, fachliche Summen und Stichproben zwischen Quelle, Export und Ziel abgestimmt. Erst nach dokumentierter Abnahme, gesichertem Rückfallnachweis und geklärten Aufbewahrungspflichten werden Zugänge widerrufen und die vertragsgemäße Löschung angestoßen.

• 1. repräsentativen Testexport anfordern und unverändert sichern
• 2. Quellobjekte, Beziehungen und Dateianhänge maschinell sowie fachlich prüfen
• 3. Transformationen versionieren und wiederholbar ausführen
• 4. Zielsystem und Integrationen mit negativen sowie positiven Testfällen abnehmen
• 5. Delta, Schreibstopp, Cutover, Monitoring und Rückfall eindeutig terminieren
• 6. nach dem Wechsel vollständig abstimmen, dann Zugang und Löschung kontrollieren

Mit fachlichen Abnahmekriterien statt nur mit Dateizahlen testen

Gleiche Objektzahlen sind ein wichtiger, aber unzureichender Nachweis. Eine Migration kann jede Datei übertragen und trotzdem Beziehungen, Dezimalwerte, Zeitzonen, Berechtigungen oder Statusbedeutungen verändern. Abnahmekriterien müssen deshalb technische Integrität und fachliche Wirkung verbinden.

Ein früher Testexport zeigt, ob die vertraglich zugesagte Portabilität praktisch nutzbar ist. Er sollte nicht erst während der 30-tägigen Übergangsphase stattfinden. Wiederholbare Prüfungen ermöglichen, nach jeder Transformationsänderung denselben Bestand erneut zu bewerten und das Ergebnis nachvollziehbar freizugeben.

• Vollständigkeit: erwartete Objekte, Anhänge, Versionen und Beziehungen vorhanden
• Integrität: Prüfsummen, Schlüssel, Datentypen und Zeitstempel unverfälscht
• Semantik: Status, Beträge, Einheiten und Berechtigungen im Ziel gleichbedeutend
• Prozesswirkung: Import, Suche, Freigabe, Übergabe und Ausnahmeweg funktionieren
• Betrieb: Monitoring, Wiederanlauf, Sicherung und Supportweg sind einsatzbereit

In sechs Schritten zu einem belastbaren Cloud-Exit

Beginnen Sie nicht mit der Kündigung, sondern mit einem begrenzten Dienst und einem realen Testbestand. Die erste Aufgabe ist eine gemeinsame Sicht von Fachbereich, IT, Einkauf, Datenschutz, Informationssicherheit und Betrieb auf Vertrag, Daten und Abhängigkeiten. Danach lässt sich der Wechsel in überprüfbare Entscheidungspunkte zerlegen.

• 1. Anwendungsbereich, Vertragslage und Ziel des Wechsels fachkundig prüfen
• 2. Exit-Inventar mit Daten, Konfigurationen, Identitäten und Integrationen erstellen
• 3. Zielarchitektur, Verantwortlichkeiten und Abnahmekriterien festlegen
• 4. Testexport und Probemigration frühzeitig vollständig durchspielen
• 5. Delta, Cutover, Rückfall und Kommunikation verbindlich planen
• 6. innerhalb der Abruffrist abstimmen, Nachweise sichern und Löschung kontrollieren