Wer die ersten Teile dieser Serie gelesen hat, weiß: Cloud Exit ist kein Nischenthema mehr. Die Regulatorik ist eindeutig, die Abhängigkeiten von Cloud-Anbietern sind real und die Frage, ob das eigene Unternehmen vorbereitet ist, lässt sich nicht länger vertagen.
Aber hier setzt häufig ein Reflexmuster ein, das in IT-Führungskreisen weit verbreitet ist: Das Thema wird als so komplex, so politisch beladen und so ressourcenintensiv wahrgenommen, dass der erste Schritt nie gemacht wird. Man wartet auf die richtige Strategie, das richtige Budget, den richtigen Moment.
Die gute Nachricht: Exit-Readiness lässt sich in Etappen aufbauen. Ohne den Betrieb zu stören. Ohne Millionenbudgets. Ohne die politische Grundsatzdiskussion, ob man Microsoft nun verlassen will oder nicht. Es geht nicht darum, einen Ausstieg zu planen, es geht darum, handlungsfähig zu sein, falls er nötig wird.
Und der erste Schritt ist einfacher, als die meisten denken.
Keine Zeit zum Lesen?
Dann hören Sie sich den Beitrag einfach an. Unsere Hörversion, gesprochen von unserem KI-Assistenten Paul, vermittelt Ihnen die wichtigsten Inhalte kompakt und verständlich – ideal für unterwegs oder zwischendurch.
Exit-Readiness ist kein binärer Zustand, entweder vorbereitet oder nicht. Sie ist ein Reifegrad, der in drei aufeinander aufbauenden Stufen entwickelt werden kann. Jede Stufe hat einen eigenständigen Wert, auch ohne die nächste.
Das Ziel: Ein vollständiges, aktuelles Bild aller Microsoft-Dienste, Datenbestände und Prozessabhängigkeiten im eigenen Unternehmen.
Das klingt selbstverständlich. In der Praxis ist es das fast nie. Die meisten Unternehmen haben kein vollständiges Bild davon, welche Microsoft-Dienste in welchen Geschäftsbereichen aktiv genutzt werden, geschweige denn, welche Daten wo liegen, welche Prozesse davon abhängen und was eine Migration konkret bedeuten würde.
Sichtbarkeit ist die Grundlage für alles, was folgt. Wer nicht weiß, was er hat, kann es nicht schützen, nicht portabilisieren und nicht ersetzen.
Konkrete Maßnahmen für Stufe 1:
Service-Inventarisierung: Erstellen Sie eine vollständige Liste aller genutzten Microsoft-Dienste, über alle Geschäftsbereiche hinweg, inkl. Schatten-IT. Strukturieren Sie nach Dienst, Nutzergruppe, Geschäftsprozess und Kritikalität. Für eine mittelgroße Organisation ist das ein 1–2-tägiger Workshop, kein Großprojekt.
Datenkartierung: Für jeden identifizierten Dienst: Welche Daten liegen dort? Welches Format? Welches Volumen? Wie lange werden sie aufbewahrt? Gibt es Exportmöglichkeiten und in welcher Qualität? Priorisieren Sie nach Geschäftskritikalität, denn nicht jeder SharePoint-Ordner hat strategische Bedeutung.
Prozessabhängigkeitsanalyse: Welche Geschäftsprozesse laufen über welche Microsoft-Dienste und wie tief ist die Einbettung? Ein Genehmigungsprozess, der über Power Automate läuft und SharePoint als Datenbasis nutzt, hat eine andere Abhängigkeitstiefe als ein Teams-Meeting für den wöchentlichen Jour fixe.
Technologieinventur: Welche Integrationen, APIs und Automatisierungen bestehen zwischen Microsoft-Diensten und anderen Systemen im Unternehmen? Diese Punkt-zu-Punkt-Verbindungen sind oft die unsichtbarsten, aber folgenreichsten Abhängigkeiten.
Aufwand/Nutzen: Hoch. Diese Stufe kostet vergleichsweise wenig. Ein strukturierter Workshop, ein dediziertes Tool oder die Erweiterung einer bestehenden CMDB. Es liefert sofort einen Mehrwert: für das Risikomanagement, für Audit-Gespräche, für interne IT-Governance. Sie ist auch ohne jede Exit-Absicht sinnvoll.
Das Ziel: Sicherstellen, dass Daten und Prozesse im Ernstfall tatsächlich aus dem Microsoft-Ökosystem herausgelöst werden können. Strukturiert, vollständig und in vertretbarer Zeit.
Portabilität ist nicht dasselbe wie Export. Export bedeutet: Sie können eine Datei herunterladen. Portabilität bedeutet: Sie können eine Datei herunterladen, in einem anderen System nutzbar machen, ohne Funktionsverlust weiterarbeiten und das für alle kritischen Datenbestände und Prozesse innerhalb eines definierten Zeitrahmens.
Das ist ein deutlich höherer Anspruch. Und er erfordert aktive Gestaltungsarbeit.
Konkrete Maßnahmen für Stufe 2:
Export-Prozesse definieren und testen: Legen Sie für jeden kritischen Dienst fest, wie ein Datenexport aussieht – und testen Sie ihn. Nicht theoretisch, sondern praktisch. Ein E-Mail-Export aus Exchange Online, ein vollständiger SharePoint-Export mit Metadaten und Versionierungen, ein Teams-Export via Compliance-Center – all das muss einmal durchgespielt werden. Ungetestetem Exodus vertraut kein Auditor, und er sollte Ihnen selbst auch nicht vertrauen. Ein Exit-Prozess, der nie praktisch erprobt wurde, ist weder audit-tauglich noch als Grundlage für die eigene Risikosteuerung verlässlich.
Datenformate bewusst wählen: Wo immer möglich, setzen Sie auf offene, standardisierte Formate. Dokumente als DOCX statt proprietärer SharePoint-Strukturen. Datenbanken mit offenen Schemas statt Azure-nativer Dienste ohne Exportäquivalent. Diese Entscheidungen kosten nichts – wenn man sie früh trifft.
Automatisierungen und Workflows dokumentieren: Power-Automate-Flows, SharePoint-Workflows und Logic Apps sind selten dokumentiert. Dabei sind sie oft geschäftskritisch und bei einem Exit neu zu bauen. Dokumentation ist hier der erste Schritt zur Portabilität – sie macht sichtbar, was existiert, und ermöglicht eine Neuimplementierung in alternativen Systemen.
Entra ID unabhängig halten: Setzen Sie bei der Identitätsverwaltung auf offene Standards: SAML, OIDC, OAuth 2.0. Konfigurieren Sie Anwendungen so, dass sie mit jedem konformen Identity Provider funktionieren – nicht nur mit Entra. Das ist eine Architekturentscheidung, die im laufenden Betrieb kaum Aufwand bedeutet, aber im Exit-Fall enorm viel Komplexität spart.
Backup-Strategie überdenken: Microsoft ist kein Backup-Anbieter. Daten in OneDrive, SharePoint oder Exchange sind nicht automatisch vor Datenverlust oder Ransomware geschützt – und sie sind vor allem nicht außerhalb des Microsoft-Ökosystems gesichert. Ein externes Backup kritischer Daten in einem anbieterneutralen Format ist gleichzeitig ein Schritt zur Portabilität.
Aufwand/Nutzen: Mittel bis hoch, je nach Ausgangslage. Die Maßnahmen können priorisiert und gestaffelt umgesetzt werden – beginnend mit den kritischsten Diensten. Der Nutzen geht über Exit-Readiness hinaus: bessere Datensicherheit, klarere Prozessdokumentation, weniger Abhängigkeit von implizitem Wissen einzelner Mitarbeiter.
Das Ziel: Für jeden kritischen Microsoft-Dienst mindestens eine evaluierte Alternative kennen – nicht zwingend betreiben, aber bewusst entschieden haben.
Diese Stufe ist die strategisch anspruchsvollste – aber auch die, die am häufigsten übersprungen wird. Viele Unternehmen bauen Sichtbarkeit auf, arbeiten an der Portabilität, und lassen dann die Frage der Alternativen offen. Das ist ein Fehler, denn ohne Alternativen ist Exit-Readiness eine Halbwahrheit.
Es geht nicht darum, Google Workspace einzuführen oder einen Zweit-Cloud-Vertrag abzuschließen. Es geht darum, für jeden kritischen Dienst eine fundierte Antwort auf die Frage geben zu können: „Was würden wir einsetzen, wenn dieser Dienst morgen nicht mehr verfügbar wäre?“
Konkrete Maßnahmen für Stufe 3:
Vergleichsmatrix für Ersatzlösungen erstellenAlternativenmatrix erstellen: Erstellen Sie eine strukturierte Übersicht: Dienst – aktuelle Microsoft-Lösung – evaluierte Alternative – Bewertung (Funktionsparität, Migrationsaufwand, Kosten, Reife). Diese Matrix muss nicht perfekt sein. Aber sie muss existieren – und jährlich aktualisiert werden.
Pilotevaluation für Top-3-Risikodienste: Für die drei kritischsten Microsoft-Abhängigkeiten im Unternehmen: führen Sie eine echte, zeitlich begrenzte Evaluation durch. Das bedeutet nicht, die Alternative einzuführen – aber es bedeutet, sie ernsthaft zu testen und eine informierte Entscheidung treffen zu können.
Vertragsreview mit Exit-Fokus: Kennen Sie die Kündigungsfristen, Exportrechte und Datenlöschfristen in Ihren Microsoft-Verträgen? Wissen Sie, welche Übergangsunterstützung Microsoft im Exit-Fall vertraglich schuldet? Diese Fragen zu beantworten kostet wenige Stunden Anwaltszeit – und kann im Ernstfall enorme Konsequenzen haben.
Aufwand/Nutzen: Der initiale Aufwand ist überschaubar – eine strukturierte Evaluationsmatrix ist in ein bis zwei Tagen erstellt. Der Nutzen: Verhandlungsmacht gegenüber Microsoft, Audit-Tauglichkeit, strategische Handlungsfähigkeit.
Nicht alle Microsoft-Dienste sind gleich. Einige lassen sich vergleichsweise einfach ersetzen, andere sind tief in Architektur, Prozesse und Nutzergewohnheiten verankert. Eine realistische Exit-Readiness-Strategie priorisiert nach dieser Einschätzung.
Outlook / Exchange Online – kritisch, aber handhabbar
E-Mail ist kritisch – aber der Markt für E-Mail-Alternativen ist reif. Google Workspace, Open-Xchange, Zimbra oder Hosted-Exchange-Lösungen europäischer Anbieter sind praxistaugliche Optionen. Der Migrationsaufwand ist erheblich, aber planbar. Das größte Risiko ist nicht die Technik – es sind die Nutzergewohnheiten und Kalenderintegrationen.
Microsoft Teams – kritisch und tief verankert
Teams ist für viele Unternehmen zur zentralen Arbeitsplattform geworden – Kommunikation, Dateiablage, Meetings, Telefonie, externe Zusammenarbeit. Ein Ersatz erfordert nicht nur eine Technologieentscheidung, sondern ein Change-Management-Projekt. Zoom, Slack, Webex oder Jitsi sind technisch valide Alternativen – aber der Prozess-Lock-in ist das eigentliche Hindernis.
SharePoint – komplex und oft unterschätzt
SharePoint ist selten nur eine Dateiablage. Es ist Intranet, Dokumentenmanagement, Workflow-Plattform und Kollaborationsraum in einem. Alternativen wie Confluence, Nextcloud oder proprietäre DMS-Systeme können Teilfunktionen übernehmen – aber selten alle. Eine Migration erfordert eine sorgfältige Analyse, welche SharePoint-Funktionen tatsächlich kritisch sind.
Microsoft Entra ID – technisch tiefster Lock-in
Entra ist das Rückgrat jeder Microsoft-Umgebung. Ein Ersatz durch Keycloak, Okta oder JumpCloud ist technisch möglich – aber voraussetzungsreich. Jede Anwendung, jedes Gerät, jeder Dienst muss neu konfiguriert werden. Deshalb gilt hier besonders: Wer von Anfang an auf offene Standards setzt, spart im Exit-Fall am meisten.
Azure-native Workloads – größtes Migrationsrisiko Anwendungen, die auf Azure Functions, Cosmos DB, Logic Apps oder anderen Azure-nativen Diensten aufbauen, haben das höchste Migrationsrisiko. Container-basierte Architekturen (Kubernetes) und die Nutzung offener Datenbankstandards sind die wichtigsten Hebel, um hier Portabilität herzustellen – idealerweise von Anfang an.
Eine Frage, die in Strategiegesprächen häufig auftaucht: Sollte man nicht einfach von Anfang an multi-cloud aufstellen und damit das Lock-in-Problem lösen?
Die ehrliche Antwort ist: Es kommt darauf an – und oft ist der parallele Betrieb nicht die klügste erste Antwort.
Multi-Cloud macht Sinn, wenn:
Multi-Cloud macht weniger Sinn, wenn:
Hybrid ist oft der realistischere Einstieg: Kritische Daten on-premises oder bei einem europäischen Anbieter halten, Microsoft für Produktivität und Kollaboration nutzen – und dabei Portabilität aktiv gestalten. Das reduziert das Concentration Risk, ohne die Komplexität einer echten Multi-Cloud-Architektur zu erzeugen.
Eine der ehrlichsten Fragen im Cloud-Exit-Kontext lautet: Was kostet es wirklich, Microsoft-Dienste durch Alternativen zu ersetzen – und lohnt es sich?
Die Antwort ist differenzierter, als die meisten Diskussionen vermuten lassen. Denn die Kosten eines Wechsels sind nicht nur Lizenzkosten. Und die Kosten des Verbleibens sind nicht nur Lizenzkosten.
Kosten eines Wechsels (vollständig betrachtet):
Kosten des Verbleibens (vollständig betrachtet):
Die pragmatische Schlussfolgerung: Für die meisten Unternehmen ist ein vollständiger Microsoft-Exit auf absehbare Zeit wirtschaftlich nicht attraktiv – die Gesamtkosten übersteigen den Nutzen. Aber Exit-Readiness aufzubauen – also Transparenz herzustellen, Portabilität zu sichern und Alternativen zu kennen – kostet einen Bruchteil davon und liefert unmittelbaren Mehrwert: für Verhandlungen, für Compliance, für Resilienz.
Ein strukturiertes Dependency-Mapping – also die Kartierung aller Dienste, Daten und Prozessabhängigkeiten – ist der Kern von Stufe 1. Es gibt verschiedene Wege, das umzusetzen:
Microsoft-eigene Tools:
Drittanbieter-Tools:
Methodischer Ansatz ohne Tooling: Für kleinere Organisationen oder als schneller erster Schritt reicht oft ein strukturierter Workshop-Ansatz: Geschäftsprozess-Owner und IT-Verantwortliche gemeinsam an einem Tisch, eine einfache Tabelle mit Dienst / Prozess / Daten / Abhängigkeit / Kritikalität / Migrationsaufwand – und zwei Tage konzentrierte Arbeit. Das Ergebnis ist kein perfektes Dependency-Map, aber ein belastbares Bild, das als Grundlage für alle weiteren Maßnahmen dient.
Exit-Readiness ist kein Projekt, das man abschließt. Es ist ein Reifegrad, den man kontinuierlich weiterentwickelt – Stufe für Stufe, Dienst für Dienst, Maßnahme für Maßnahme.
Was zählt, ist der erste Schritt. Denn wer heute damit beginnt, Transparenz herzustellen, hat morgen eine bessere Verhandlungsposition, übermorgen einen audit-tauglichen Nachweis – und im Ernstfall die Handlungsfähigkeit, die anderen fehlt.
Die gute Nachricht: Sie müssen das nicht alleine tun. Und Sie müssen nicht bei null anfangen. In vielen Unternehmen existieren bereits Inventarisierungen, Risikoregister und Prozessdokumentationen, die als Ausgangspunkt dienen können. Es geht darum, diese Bausteine zusammenzuführen – und gezielt die Lücken zu schließen.
Wir haben einen strukturierten Tagesworkshop entwickelt, der Ihr Unternehmen in einem Tag durch die ersten beiden Stufen des Exit-Readiness-Modells führt. Das Ergebnis: eine priorisierte Maßnahmenliste, eine erste Dependency-Map und ein klares Bild davon, wo Ihr größter Handlungsbedarf liegt.
Kein Aktionismus. Kein Ausstiegsdruck. Nur Klarheit – und ein konkreter nächster Schritt.
Sie fanden diesen Artikel spannend? Dann freuen Sie sich auf weitere Artikel dieser Serie oder lesen Teil 1: Warum Cloud Exit kein Widerspruch zur Cloud-Strategie ist, Teil 2: Cloud Exit als Enterprise Risk Management – Was Auditoren und Regulatoren erwarten und Teil 3: Vendor Lock-in bei Microsoft 365
Sie möchten wissen, wie stark Ihr Unternehmen von Microsoft gebunden ist und wo die größten Hebel liegen?
Wir analysieren Ihre Abhängigkeitsstruktur, priorisieren nach Risiko und Aufwand und entwickeln mit Ihnen eine pragmatische Roadmap, ohne Hype, ohne Dogma.
Wir sind für Sie da.
Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen?
Wir sind gerne für Sie da.
HEIKO WESSELS
Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an
Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.
