Lock-in endet nicht mit einer Kündigung: Beim Cloud-Wechsel müssen Daten, Dienste und Betrieb mitziehen

Viele IT-Leitungen sprechen inzwischen deutlich offener über Cloud-Lock-in als noch vor wenigen Jahren. Der Grund ist nachvollziehbar: Nach der ersten Migrationswelle zeigt sich in vielen Häusern, wie eng Anwendungen, Datenpfade, Identitäten, Monitoring, Automatisierung und kommerzielle Zusagen an konkrete Plattformen gebunden wurden. Genau deshalb wird Cloud-Wechsel heute nicht mehr nur als Beschaffungsthema diskutiert, sondern als Frage von Resilienz, Verhandlungsmacht und Betriebsfähigkeit.

Mit dem EU Data Act ist daraus zusätzlich ein regulatorisch sichtbares Thema geworden. Die Europäische Kommission beschreibt die Verordnung als Regelwerk für fairen Datenzugang und Nutzerrechte, das unter anderem den Wechsel zwischen Cloud-Anbietern erleichtern und vertragliche Ungleichgewichte abbauen soll. Für Nicht-Spezialisten ist die Kernaussage einfach: Wer Datenverarbeitungsdienste nutzt, soll Anbieter nicht faktisch nur deshalb kaum wechseln können, weil Verträge, technische Hürden oder einseitige Bedingungen den Ausstieg blockieren. Relevant ist das, weil Wechsel- und Exitfähigkeit längst keine theoretische Einkaufsklausel mehr ist, sondern direkte Auswirkungen auf Kosten, Risiko und Handlungsfreiheit im IT-Betrieb hat.

Genau an dieser Stelle beginnt der operative Teil, den viele Organisationen noch unterschätzen. Ein Cloud-Wechsel scheitert selten an der Formulierung „Ausstieg möglich“. Er scheitert daran, dass Daten zwar exportiert werden könnten, aber Integrationen, Laufzeitumgebungen, Sicherheitsannahmen, Betriebsroutinen und Zuständigkeiten nicht mitgeplant wurden. Der Data Act erzeugt daher keinen magischen Umzugsbutton. Er erhöht vielmehr den Druck, Exit-Fähigkeit als echte Betriebsfähigkeit zu organisieren.

Die Verordnung macht Wechselbarkeit sichtbar, ersetzt aber keine Migrationsarchitektur

Die Kommission nennt Cloud Switching ausdrücklich als einen der neuen Regelungsbereiche des Data Act. Nutzer sollen Daten leichter übertragen und zwischen Anbietern wechseln können; zusätzlich verweist die Kommission auf ein allgemeines Ziel besserer Interoperabilität. In der begleitenden Kommunikation zum Anwendungsstart hebt sie sogar hervor, dass Cloud-Nutzer zwischen Anbietern wechseln oder mehrere Dienste parallel nutzen können sollen. Das ist fachlich wichtig, weil damit nicht nur der Exit von einem einzelnen Provider gemeint ist, sondern auch die praktische Fähigkeit, Lasten, Daten oder Teilfunktionen kontrolliert zu verlagern.

Für IT-Management und Plattformverantwortliche folgt daraus eine nüchterne Einsicht: Wechselbarkeit ist kein später Vertragsanhang, sondern ein Architekturmerkmal. Wer produktive Workloads stark an proprietäre Datenmodelle, IAM-Muster, Observability-Pfade, Messaging-Dienste oder Automatisierungslogik eines einzelnen Providers hängt, baut implizit hohe Wechselkosten auf – selbst wenn der Vertrag formal sauber aussieht. Der regulatorische Hebel macht diese Lage sichtbarer, beseitigt sie aber nicht automatisch.

Deshalb sollte jede Organisation den Begriff Portabilität neu lesen. Gemeint ist nicht nur, ob ein Datenexport als ZIP-Datei technisch möglich wäre. Gemeint ist, ob ein Service in einer anderen Umgebung mit vertretbarer Zeit, vertretbarem Risiko und vertretbarer Betriebsunterstützung weiterlaufen kann. Genau diese Dreierkombination entscheidet über reale Handlungsfreiheit.

Verträge helfen nur dann, wenn Exit und Betrieb im selben Modell gedacht werden

