Beim Cloud-Wechsel entscheidet der Rückweg

Ein Cloud-Wechsel wirkt auf dem Papier oft wie eine Vertragsfrage. Im Betrieb entscheidet aber der Rückweg: Welche Daten müssen raus, welche Schnittstellen ziehen mit, wer testet die neue Umgebung und was passiert während der Übergabe mit laufenden Services?

Der EU Data Act ist eine europäische Verordnung, die unter anderem den Wechsel zwischen Cloud- und Datenverarbeitungsdiensten erleichtern soll. Für Nicht-Juristen heißt das: Anbieter sollen Kunden nicht unnötig festhalten, Daten sollen besser übertragbar sein und Wechselhindernisse sollen sinken. Für ITSM-Generalisten ist daran weniger der Paragraf spannend als die Betriebsfrage dahinter. Ein rechtlicher Wechselanspruch hilft wenig, sobald Daten, Identitäten, Protokolle, Backups und Fachprozesse nicht sauber dokumentiert sind.

Der Data Act gilt seit September 2025 in wesentlichen Teilen. Die Europäische Kommission beschreibt ihn als Baustein für mehr Fairness beim Zugang zu Daten und für einfachere Wechsel zwischen Datenverarbeitungsdiensten. Die Verordnung selbst enthält Pflichten rund um Wechsel, Datenexport und Interoperabilität. Daraus entsteht kein automatischer Migrationsplan. Der Betrieb muss den Wechsel so vorbereiten, dass Servicequalität, Nachweise und Verantwortlichkeiten nicht erst beim Ausstieg sichtbar werden.

Vertragliche Freiheit ist noch kein Betriebsweg

Cloud-Dienste werden selten als einzelne Insel genutzt. Hinter einem Dienst hängen Identitätsprovider, Rechte, Schnittstellen, Monitoring, Kostenstellen, Protokolle, Supportprozesse, Datenablagen, Automationen und manchmal auch Fachprozesse, die niemand mehr als Cloud-Abhängigkeit erkennt. Genau deshalb ist der Ausstieg aus einem Dienst oft schwieriger als seine Einführung.

Ein Vertrag kann regeln, dass Daten exportiert werden dürfen. Er beantwortet aber nicht automatisch, welches Datenformat wirklich nutzbar ist, welche Metadaten erhalten bleiben, wie lange ein Exportfenster dauert oder wie ein Fachbereich während der Umstellung weiterarbeitet. Auch Rollen und Berechtigungen lassen sich nicht immer sauber mitnehmen. Was technisch als Download erscheint, kann im Betrieb ein komplettes Wiederanlaufprojekt werden.

ITSM muss diese Lücke sichtbar machen. Wer Cloud-Wechsel nur als Einkaufs- oder Rechtsfrage behandelt, findet die eigentlichen Risiken zu spät. Der Servicekatalog muss zeigen, welche Cloud-Dienste geschäftskritisch sind, welche Nutzergruppen betroffen wären und welche Abhängigkeiten bei einem Anbieterwechsel mitwandern müssen. Ohne diese Sicht wird der Rückweg erst dann gesucht, wenn Druck entsteht.

Exit-Pläne gehören in den Servicebetrieb

Ein brauchbarer Exit-Plan beginnt nicht am Kündigungstag. Er gehört schon in die Betriebsdokumentation eines Services. Dazu zählen Datenarten, Exportwege, Schnittstellen, Identitäten, Aufbewahrungsfristen, Fachowner, technische Owner, Testumgebung, Rückfalloption und ein realistisches Zeitfenster. Wichtig ist auch die Frage, welche Informationen nur im alten System sinnvoll lesbar sind.

Besonders kritisch sind unscheinbare Zusatzfunktionen. Kommentare, Freigaben, Historien, Automationsregeln, Benachrichtigungen oder integrierte Workflows werden beim Export leicht übersehen. Für den Fachbereich können genau diese Details entscheidend sein. Ein Dienst ist nicht migriert, nur weil Rohdaten übertragen wurden. Er ist erst migriert, wenn Arbeit, Nachweis und Support wieder funktionieren.

Der Betrieb sollte deshalb für wichtige Cloud-Services eine einfache Wechselakte führen. Sie muss keine juristische Abhandlung sein. Sie muss beantworten, wie ein Wechsel praktisch abläuft, wer entscheidet, welche Daten betroffen sind, welche Tests nötig sind und welche Risiken im Service Desk ankommen. Diese Akte gehört neben SLA, Supportmodell und Notfallinformationen.

