Cloud-Exit beginnt vor der Vertragsunterschrift

Ein Anbieter verspricht, dass Daten jederzeit exportiert werden können. Das klingt nach Unabhängigkeit. Beim späteren Wechsel zeigt sich jedoch: Der Export enthält Stammdaten, aber keine Freigabeverläufe, Rollen, Anhänge oder Schnittstellenkonfigurationen. Die Dateien sind vorhanden, der Geschäftsbetrieb lässt sich daraus trotzdem nicht wiederherstellen.

Cloud-Exit ist deshalb mehr als Datenexport. Er beschreibt die Fähigkeit, einen Dienst kontrolliert zu beenden, zu einem anderen Anbieter zu wechseln oder eine Leistung in eine eigene Umgebung zu überführen, ohne dass ein unvertretbarer Betriebs-, Daten- oder Nachweisverlust entsteht.

Diese Fähigkeit lässt sich nicht sinnvoll erst bei der Kündigung beschaffen. Verhandlungsspielraum, technisches Wissen und verfügbare Ansprechpartner sind vor Vertragsabschluss meist besser. Der Exit gehört daher in dieselbe Entscheidung wie Leistungsumfang, Sicherheit, Preis und Einführung.

Der Exit braucht einen Zielzustand

„Wir kommen wieder heraus“ ist kein prüfbares Ziel. Zuerst ist festzulegen, was nach dem Ende des Dienstes funktionieren soll:

• Soll der Prozess bei einem anderen Anbieter weiterlaufen?
• Reicht eine geordnete Archivierung, weil die Leistung entfällt?
• Muss ein Notbetrieb während einer ungeplanten Beendigung möglich sein?
• Welche historischen Daten und Nachweise müssen weiter verfügbar bleiben?
• Welche Integrationen, Identitäten und Berechtigungen müssen im Ziel neu aufgebaut werden?
• Wie lange darf der Geschäftsbetrieb eingeschränkt sein?
• Welcher Datenstand ist im ungünstigen Fall noch akzeptabel?

Der Zielzustand bestimmt Tiefe und Kosten der Vorsorge. Für ein austauschbares Hilfswerkzeug kann ein dokumentierter Export genügen. Bei einem geschäftskritischen Kernprozess braucht es möglicherweise eine vorbereitete Migrationsstrecke, regelmäßige Sicherungen außerhalb des Dienstes und einen zeitlich begrenzten Ersatzbetrieb.

Die BSI-Empfehlungen zur Cloud-Exit-Strategie betonen die frühzeitige Planung und die Aufrechterhaltung der Handlungsfähigkeit. Das Dokument macht deutlich, dass Daten, Anwendungen, Konfigurationen, Verträge und organisatorische Maßnahmen gemeinsam betrachtet werden müssen.

Planmäßiger Wechsel und ungeplanter Ausfall sind verschieden

Ein reguläres Vertragsende bietet Fristen, Ansprechpartner und einen laufenden Dienst. Eine außerordentliche Kündigung, Insolvenz, Sicherheitskrise oder schwerwiegende Leistungsstörung kann diese Voraussetzungen verändern.

Eine Exit-Strategie sollte deshalb mindestens zwei Wege unterscheiden:

Weg	Typische Voraussetzung	Schwerpunkt
geplanter Exit	Dienst und Anbieter wirken während der Übergangsfrist mit	vollständige Migration, kontrollierte Umschaltung, Abnahme und Löschung
ungeplanter Exit	Unterstützung, Zugriff oder Betriebsfähigkeit können eingeschränkt sein	eigene aktuelle Kopien, Notbetrieb, priorisierte Kernfunktionen und schnelle Entscheidungswege

Nicht jedes denkbare Scheitern kann wirtschaftlich vollständig abgesichert werden. Aber wenn die Strategie ausschließlich unter idealer Mitwirkung des bisherigen Anbieters funktioniert, ist sie kein belastbarer Notfallweg.

Portierbar sein müssen Daten und Bedeutung

Eine Liste exportierbarer Tabellen reicht nicht. Entscheidend ist, ob die Organisation die Informationen im Ziel fachlich und technisch wieder nutzbar machen kann.

Zu prüfen sind mindestens:

• Stamm-, Bewegungs- und Verlaufsdaten,
• Dokumente, Anhänge und unveränderbare Nachweise,
• fachliche Beziehungen, Schlüssel und Statuswerte,
• Benutzer, Rollen und Berechtigungszuordnungen,
• Konfigurationen, Regeln, Workflows und Vorlagen,
• Schnittstellen, Ereignisse, Schlüssel und technische Abhängigkeiten,
• Protokolle, Aufbewahrungsinformationen und Audit-Trails,
• Datenformate, Schemata, Dokumentation und notwendige Werkzeuge.