Besonders praktisch wird der Data Act dort, wo die Kommission zusätzliche Hilfsmittel für die Umsetzung bereitstellt. Für Cloud-Verträge wurden nicht bindende Standard Contractual Clauses entworfen, darunter Bausteine zu Switching & Exit, Termination sowie Security & Business continuity during switching. Allein diese Dreiteilung ist aufschlussreich. Sie zeigt nämlich, dass ein Anbieterwechsel nicht mit einer Kündigung endet, sondern Sicherheits- und Kontinuitätsfragen mitten in den Kern des Übergangs rücken.

Genau hier entstehen in vielen Häusern die teuren Missverständnisse. Einkauf verhandelt Kündigung, Notice Period und vielleicht noch Datenrückgabe. Der Betrieb kämpft später mit ganz anderen Fragen: Welche Logs werden wo noch benötigt? Wie lange muss ein Parallelbetrieb bestehen? Welche Runbooks, Alarmierungen und Backups müssen in der Übergangsphase doppelt gepflegt werden? Welche technischen Kontrollen bleiben bis zum letzten Tag beim Altanbieter aktiv und wer trägt in dieser Phase die Incident-Führung?

Wenn diese Fragen nicht schon vorab in dasselbe Zielbild gehören, bleibt Exit ein juristischer Vorsatz ohne operative Traktion. Sinnvoll ist deshalb, Cloud-Verträge nicht isoliert auf Preis, Laufzeit und Service Credits zu prüfen, sondern zusätzlich auf ihre Übersetzbarkeit in reale Übergabepfade. Ein guter Vertrag beantwortet nicht jedes Technikdetail. Er sollte aber den Raum dafür schaffen, dass Export, Unterstützung, Sicherheitsauflagen, Mitwirkungspflichten und geordnete Beendigung überhaupt sauber orchestriert werden können.

Datenportabilität ohne Abhängigkeitswissen produziert nur halbe Beweglichkeit

Die öffentliche Diskussion über den Data Act fokussiert verständlicherweise oft auf Daten. Das ist richtig, reicht für die Praxis aber nicht aus. Ein Datenbestand hat immer eine Umgebung: Identitäten, Schlüssel, API-Aufrufe, Batch-Läufe, Trigger, Dashboards, Rechtekonzepte, Netzpfade und Betriebswissen. Wer nur an Export denkt, übersieht die Hälfte der Migration.

Das merkt man besonders bei geschäftskritischen Plattformen. Ein Data Lake kann technisch kopiert werden, verliert aber seinen Nutzen, wenn Upstream-Quellen, Metadatenmodelle, Kataloge, Jobs und Zugriffsregeln nicht mitziehen. Ein SaaS-naher Service lässt sich vielleicht ablösen, aber die Service-Desk- oder IAM-Logik bleibt an proprietären Workflows hängen. Selbst scheinbar portable Containerlandschaften tragen häufig providernahe Abhängigkeiten in Secrets-Management, Load-Balancing, Messaging oder Managed-Datenbanken mit sich.

Für Exit-Readiness braucht es deshalb ein ehrlicheres Inventar. Welche Datenklassen sind betroffen? Welche Schnittstellen hängen daran? Welche Betriebswerkzeuge sind im Alltag unverzichtbar? Welche Kontrollen zu Logging, Security, Compliance und Backup müssen in der Zielumgebung gleichzeitig vorhanden sein? Und wo steckt stillschweigendes Wissen bei Einzelpersonen, das in keinem Architekturdiagramm auftaucht? Wer diese Punkte nicht beantwortet, verwechselt Datentransfer mit Serviceübernahme.

Business Continuity während des Wechsels ist die eigentliche Reifeprobe

Dass die Kommission in den vorgeschlagenen Vertragsbausteinen Sicherheit und Business Continuity während des Wechsels eigens adressiert, ist kein formaler Nebensatz. Genau dort entscheidet sich, ob Portabilität im Ernstfall brauchbar ist. Denn der schwierigste Moment eines Cloud-Wechsels liegt oft nicht vor oder nach der Migration, sondern dazwischen: wenn zwei Umgebungen parallel laufen, Zuständigkeiten geteilt sind und Störungen plötzlich an den Übergängen entstehen.

Dann reichen abstrakte Ausstiegsrechte nicht mehr. Der Betrieb braucht belastbare Antworten auf sehr konkrete Fragen. Wer überwacht welche Strecke im Parallelbetrieb? Welche Metriken sind führend? Wie werden Incidents klassifiziert, wenn Alt- und Zielplattform gleichzeitig betroffen sind? Wie laufen Rollback-Entscheidungen? Wer genehmigt temporäre Abweichungen bei Härtung, Netzfreigaben oder Datenreplikation? Und wie lange dürfen doppelte Kosten und doppelte Komplexität überhaupt bestehen bleiben?