Der Service Desk merkt fehlende Übergaben zuerst

Bei einem Cloud-Wechsel entstehen Störungen selten nur in der Zielplattform. Nutzer finden alte Links nicht mehr, Berechtigungen greifen anders, automatische E-Mails verändern sich, Reports fehlen, Integrationen liefern verzögert oder ein Fachbereich sucht historische Daten. Wenn der Service Desk diese Übergabe nicht kennt, wird aus einem geplanten Wechsel eine Serie unklarer Tickets.

Darum braucht der Support vor dem Wechsel eine verständliche Übergabe. Welche Funktionen ändern sich sichtbar? Welche Fehlerbilder sind erwartbar? Welche alten Links oder Zugänge laufen aus? Welche Fragen gehören sofort zum Fachowner, welche zur Technik und welche zum Lieferanten? Ein Cloud-Wechsel ohne Supportbriefing spart keine Arbeit. Er verschiebt sie nur in den laufenden Betrieb.

Auch Kommunikation gehört dazu. Nutzer müssen nicht jeden Vertragsgrund kennen. Sie müssen aber wissen, wann ein Dienst umzieht, was sich für ihre Arbeit ändert und wo sie Hilfe bekommen. Gerade bei Diensten mit vielen Gelegenheitsnutzern entscheidet diese Vorbereitung darüber, ob ein Wechsel als kontrollierter Betriebsvorgang oder als überraschender Ausfall wahrgenommen wird.

Interoperabilität braucht Tests statt Hoffnung

Interoperabilität klingt nach technischer Anschlussfähigkeit. In der Praxis muss sie getestet werden. Ein Exportformat kann formal offen sein und trotzdem Daten verlieren, Felder anders interpretieren oder Workflows brechen. Ein neues System kann Schnittstellen anbieten und dennoch andere Grenzwerte, Rollenmodelle oder Protokollformate nutzen. Genau hier entsteht die Aufgabe für Change Management und Testplanung.

Ein guter Test prüft nicht nur, ob Daten ankommen. Er prüft die wichtigsten Arbeitsschritte nach der Übernahme. Kann ein Nutzer suchen, freigeben, berichten und eskalieren? Stimmen Berechtigungen und Auditspuren? Funktionieren Schnittstellen mit angrenzenden Systemen? Sind Lösch- und Aufbewahrungsregeln nachvollziehbar? Erst diese Fragen zeigen, ob ein Cloud-Wechsel betrieblich tragfähig ist.

Für kritische Services sollte es mindestens einen Probexport und eine kleine Wiederherstellungsübung geben. Das muss nicht sofort eine vollständige Migration sein. Es reicht oft schon, die harten Stellen sichtbar zu machen: Datenvolumen, Formatgrenzen, fehlende Metadaten, unklare Owner, lange Durchlaufzeiten oder manuelle Nacharbeit. Diese Erkenntnisse sind wertvoller als ein beruhigender Satz im Vertrag.

Einkauf, Recht und Betrieb brauchen dieselbe Checkliste

Der wichtigste Effekt des Data Act für IT-Organisationen kann ein neuer Gesprächsanlass sein. Einkauf und Recht fragen nach Vertragsbedingungen, Wechselgebühren und Pflichten. Der Betrieb fragt nach Export, Test, Support, Monitoring und Rückfall. Beides muss zusammenkommen. Sonst wird ein formal besserer Wechselrahmen nicht automatisch zu einem besseren Betriebszustand.

Für neue Cloud-Beschaffungen sollte die Checkliste deshalb wenige klare Punkte enthalten. Wie verlassen wir den Dienst wieder? Welche Daten und Metadaten bekommen wir zurück? Wie wird ein Probexport getestet? Welche Schnittstellen sind dokumentiert? Wie lange unterstützt der Anbieter die Übergabe? Welche Kosten, Fristen und technischen Grenzen sind bekannt? Wer hält diese Informationen im Servicekatalog aktuell?

Beim Cloud-Wechsel entscheidet der Rückweg, weil er die tatsächliche Betriebsreife zeigt. Ein Dienst ist nicht nur dann gut eingeführt, wenn Nutzer ihn starten können. Er ist erst dann sauber beherrscht, wenn die Organisation ihn ändern, prüfen, ersetzen und geordnet verlassen kann. Genau dort wird aus Regulierung ein praktischer ITSM-Auftrag.

Quellen und Einordnung: Europäische Kommission zum Data Act und zur Erklärung des Data Act, EU-Verordnung 2023/2854 im Amtsblatt. Stand der Quellenprüfung 23.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.