Wenn Unternehmen über einen Wechsel ihrer Cloud-Plattform nachdenken, beginnen sie fast immer mit derselben Frage: „Wie kommen wir an unsere Daten?“ Es ist die naheliegende Frage und zugleich die falsche.
Denn die eigentliche Herausforderung beim Verlassen des Microsoft-Ökosystems liegt nicht in den Daten. Sie liegt in dem, was über Jahre um die Daten herum gewachsen ist: Abhängigkeiten, Berechtigungskonzepte, Automatisierungen, Geschäftsprozesse und zunehmend auch KI-gestützte Workflows. Wer einen Microsoft Exit plant, ohne diesen unsichtbaren Teil der Abhängigkeit zu verstehen, unterschätzt den Aufwand, sowohl strukturell, finanziell als auch organisatorisch.
Dieser Beitrag liefert einen ehrlichen, differenzierten Überblick. Kein Alarmismus, keine Anbieter-Werbung, sondern eine sachliche Einordnung, welche Microsoft-Dienste wie stark binden und warum.
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.
DORA ist seit Januar 2025 in der EU verpflichtend anwendbar und richtet sich primär an Finanzunternehmen: Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister, Kreditinstitute und deren IKT-Dienstleister. Der Anwendungsbereich ist deutlich breiter als viele zunächst angenommen haben.
DORA adressiert Cloud-Abhängigkeiten auf zwei Ebenen, die für das Thema Exit-Readiness direkt relevant sind:
Concentration Risk ist eines der Kernkonzepte. DORA verlangt, dass Finanzunternehmen aktiv bewerten und dokumentieren, ob eine übermäßige Abhängigkeit von einzelnen IKT-Drittdienstleistern besteht und welche Risiken daraus entstehen. Ein Unternehmen, das seine gesamte digitale Infrastruktur auf Microsoft aufgebaut hat, ohne Fallback-Optionen oder eine dokumentierte Exit-Strategie, hat per Definition ein Concentration-Risk-Problem im Sinne von DORA.
Exit-Strategien für kritische IKT-Dienstleister sind nach DORA explizit zu dokumentieren. Artikel 28 des Gesetzes verlangt, dass Finanzunternehmen für kritische Drittanbieter einen schriftlichen Exit-Plan vorhalten, einschließlich Zeitplanung, Verantwortlichkeiten, Migrationsszenarien und Nachweis der technischen Umsetzbarkeit. Dieser Plan muss nicht bedeuten, dass der Ausstieg geplant ist. Er muss bedeuten, dass er möglich ist und, dass das Unternehmen das belegen kann.
Für Unternehmen, die Microsoft als kritischen IKT-Dienstleister eingestuft haben, und das sollten alle tun, bei denen Microsoft substanzielle Teile ihrer IT-Landschaft darstellen, ist ein dokumentierter Exit-Plan damit keine Option, sondern Pflicht.
Was Auditoren unter DORA prüfen:
Vendor Lock-in bei Microsoft entsteht auf drei Ebenen, die sich gegenseitig verstärken:
Nicht alle Microsoft-Dienste binden gleich stark. Die folgende Einschätzung orientiert sich an der Praxiserfahrung aus Migrationsprojekten und unterscheidet zwischen dem, was technisch möglich ist, und dem, was tatsächlich Aufwand erzeugt.
Exchange / Outlook (E-Mail) E-Mails lassen sich grundsätzlich migrieren. IMAP-basierte Protokolle sind standardisiert, und es existieren ausgereifte Migrationswerkzeuge. Die Herausforderung liegt nicht in den E-Mail-Daten selbst, sondern in der Planung: Welche Postfächer, in welcher Reihenfolge, mit welchem Cutover-Konzept? Verteilerlisten, freigegebene Postfächer und Kalenderberechtigungen erfordern sorgfältige Abbildung auf das Zielsystem.
OneDrive / SharePoint – reine Dateien Die eigentliche Datei ist selten das Problem. Dokumente, PDFs, Bilder lassen sich übertragen. Was verloren geht oder aufwendig nachgebaut werden muss sind Freigabestrukturen, Berechtigungshierarchien und kollaborative Nutzungsmuster. Wer wem welchen Ordner geteilt hat, wer Bearbeitungsrechte hatte – das ist nicht in der Datei gespeichert, sondern im System darum herum.
Stream, Visio, Clipchamp Exportierbare Inhalte wie Videos oder Diagramme können in alternativen Systemen weiterverwendet werden. Bearbeitungsstände, Versionierungen und plattformspezifische Funktionen gehen dabei häufig verloren. Kein kritischer Lock-in, aber kein triviales Projekt.
Microsoft Entra ID (ehemals Azure Active Directory) Benutzeridentitäten lassen sich technisch über Federation oder Identity-Provider-Wechsel überführen. Die eigentliche Herausforderung ist das, was hinter den Identitäten steckt: Rollenzuweisungen, Berechtigungskonzepte, Lizenzzuweisungen, Conditional-Access-Policies und Verwaltungsstrukturen. Wer über Jahre ein granulares Berechtigungsmodell in Entra ID aufgebaut hat, wird dieses nicht exportieren, sondern neu konzipieren müssen.
Microsoft Intune Intune-Konfigurationen sind nicht portierbar. Geräterichtlinien, Compliance-Anforderungen, App-Deployments, all das muss im Zielsystem von Grund auf neu aufgebaut werden. Eine Intune-Migration ist de facto eine Neuimplementierung des Endpoint-Managements.
SharePoint-Lösungen (individuell entwickelt) Hier beginnt der kritische Bereich. Sobald SharePoint nicht nur als Dateiablage, sondern als Applikationsplattform genutzt wird (SPFx-Lösungen, Power Apps, benutzerdefinierte Listen, komplexe Workflows), steigt die Komplexität erheblich. Nicht die Daten, sondern die Plattformlogik erzeugt die Bindung. Diese Logik existiert nur innerhalb von SharePoint und muss in einem alternativen System neu gedacht werden.
OneDrive-Freigaben und kollaborative Strukturen Die Dateien sind übertragbar. Die Freigabestruktur, also wer auf welchen Ordner Zugriff hat, welche externen Gäste eingeladen sind, welche Teams-Kanäle mit welchen SharePoint-Sites verknüpft sind, ist das eigentliche Migrationsprojekt.
Microsoft Planner Aufgaben, Status, Kategorien, Zuweisungen, Verknüpfungen mit Teams-Kanälen. All das lässt sich nicht sauber in ein alternatives Projektmanagement-Tool exportieren. Wer Planner intensiv nutzt, hat eine gewachsene Aufgabenstruktur aufgebaut, die in dieser Form nur in Planner existiert. Die Migration bedeutet: Neustart im Zielsystem, mit erheblichem manuellen Aufwand.
Microsoft Project (insbesondere Project Online) Unter den Microsoft-Workloads gilt Project Online als besonders migrationsfeindlich. Komplexe Projektstrukturen, Ressourcenplanung, Portfolio-Abhängigkeiten und Reporting-Konfigurationen erzeugen eine Bindung, die sich kaum automatisiert lösen lässt. In der Praxis wird eine Project-Online-Migration regelmäßig als aufwendigstes Teilprojekt beschrieben.
Teams-Chats und Kollaborationshistorie Chatverläufe, Kanalhistorien, Dateien in Kanal-Tabs, Meeting-Aufzeichnungen, Reaktionen, angeheftete Nachrichten, das alles ist in Teams gespeichert und lässt sich nicht vollständig und strukturtreu in eine andere Plattform überführen. Der Informationsverlust kann substanziell sein. Besonders kritisch: Viele Unternehmen haben Teams zu ihrer primären Wissensdatenbank gemacht, ohne sich dessen bewusst zu sein.
Microsoft Purview Datenklassifizierung, Sensitivity Labels, Verschlüsselung und Compliance-Konfigurationen können eine Migration massiv erschweren. Dokumente, die mit bestimmten Labels versehen sind, lassen sich unter Umständen nicht ohne weiteres aus dem geschützten Kontext herauslösen. Vor einer Migration müssen Schutzmechanismen systematisch analysiert, teilweise aufgelöst und im Zielsystem neu aufgebaut werden.
Whiteboard, Loop, OneNote Diese kollaborativen Tools haben kaum standardisierte Migrationspfade. Inhalte können exportiert werden, aber die kollaborative Struktur, die Verknüpfungen mit Teams-Meetings oder die Einbettung in Kanäle gehen verloren. Für Teams, die diese Tools intensiv nutzen, kann das ein echter Verlust sein.
Microsoft Forms und Lists Daten lassen sich exportieren, aber die eigentliche Funktionalität nicht. Ein Formular, das intern genutzt wird, um Genehmigungen einzuholen oder Feedback zu sammeln, ist kein reiner Datensatz. Es ist ein Prozess. Und dieser Prozess muss im Zielsystem neu aufgebaut werden.
Das ist der Punkt, an dem viele Unternehmen die Tragweite ihrer Abhängigkeit unterschätzen.
Die größte Bindung entsteht nicht durch die Daten, sie entsteht durch die Prozesse, Automatisierungen und Arbeitsweisen, die auf der Microsoft-Plattform aufgebaut wurden. Und diese sind, anders als Daten, nicht exportierbar. Sie sind in der Plattform verankert.
Konkrete Beispiele aus der Praxis:
Jeder dieser Bereiche ist ein eigenständiges Migrationsprojekt. Zusammengenommen ergibt sich ein Bild, das weit über eine Datenmigration hinausgeht: Es ist eine Transformation der Arbeitsweise eines Unternehmens.
Neben dem klassischen Plattform-Lock-in entsteht gerade eine neue Dimension der Abhängigkeit, die noch wenig diskutiert wird, aber erhebliches Gewicht hat.
Unternehmen bauen zunehmend auf Microsoft Copilot: Copilot für M365, Copilot Studio, KI-Agenten, die Prozesse orchestrieren, Informationen aus SharePoint und Teams abrufen, E-Mails zusammenfassen, Genehmigungen anstoßen oder Projekte koordinieren. Diese Agenten werden Teil geschäftskritischer Abläufe.
Was bedeutet das für die Abhängigkeit?
Ein Plattformwechsel bedeutet künftig nicht mehr nur die Migration von Daten und Prozessen, sondern auch die Migration oder vollständige Neuerstellung intelligenter, KI-gestützter Workflows. Copilot-Agenten sind tief in den Microsoft-Graph eingebunden: Sie greifen auf E-Mails, Kalender, Teams-Kanäle, SharePoint-Dokumente und Entra-ID-Berechtigungen zu. Diese Architektur existiert nur innerhalb des Microsoft-Ökosystems.
Wer heute beginnt, Geschäftsprozesse mit Microsoft Copilot zu automatisieren, ohne eine Exit-Perspektive zu haben, schafft eine neue Klasse von Lock-in. Und zwar einen, der sich in wenigen Jahren noch deutlich schwerer lösen lassen wird als die heutigen Abhängigkeiten.
Das bedeutet nicht, Copilot nicht zu nutzen. Es bedeutet, die Abhängigkeit zu kennen und bei der Gestaltung von KI-Workflows darauf zu achten, welche Prozesslogik sich prinzipiell auch auf andere Plattformen übertragen ließe.
Drei Erkenntnisse, die aus diesem Überblick folgen:
1. Realistische Bestandsaufnahme vor jeder Migrationsdiskussion Bevor über einen Cloud-Wechsel nachgedacht wird, braucht es eine ehrliche Inventur: Welche Dienste nutzen wir wie intensiv? Wo haben wir individuelle Lösungen aufgebaut? Welche Geschäftsprozesse hängen an der Plattform? Ohne diese Kenntnis ist jede Aufwandsschätzung Kaffeesatzlesen.
2. Nicht alle Dienste binden gleich: priorisieren lohnt sich Exchange migrieren ist anders als Entra ID ablösen. SharePoint-Dateien übertragen ist anders als SharePoint-Anwendungen migrieren. Eine differenzierte Risikobetrachtung je Workload ermöglicht eine strukturierte Priorisierung und verhindert, dass der schwierigste Teil erst am Ende sichtbar wird.
3. Der KI-Lock-in beginnt jetzt Wer heute KI-gestützte Prozesse aufbaut, trifft Entscheidungen, die in drei bis fünf Jahren schwer revidierbar sind. Das ist kein Argument gegen KI-Einsatz, aber ein starkes Argument dafür, die Plattformabhängigkeit bewusst zu gestalten statt sie stillschweigend wachsen zu lassen.
Vendor Lock-in bei Microsoft ist real. Aber er ist kein Schicksal und er ist auch kein Argument gegen die Nutzung von Microsoft-Diensten. Er ist eine Rahmenbedingung, die verstanden werden muss.
Die Unternehmen, die in einer künftigen Migrationssituation den größten Spielraum haben werden, sind nicht die, die heute schon alternative Systeme betreiben. Es sind die, die wissen, wo ihre Abhängigkeiten liegen und die bei der Weiterentwicklung ihrer Plattform-Nutzung bewusste Entscheidungen über Portabilität und Flexibilität treffen.
Wer heute nicht weiß, was ihn bindet, wird morgen teuer herausfinden, was das kostet.
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 und Teil 2: Cloud Exit als Enterprise Risk Management – Was Auditoren und Regulatoren erwarten
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.