Ein proprietäres Format ist nicht automatisch unbrauchbar, und ein offenes Format nicht automatisch migrierbar. Entscheidend ist, ob Struktur und Semantik ausreichend dokumentiert sind und ob das Zielsystem sie mit vertretbarem Aufwand übernehmen kann.

ISO/IEC 19941:2017 behandelt Begriffe und Schnittstellen rund um Cloud-Interoperabilität und -Portabilität. Die ISO weist die Ausgabe zum Abrufzeitpunkt als in Überarbeitung aus. Für eine konkrete Beschaffung ist daher der aktuelle Stand zu prüfen; als Grundgedanke bleibt die Trennung hilfreich: Datenübertragbarkeit allein stellt noch keine funktionale Austauschbarkeit eines Dienstes her.

Architektur bestimmt die tatsächliche Bindung

Lock-in entsteht nicht nur durch Vertragsklauseln. Er kann in der eigenen Architektur wachsen:

• Geschäftslogik liegt ausschließlich in anbieterspezifischen Workflows.
• Identitäten und Rollen sind nicht dokumentiert oder übertragbar.
• Andere Systeme greifen direkt auf proprietäre Funktionen zu.
• Daten werden nur im Dienst gesichert.
• Wissen über Konfigurationen liegt beim Anbieter oder einer einzelnen Person.
• Der Wechsel setzt gleichzeitige Änderungen an vielen Schnittstellen voraus.

Deshalb sollten Architekturprinzipien festlegen, bei welchen Services Portabilität, offene Schnittstellen, eigene Datenkopien oder eine entkoppelte Integrationsschicht wichtig sind. Das Ziel ist nicht, jeden Cloud-Vorteil zu vermeiden. Es ist, Bindung bewusst gegen Nutzen und Wechselkosten abzuwägen.

Der Vertrag muss die Übergangsphase regeln

Ein technisch möglicher Exit kann an Zeit, Kosten oder fehlender Mitwirkung scheitern. Vor der Unterschrift sollten daher konkrete Bedingungen geklärt werden:

• Kündigungs- und Übergangsfristen,
• Dauer des Zugriffs nach Kündigung,
• Umfang, Format und Häufigkeit von Exporten,
• Unterstützung bei Migration und Übergabe,
• Preise, Tagessätze und Obergrenzen für Exit-Leistungen,
• Weiterbetrieb und Servicequalität während der Migration,
• Herausgabe von Dokumentation, Konfiguration und Nachweisen,
• Umgang mit Unterauftragnehmern,
• Löschung von Produktivdaten, Kopien, Backups und Metadaten,
• Form und Zeitpunkt eines Lösch- oder Übergabenachweises.

Pauschale Formulierungen wie „marktübliche Unterstützung“ oder „Export auf Anfrage“ lassen wesentliche Unsicherheit beim Kunden. Eine Exit-Klausel sollte Leistungen, Verantwortungen, Formate und Zeitfenster so weit konkretisieren, dass sie kalkulierbar und prüfbar werden.

Der EU Data Act enthält in Kapitel VI Regeln für den Wechsel zwischen Datenverarbeitungsdiensten in seinem sachlichen Anwendungsbereich. Laut Europäischer Kommission gilt die Verordnung seit dem 12. September 2025. Diese Einordnung entspricht dem Abrufstand 8. August 2026; laufende Gesetzgebung und die Anwendbarkeit auf einen konkreten Vertrag müssen aktuell geprüft werden. Der Beitrag ersetzt keine rechtliche Beratung. Eine belastbare Exit-Strategie sollte sich außerdem nicht allein auf gesetzliche Mindestansprüche verlassen, sondern den betrieblich notwendigen Übergang ausdrücklich vereinbaren.

Konstruiertes Beispiel: Exportierbare Daten, nicht exportierbarer Service

Das folgende Beispiel ist konstruiert.

Ein Unternehmen möchte eine SaaS-Anwendung ablösen. Der Vertrag nennt einen Datenexport, und der Anbieter liefert CSV-Dateien mit Kunden- und Auftragsstammdaten. Beim Migrationsprojekt fehlen jedoch Anhänge, Freigabeverläufe, historische Rollen, Schnittstellenkonfigurationen und die Zuordnung fachlicher Statuswerte.

Die Datenmenge ist nicht das Hauptproblem. Dem Zielsystem fehlt die Bedeutung, die den laufenden Prozess und seine Nachweise ausmacht. Teile müssen manuell rekonstruiert werden, während der alte Vertrag länger als geplant weiterläuft.