Viele Organisationen behandeln Business Continuity noch immer als nachgelagerte Assurance-Schicht. Beim Cloud-Wechsel ist sie jedoch Teil der eigentlichen Migrationsmechanik. Wer keine tragfähige Kontinuitätsplanung hat, wird konservativer migrieren, länger doppelt zahlen und kritische Systeme eher auf dem Status quo lassen. Genau deshalb ist Exit-Fähigkeit immer auch ein Thema für SRE, Service Management, Security und FinOps – nicht nur für Rechtsabteilung und Einkauf.

Aus Exit-Klauseln wird erst mit Übung eine belastbare Fähigkeit

Die Kommission verweist inzwischen sogar auf einen Data Act Legal Helpdesk, bei dem Organisationen gezielt zu Themen wie Cloud Switching und Interoperabilität Fragen stellen können. Das ist hilfreich, zeigt aber auch die Realität: Viele Unternehmen stehen noch am Anfang, wenn es um die Übersetzung regulatorischer Prinzipien in einen eigenen Betriebsstandard geht.

Genau deshalb lohnt sich ein Trainingsgedanke, den man sonst eher aus Notfallmanagement oder Incident Response kennt. Exit-Fähigkeit sollte geübt werden. Nicht zwingend als kompletter Anbieterwechsel, wohl aber als kontrollierte Probe einzelner Fähigkeiten: Export eines repräsentativen Datensatzes, Wiederanlauf einer Kernfunktion in einer zweiten Umgebung, erneute Anbindung eines Identitäts- oder Monitoring-Pfads, Test des Rollbacks nach einem gezielten Umschaltfenster. Erst solche Übungen zeigen, wie viel der eigenen Wechselstrategie aus Dokumenten besteht und wie viel tatsächlich ausführbar ist.

Für IT-Leitungen ist das auch wirtschaftlich relevant. Eine geübte Exit-Option stärkt Verhandlungen, verkürzt Wiederanlaufzeiten bei strategischen Kurswechseln und reduziert das Risiko, aus Bequemlichkeit dauerhaft in suboptimalen Plattformmustern zu bleiben. Anders gesagt: Portabilität ist nicht nur ein Compliance-Wert, sondern ein Instrument gegen strukturelle Trägheit.

Worauf IT- und Sourcing-Teams jetzt konkret achten sollten

• Exit nicht nur juristisch lesen: Vertragsklauseln müssen in reale Übergabe-, Export- und Supportpfade übersetzbar sein.
• Abhängigkeiten offenlegen: Daten, Integrationen, IAM, Monitoring, Automatisierung und Betriebswissen gemeinsam kartieren.
• Parallelbetrieb vorbereiten: Incident-Führung, Metriken, Rollback und temporäre Sicherheitsausnahmen vorab definieren.
• Portabilität üben: repräsentative Exporte, Teilmigrationen und Wiederanlauf in einer zweiten Umgebung regelmäßig testen.
• Zielumgebung vollständig denken: Nicht nur Workloads verschieben, sondern auch Logging, Backup, Rechte, Compliance und Runbooks mitziehen.
• Exit als Steuerungsfähigkeit behandeln: Die Organisation sollte wissen, welche Services tatsächlich beweglich sind und welche nur auf dem Papier.

Fazit

Der Data Act macht Cloud-Wechsel zu einem deutlich sichtbareren Management- und Betriebsthema. Das ist hilfreich, weil er den Blick weg von bloßen Lock-in-Debatten hin zu faireren Wechselbedingungen, Interoperabilität und praktischer Exit-Fähigkeit verschiebt. Die eigentliche Arbeit bleibt jedoch in der Organisation selbst.

Wer Lock-in ernsthaft verringern will, muss nicht nur Vertragsrechte sichern, sondern Datenpfade, Serviceabhängigkeiten, Betriebsroutinen und Kontinuitätsplanung zusammenführen. Erst dann entsteht aus dem formalen Recht auf Wechsel eine belastbare Option im Alltag. Genau daran entscheidet sich, ob Cloud-Portabilität nur gut klingt oder im Ernstfall wirklich trägt.

Quellen

• European Commission: Data Act
• European Commission: Data Act explained
• European Commission: Draft Recommendation with model contractual terms and cloud switching standard contractual clauses
• European Commission: EU Data Act gives users control over data from connected devices
• European Commission: Data Act Legal Helpdesk