Stellen Sie sich eine einfache Frage: Könnten Sie morgen entscheiden, Ihren Cloud-Anbieter zu wechseln Vielleicht wäre die erste Antwort: grundsätzlich schon. Daten exportieren, einen neuen Anbieter auswählen, Systeme umziehen. In der Praxis beginnt an dieser Stelle allerdings meist erst die eigentliche Bestandsaufnahme.
Welche Anwendungen greifen auf proprietäre Dienste des bisherigen Providers zu? Wo liegen welche Daten? Wie sind Zugriffe und Identitäten organisiert? Welche Schnittstellen müssen angepasst werden? Ist die aktuelle Architektur vollständig dokumentiert? Und wer im Unternehmen weiß eigentlich im Detail, wie all diese Komponenten zusammenspielen?
Viele Unternehmen können ziemlich genau erklären, warum sie sich für ihre heutige Cloud-Umgebung entschieden haben. Deutlich schwieriger wird oft die Frage, wie ein Weg aus dieser Umgebung aussehen würde.
Genau deshalb lohnt es sich, über eine Exit-Strategie zu sprechen. Auch dann, wenn aktuell überhaupt kein Wechsel geplant ist.
Ein Providerwechsel wird erst dann planbar, wenn Daten, Plattformdienste, Zugriffe, Betriebsprozesse und Wissen gemeinsam betrachtet werden.
Der Cloud-Wechsel wird gerade einfacher. Zumindest auf dem Papier.
Das Thema bekommt durch den europäischen Data Act zusätzliche Aktualität. Die Verordnung gilt seit dem 12. September 2025 und soll unter anderem den Wechsel zwischen Anbietern von Datenverarbeitungsdiensten erleichtern.
Cloud-Anbieter müssen Hindernisse für einen Wechsel abbauen. Für Platform- und Software-as-a-Service-Angebote sieht der Data Act beispielsweise offene Schnittstellen und Möglichkeiten zum Export bestimmter Daten vor. Bei Infrastructure-as-a-Service-Angeboten sollen Anbieter den Wechsel zu einem vergleichbaren Dienst technisch unterstützen.
Ab dem 12. Januar 2027 dürfen Anbieter außerdem keine Gebühren mehr für den eigentlichen Wechselprozess verlangen. Dazu gehören grundsätzlich auch klassische Data-Egress-Gebühren, soweit sie im Zusammenhang mit dem Wechsel stehen.
Cloud-Abhängigkeit entsteht in mehreren Schichten. Sinnvoll wird der Blick darauf erst, wenn Daten, Dienste, Betriebsprozesse und Wissen getrennt bewertet werden.
Die Richtung ist klar: Ein Kunde soll seine Daten und Anwendungen leichter zu einem anderen Anbieter mitnehmen können.
Das ist sinnvoll. Es löst allerdings nur einen Teil des Problems.
Denn selbst wenn der bisherige Anbieter einen Wechsel technisch ermöglicht, bleibt eine entscheidende Frage offen:
Wie wechselbar ist die eigene IT-Architektur überhaupt?
Ein offener Ausgang hilft nur begrenzt, wenn hinter der Tür noch ein halbes Rechenzentrum festgeschraubt ist.
Cloud-Abhängigkeit entsteht an vielen Stellen
Beim Begriff Vendor Lock-in denken viele zuerst an Daten. Liegen große Datenmengen bei einem Anbieter, kann ihre Migration aufwendig werden.
In modernen Cloud-Umgebungen entstehen Abhängigkeiten allerdings auf mehreren Ebenen.
Eine Anwendung kann beispielsweise Dienste verwenden, die eng mit dem jeweiligen Cloud-Ökosystem verbunden sind. Datenbanken, Serverless Functions, Identity Services oder Monitoring-Lösungen sparen im täglichen Betrieb erheblichen Aufwand. Bei einem Wechsel müssen diese Komponenten möglicherweise ersetzt oder neu aufgebaut werden.
Hinzu kommt die Betriebslogik. Backups, Sicherheitsmechanismen und Automatisierungen entwickeln sich häufig über Jahre innerhalb einer Plattform weiter. Ein erheblicher Teil dieser Umgebung steckt irgendwann in Konfigurationen, Skripten und Betriebsprozessen.
Und schließlich gibt es eine Abhängigkeit, die leicht übersehen wird: Wissen.
Eine Exit-Strategie ist kein zweites Migrationsprojekt. Sie schafft Transparenz darüber, was bei einem Wechsel passieren würde und welche Schritte vorbereitet sein sollten.
Vielleicht kennt ein interner Administrator die Umgebung sehr gut. Vielleicht liegt das entscheidende Know-how bei einem externen Dienstleister. Vielleicht funktioniert ein System seit Jahren zuverlässig, während die Dokumentation längst nicht mehr Schritt gehalten hat.
All das ist zunächst einmal normal.
Wer die Möglichkeiten einer Cloud-Plattform nutzt, schafft zwangsläufig Bindungen. Viele dieser Bindungen sind sogar wirtschaftlich sinnvoll. Ein Unternehmen muss nicht auf einen hilfreichen Managed Service verzichten, nur weil dessen Migration eines Tages Aufwand verursachen könnte.
Entscheidend ist, diese Abhängigkeiten zu kennen und bewusst zu bewerten.
Wie teuer ist die Freiheit, jederzeit wechseln zu können?
Theoretisch ließe sich eine Cloud-Architektur so gestalten, dass möglichst viele Komponenten jederzeit auf einen anderen Anbieter übertragen werden können.
In der Praxis wäre das häufig eine schlechte Entscheidung.
Wer jeden proprietären Dienst vermeidet, jede Anwendung vollständig abstrahiert und für mehrere Plattformen parallel vorbereitet, bezahlt diese Flexibilität mit zusätzlicher Komplexität, Entwicklungsaufwand und Betriebskosten. Jede Abhängigkeit vermeiden sollte auch gar nicht das Ziel sein. Es reicht, sich zu fragen:
„Welche Abhängigkeiten gehen wir bewusst ein und was würde es kosten, sie später aufzulösen?“
Damit verändert sich auch die Perspektive auf Vendor Lock-in.
Eine starke Bindung an einen Anbieter kann vollkommen vertretbar sein, wenn sie deutliche Vorteile bringt und das Unternehmen die Konsequenzen kennt. Problematisch wird es dort, wo Abhängigkeiten über Jahre wachsen, ohne dass sie noch jemand vollständig überblickt.
Dann entsteht aus einer technischen Entscheidung irgendwann eine strategische Einschränkung.
Multi-Cloud kann strategisch sinnvoll sein. Als pauschale Versicherung gegen Vendor Lock-in funktioniert sie jedoch nur dann, wenn zusätzliche Plattformen nicht selbst neue unübersichtliche Abhängigkeiten erzeugen.
Eine Exit-Strategie beginnt lange vor dem Exit
Eine gute Exit-Strategie besteht deshalb auch nicht aus einem Dokument, das irgendwo für den Ernstfall abgelegt wird, sondern im laufenden Betrieb.
Wenn neue Cloud-Dienste eingeführt werden, sollte beispielsweise klar sein, welche Rolle sie übernehmen und wie stark die Anwendung dadurch an den jeweiligen Anbieter gebunden wird. Bei kritischen Systemen kann es sinnvoll sein, mögliche Alternativen bereits zu kennen.
Architektur und Konfiguration sollten so dokumentiert sein, dass sie auch von jemandem verstanden werden können, der die Umgebung nicht selbst aufgebaut hat.
Und beim Thema Daten reicht die theoretische Möglichkeit eines Exports kaum aus. Entscheidend ist, ob die exportierten Daten tatsächlich vollständig, aktuell und in einer Form verfügbar wären, mit der ein anderes System etwas anfangen kann.
Das alles bedeutet nicht, dass Unternehmen permanent ihre Cloud-Migration vorbereiten sollten.
Es bedeutet, dass sie einen realistischen Überblick darüber haben sollten, was passieren würde, wenn eine Migration irgendwann notwendig wird.
Ein Providerwechsel wird oft durch Veränderungen außerhalb der eigentlichen Cloud-Plattform relevant. Eine Exit-Strategie sorgt dafür, dass das Unternehmen auch dann handlungsfähig bleibt.
Genau das verstehen wir bei BW.Tech unter Cloud by Design: Cloud-Infrastruktur wird kontinuierlich geplant und weiterentwickelt. Dabei gehört auch der Blick auf Abhängigkeiten und mögliche zukünftige Wege zur Architektur.
Denn auch eine gut geplante Cloud-Umgebung verändert sich. Neue Anwendungen kommen hinzu. Teams wechseln. Dienste werden erweitert. Aus einer ursprünglich überschaubaren Architektur kann über mehrere Jahre eine ziemlich komplexe Landschaft entstehen.
Cloud by Design heißt deshalb auch, diese Komplexität regelmäßig wieder einzuhegen und einen Fahrplan dafür zu haben.
Fünf Fragen für einen ersten Exit-Check
Für eine erste Einschätzung braucht es kein großes Migrationsprojekt. Ein Gespräch zwischen Geschäftsführung, IT-Verantwortlichen und gegebenenfalls dem betreuenden Dienstleister kann bereits viel sichtbar machen.
Fünf Fragen sind dafür besonders hilfreich:
1. Welche Systeme und Daten wären von einem Providerwechsel betroffen?
Klingt banal, ist aber die Grundlage. Dazu gehören auch Schnittstellen zu SaaS-Lösungen, Identitätsdienste und angebundene Anwendungen.
2. Wo liegen unsere stärksten Abhängigkeiten?
Welche Dienste lassen sich relativ einfach ersetzen? Wo wäre eine Migration technisch komplex? Welche Anwendungen hängen besonders tief im Ökosystem des Providers?
3. Ist unsere Umgebung ausreichend dokumentiert?
Kann ein Dritter nachvollziehen, wie Systeme aufgebaut, konfiguriert und miteinander verbunden sind?
4. Kommen wir tatsächlich an unsere Daten?
Es lohnt sich, Datenexporte und Backups gelegentlich praktisch zu prüfen. Entscheidend ist, ob sich die Daten anschließend auch sinnvoll weiterverwenden beziehungsweise wiederherstellen lassen.
5. Haben wir eine Vorstellung vom Aufwand eines Wechsels?
Dabei braucht es keine Kalkulation auf den Euro genau. Schon eine grobe Einordnung ist wertvoll: Reden wir über einige Wochen? Mehrere Monate? Müssten Anwendungen teilweise neu entwickelt werden? Welche Systeme wären besonders kritisch?
Wer diese Fragen beantworten kann, hat bereits einen großen Teil dessen erreicht, was eine Exit-Strategie leisten soll: Transparenz.
Die richtige Antwort muss nicht „ja“ sein
Also noch einmal zurück zur Ausgangsfrage:
Könnten Sie morgen Ihren Cloud-Anbieter wechseln?
Für die meisten Unternehmen lautet die vernünftige Antwort wahrscheinlich: Nein. Zumindest nicht ohne erheblichen Aufwand.
Das ist vollkommen in Ordnung.
Spannender ist, ob Sie sagen können:
Wir wissen, was bei einem Wechsel betroffen wäre. Wir kennen unsere wichtigsten Abhängigkeiten. Und wir haben eine Vorstellung davon, wie der Weg aussehen würde.
Dann ist die eigene Cloud-Umgebung vielleicht nicht jederzeit austauschbar.
Aber das Unternehmen bleibt handlungsfähig.
Und genau darum geht es am Ende bei einer guten Cloud-Strategie.
Über den Autor
Frank Böttcher ist COO und Geschäftsführer von BW.Tech. Als Betreiber eines deutschen Hochverfügbarkeits-Rechenzentrum steht für ihn sichere Datenhaltung an der Tagesordnung.