Vor Vertragsabschluss hätte eine konkrete Exit-Probe andere Fragen ausgelöst: Welche Objekte umfasst der Export? Wie werden Beziehungen und Historie dargestellt? Lassen sich Rollen und Workflows dokumentieren? Welche Unterstützung ist im Preis enthalten? Ein kleiner Test hätte die Lücke sichtbar gemacht, bevor Zeitdruck entstand.

Die Exit-Karte als Teil der Beschaffung

Eine knappe Exit-Karte zwingt Anbieter und Auftraggeber zu überprüfbaren Aussagen.

Feld	Inhalt
Auslöser	reguläres Ende, Leistungsstörung, Insolvenz, Strategie- oder Rechtsänderung
Zielzustand	Ersatzdienst, Eigenbetrieb, Archiv oder kontrollierte Abschaltung
kritische Funktionen	Leistungen, die im Übergang erhalten bleiben müssen
Exportumfang	Daten, Historie, Dokumente, Konfigurationen, Rollen und Protokolle
Format und Semantik	Schema, Dokumentation, Schlüssel, Beziehungen und Lesewerkzeuge
Abhängigkeiten	Identitäten, Schnittstellen, Domains, Schlüssel, Geräte und Dienstleister
Übergangsleistung	Mitwirkung, Ansprechpartner, Fristen, Parallelbetrieb und Kosten
eigene Vorsorge	Kopien, Dokumentation, Kompetenzen und Notbetrieb außerhalb des Dienstes
Löschung	Umfang, Termin, Unterauftragnehmer und Nachweis
Test	Probeexport, Zielprüfung, Abweichungen und nächster Termin
Owner und Entscheidung	fachliche, technische, kaufmännische und rechtliche Verantwortung

Die Karte ergänzt eine Make-or-Buy-Entscheidung um die Rückrichtung. Beschaffung betrachtet dann nicht nur, wie die Leistung übernommen wird, sondern auch, wie die Organisation ihre Handlungsfähigkeit später zurückgewinnt.

Ein Exporttest muss auf der Zielseite enden

Die erfolgreiche Erzeugung einer Datei beweist nur, dass der Exportknopf funktioniert. Ein sinnvoller Test prüft stichprobenartig:

1. Kann eine befugte Rolle den Export ohne Sonderprojekt auslösen?
2. Sind Umfang, Format und Erstellungsdauer wie vereinbart?
3. Lassen sich Dateien unabhängig vom Quelldienst öffnen und verarbeiten?
4. Stimmen relevante Objektzahlen, Beziehungen und Prüfsummen?
5. Sind Historie, Anhänge, Rollen und Konfigurationen enthalten oder anderweitig dokumentiert?
6. Kann ein Ziel oder Prototyp die wichtigsten Geschäftsvorgänge rekonstruieren?
7. Welche manuellen Schritte und Anbieterleistungen bleiben notwendig?
8. Werden Abweichungen vertraglich, technisch oder organisatorisch bearbeitet?

Nicht jeder Test muss eine vollständige Migration durchführen. Seine Tiefe richtet sich nach Kritikalität, Datenvolumen, Änderungsrate, Individualisierung und realistischer Wiederbeschaffungszeit. Bei einem kritischen Service ist ein ungeprüfter Exportversprechung jedoch zu wenig.

Exit-Fähigkeit braucht einen Owner und einen Lebenszyklus

Die beste Klausel veraltet, wenn neue Module, Schnittstellen und Datenarten hinzukommen. Deshalb muss ein Owner bei wesentlichen Änderungen prüfen, ob Export, Dokumentation, Zielbild und Kosten noch passen.

Geeignete Auslöser sind:

• Vertragsverlängerung oder größere Preisänderung,
• Einführung eines neuen Moduls,
• neue kritische Schnittstellen oder Datenarten,
• Änderung der Unterauftragnehmer oder Betriebsregion,
• erhebliche Individualisierung,
• veränderte Kritikalität des unterstützten Geschäftsprozesses,
• angekündigtes Support- oder Produktende.

Damit wird Cloud-Exit Teil von Roadmap und Lifecycle-Management, nicht eine einmalig abgelegte Beschaffungsanlage.

Der pragmatische Start ist der wichtigste bestehende Cloud-Service. Fordern Sie einen aktuellen Export an und vergleichen Sie ihn mit dem fachlichen Ziel: Könnte ein kompetentes Team daraus Daten, Nachweise und Kernprozess wieder aufbauen? Jede nicht beantwortete Lücke kommt mit Owner, Vertragstermin oder technischem Test auf die Exit-Karte. Bei der nächsten Beschaffung wird diese Karte vor der Unterschrift ausgefüllt – solange Wahlmöglichkeiten und Verhandlungsspielraum noch vorhanden sind.