MS365 und die Notwendigkeit einer Exit-Strategie — Digitale Souveränität beginnt bei der Einführung
~13 min read
Digital SovereigntyMS365Exit StrategyOpen SourceopenDeskCloud ComputingIT Governance
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Viele Organisationen stehen vor einer Entscheidung: Microsoft 365 einführen oder nicht. Auf den ersten Blick scheint MS365 die einfache Lösung — vollständiges Paket, Integration, geringe Eintrittsbarrieren. Doch die Entscheidung für MS365 ist bei mangelnder Planung eine Entscheidung für langfristige Abhängigkeit.
Das Problem: Exit-Strategien werden oft nach der Einführung entwickelt. Zu diesem Zeitpunkt ist die Organisation bereits tief in Ökosystemen, Datenhaltung und Arbeitsprozesse verwoben. Ein Ausstieg wird zur technischen, organisatorischen und finanziellen Herausforderung.
Dieser Beitrag argumentiert für ein anderes Prinzip: Exit-Strategien müssen parallel zur Einführung von MS365 entwickelt werden. MS365 sollte nicht als Endzustand betrachtet werden, sondern als reversibler Betriebszustand mit Exit-by-Design. Nur so bleibt digitale Souveränität erhalten — die Kontrolle über eigene Daten, Identitäten und Systeme.
Microsoft 365 bietet ein durchgängiges Ökosystem: Teams als Kommunikationsplattform, SharePoint für Kollaboration, OneDrive für Speicher, Exchange für Mail, Power Platform für Workflows und Automatisierung. Alle Services sind integriert, Identitäten laufen über Entra ID (früher Azure AD), und Anwendungen sind nahtlos verschaltet.
Das ist bequem — und gefährlich.
Was oft übersehen wird: Jedes Jahr ohne Exit-Planung erhöht die technische Schuld einer Organisation. Diese Schuld manifestiert sich in:
| Art der Schuld | Monetäre Auswirkung | Operative Auswirkung |
|---|---|---|
| Datenmigration | steigt exponentiell mit Datenmenge und Zeit | Benutzerdowntime, Datenverluste |
| Schulungspotentiale | Mitarbeiter müssen doppelt geschult werden (MS365 + Alternative) | Produktivitätsverluste |
| prozessualer Umbau | Redesign aller Arbeitsabläufe | Widerstand der Anwender |
| technische Refaktorierung | Neuentwicklung von Schnittstellen, APIs | Projektrisiko |
| vertragliche Bindung | Verlängerungen, vormals geplante Abgabefristen | Verhandlungsmachtverlust |
Praxisbeispiel: Eine mittelständische Organisation mit 500 Mitarbeitenden führte Microsoft Teams und SharePoint ohne Exit-Konzept ein. Nach vier Jahren:
Ein späterer Exit schätzt in diesem Szenario auf 1,5–2,5 Mio. Euro allein für Konsolidierung, Migration und Schulungen — ein Betrag, der bei paralleler Exit-Planung auf ca. 30–40 % reduziert hätte werden können.
Eine Exit-Strategie kann und sollte parallel zur Einführung von MS365 entwickelt werden. Der entscheidende Gedanke lautet: MS365 nicht als Endzustand einführen, sondern als reversiblen, kontrollierten Betriebszustand.
Das bedeutet: Bereits während der Einführung werden technische, rechtliche und organisatorische Maßnahmen getroffen, damit Organisationen später Dienste, Daten und Prozesse wieder aus MS365 herauslösen können — ohne Chaos, Datenverlust oder vollständige Neuplanung.
Schon bei der Einführung sollten diese Fragen geklärt werden:
Die Exit-Strategie ist dann kein späteres Sonderprojekt, sondern Teil der MS365-Governance.
Organisationen können unterschiedliche Zielbilder verfolgen. Ein vollständiger Exit ist nicht die einzige Option.
MS365 bleibt für bestimmte Funktionen im Einsatz, etwa Excel, Word oder eine Exchange-Migration. Die Dateiablage, die Projektarbeit und die Kollaboration werden aber zunehmend durch Open-Source-Dienste ersetzt. Das Ziel ist nicht gegen Microsoft, sondern pragmatische Nutzung und parallele Entwicklung.
MS365 wird nur für weniger sensible oder stark standardisierte Szenarien genutzt. Sensible Projekte, Verwaltungsprozesse, kritische Zusammenarbeit oder personenbezogene Daten liegen bevorzugt auf eigener oder föderierter Infrastruktur. Die Entscheidung "wohin" wird durch Datenklassifikation gesteuert, nicht durch Bequemlichkeit.
MS365 wird über mehrere Jahre schrittweise ersetzt, durch openDesk, Nextcloud, Collabora, Matrix, OpenProject und weitere Dienste. Dies ist ein langjähriges Projekt, aber indem bereits bei der Einführung Vorbereitungen getroffen werden, ist der Weg offen.
Wichtig: Organisationen müssen nicht sofort entscheiden, ob sie vollständig aussteigen. Sie sollten aber von Anfang an exitfähig bleiben.
Es sollte ein gemeinsames Programm für Einführung und Exit-Fähigkeit geben, nicht zwei getrennte Projekte. Beteiligt sein sollten:
Dieses Gremium entscheidet nicht nur über MS365-Konfigurationen, sondern auch über:
Eine Exit-Strategie funktioniert nur, wenn klar ist, welche Daten wohin dürfen. Die folgende Klassifikation ist ein typisches Modell für Organisationen:
| Datenklasse | Beispiele | MS365-Nutzung? | Zielstrategie |
|---|---|---|---|
| Öffentlich | Webseiteninhalte, öffentliche Materialien | möglich | unkritisch |
| Intern | Arbeitsdokumente, Protokolle | eingeschränkt möglich | exportfähig halten |
| Personenbezogen | Kundendaten, Mitarbeitendendaten | nur nach Prüfung | bevorzugt souveräne Dienste |
| Besonders schutzwürdig | Gesundheitsdaten, sensible Projektdaten | möglichst nicht | lokale/föderierte Dienste |
| Finanzdaten | Rechnungen, Bilanzen, Buchhaltung | kritisch | DMS/E-Akte/Fachverfahren |
| Strategische Daten | Geschäftspläne, F&E-Ergebnisse | kritisch | lokale/föderierte Dienste |
Diese Klassifikation sollte schon bei der MS365-Einführung in Richtlinien, Schulungen und technische Policies übersetzt werden.
Bereits bei der Einführung sollten bestimmte Lock-in-Fallen vermieden werden.
Ein besonders wichtiger Punkt: Entra ID darf möglichst nicht das führende Identitätssystem werden, wenn Exit-Fähigkeit gewünscht ist.
Besser ist:
Organisations-IAM / LDAP / AD / Shibboleth / Keycloak
|
Keycloak oder Föderationsdienst
|
MS365, openDesk, weitere Dienste
Ziel:
Das ist eine der wichtigsten technischen Voraussetzungen für jeden späteren Exit.
Während MS365 eingeführt wird, sollte parallel eine souveräne Zielplattform evaluiert werden. Ein naheliegendes Modell:
| MS365-Funktion | Parallel evaluierte Alternative |
|---|---|
| Teams / SharePoint-Arbeitsräume | openDesk-CE |
| OneDrive | Nextcloud / ownCloud |
| Office Online | Collabora Online / OnlyOffice |
| Planner | OpenProject, Taiga |
| Forms | LimeSurvey |
| Teams-Chat | Matrix/Element, Mattermost |
| Videokonferenzen | BigBlueButton, Jitsi Meet |
| OneNote/Wissensablage | XWiki, HedgeDoc |
| Exchange | SOGo, Open-Xchange, Postfix/Dovecot |
Gerade openDesk-CE eignet sich als parallele Evaluationsplattform, weil es mehrere dieser Funktionen integriert bereitstellt: Dateiablage, Online-Office, Projektarbeit, Wissensmanagement, Kommunikation und Identitätsintegration.
Parallel zur MS365-Einführung sollten Organisationen Regeln beschließen, die zukünftige Abhängigkeiten begrenzen.
Beispiele:
Diese Regeln verhindern, dass Organisationen sich während der Einführung tiefer binden, als sie eigentlich möchten.
Eine Exit-Strategie parallel zur Einführung bedeutet nicht, zwei völlig getrennte Welten aufzubauen. Besser ist ein kontrollierter Parallelbetrieb:
MS365: kurzfristig verfügbare Standardplattform
openDesk/
OSS-Dienste: strategische souveräne Zielplattform
Organisations-IAM: gemeinsame Identitätsbasis
Datenklassifikation: entscheidet über Speicherort
Governance: steuert Nutzung und Migration
Beispielkonfiguration:
Beispielkonfiguration:
Bereits bei Einführung sollte für jeden Dienst ein „Exit-Steckbrief" existieren.
Parallel zur Einführung sollten Verträge und interne Beschaffungsrichtlinien angepasst werden.
Wichtige Anforderungen:
Auch bei Open-Source-Alternativen sollen Betrieb, Support und Exit-Fähigkeit vertraglich bedacht werden.
Eine mögliche Roadmap:
| Zeitraum | MS365-Einführung | Exit-/Souveränitätsmaßnahmen |
|---|---|---|
| 0–3 Monate | Projektstart, Tenant-Planung | Governance, Datenklassifikation, Exit-Leitlinien |
| 3–6 Monate | Pilot MS365 | openDesk-CE/Nextcloud-Pilot, IAM-Entkopplung |
| 6–12 Monate | Rollout ausgewählter MS365-Dienste | No-new-lock-in-Regeln, Exporttests, Schulungen |
| Jahr 2 | Breitere Nutzung | Standard für neue sensible Projekte auf OSS-Plattform |
| Jahr 3 | Konsolidierung | Reduktion von Teams/SharePoint-Neuanlagen, Migration erster Bereiche |
| Jahr 4+ | Lizenzoptimierung | mögliche Teil- oder Vollablösung einzelner MS365-Dienste |
So entsteht kein Widerspruch zwischen Einführung und Exit: MS365 wird kontrolliert genutzt, während Alternativen wachsen.
Eine sinnvolle Formulierung könnte sein:
Die Organisation führt MS365 nur unter der Bedingung ein, dass Identitäten, Daten, Prozesse und Dokumentformate so gestaltet werden, dass ein späterer Wechsel zu offenen oder souveränen Plattformen möglich bleibt. Parallel werden openDesk-CE und weitere Open-Source-Dienste als strategische Zielumgebung aufgebaut und für geeignete Nutzungsszenarien bevorzugt eingesetzt.
Dieses Zielbild schafft Klarheit: MS365 ist nicht verboten, aber die Nutzung erfolgt unter Bedingungen, die Exit-Fähigkeit sicherstellen.
Kurz zusammengefasst:
Der wichtigste Punkt: Eine Organisation sollte MS365 nicht „blind" einführen und später über den Exit nachdenken. Sie sollte MS365 von Anfang an so nutzen, dass der spätere Exit technisch, organisatorisch und rechtlich möglich bleibt.