MS365 Exit-Strategien: Warum digitale Souveränität bei der Implementierung beginnt
🇬🇧 Read in English~11 min read
DevOpsms365digital-sovereigntycloud-migrationopen-sourceit-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 Wahl zu sein – Komplettpaket, Integration, geringe Anfangskosten. Doch ohne entsprechende Planung ist die Entscheidung für MS365 eine Entscheidung für eine langfristige Abhängigkeit.
Das Problem: Exit-Strategien werden oft erst nach der Implementierung entwickelt. Zu diesem Zeitpunkt ist die Organisation bereits tief in Microsoft-Ökosystemen, Datenarchitekturen und Workflows verankert. Ein Ausstieg wird zu einer technischen, organisatorischen und finanziellen Herausforderung.
Dieser Artikel plädiert für ein anderes Prinzip: Exit-Strategien müssen parallel zur MS365-Implementierung entwickelt werden. MS365 sollte nicht als Endzustand betrachtet werden, sondern als ein reversibler Betriebszustand mit „Exit-by-Design“. Nur so bleibt die digitale Souveränität gewahrt – die Kontrolle über die eigenen Daten, Identitäten und Systeme.
Microsoft 365 bietet ein vollständiges Ökosystem: Teams für die Kommunikation, SharePoint für die Zusammenarbeit, OneDrive für die Speicherung, Exchange für E-Mails, Power Platform für Workflows und Automatisierung. Alle Dienste sind integriert, Identitäten werden über Entra ID (früher Azure AD) verwaltet und Anwendungen verbinden sich nahtlos. Diese Bequemlichkeit ist jedoch auch gefährlich.
Was oft übersehen wird: Jedes Jahr ohne Exit-Planung erhöht die technischen Schulden einer Organisation. Diese summieren sich wie folgt:
| Schuldenart | Monetare Auswirkung | Operative Auswirkung |
|---|---|---|
| Datenmigration | Exponentielles Wachstum mit Daten und Zeit | Ausfallzeiten, Datenverlust |
| Schulungspotenziale | Mitarbeiter geschult auf MS360+Alternativen | Produktivitätsverlust |
| Prozess-Redesign | Neugestaltung aller Workflows | Nutzerwiderstand |
| Technisches Refactoring | Neuarchitektur von Schnittstellen, APIs | Projektrisiko |
| Vertragsbindungen | Verlängerungen, zuvor geplante Kündigungsfristen | Verlust der Verhandlungsmacht |
Praxisbeispiel: Eine mittelständische Organisation mit 500 Mitarbeitern führte Microsoft Teams und SharePoint ohne Exit-Konzept ein. Nach vier Jahren:
Ein späterer Ausstieg würde schätzungsweise 1,5–2,5 Millionen Euro allein für Konsolidierung, Migration und Schulung kosten – ein Betrag, der durch eine parallele Exit-Planung auf 30–40 % hätte reduziert werden können.
Eine Exit-Strategie kann und sollte parallel zur MS365-Implementierung entwickelt werden. Die Kernidee: Implementieren Sie MS365 nicht als Endzustand, sondern als reversiblen, kontrollierten Betriebszustand.
Das bedeutet: Bereits während der Implementierung werden technische, rechtliche und organisatorische Maßnahmen ergriffen, damit Organisationen später Dienste, Daten und Prozesse aus MS365 extrahieren können – ohne Chaos, Datenverlust oder komplettes Redesign.
Bereits während der Einführung sollten diese Fragen geklärt werden:
Die Exit-Strategie wird so nicht zu einem späteren Sonderprojekt, sondern Teil der MS365-Governance.
Organisationen können unterschiedlichen Zielbildern folgen. Ein kompletter Ausstieg ist nicht die einzige Option.
MS365 bleibt für bestimmte Funktionen erhalten, wie Excel, Word oder eine Exchange-Migration. Dateispeicherung, Projektarbeit und Kollaboration werden zunehmend durch Open-Source-Dienste ersetzt. Das Ziel ist nicht „Anti-Microsoft“, sondern eine pragmatische Nutzung und parallele Entwicklung.
MS365 wird nur für weniger sensible oder hochstandardisierte Szenarien genutzt. Sensible Projekte, administrative Prozesse, kritische Zusammenarbeit oder personenbezogene Daten liegen vorzugsweise auf eigener oder föderierter Infrastruktur. Die Entscheidung über das „Wo“ wird durch die Datenklassifizierung gesteuert, nicht durch Bequemlichkeit.
MS365 wird über mehrere Jahre schrittweise durch openDesk, Nextcloud, Collabora, Matrix, OpenProject und andere Dienste ersetzt. Dies ist ein mehrjähriges Projekt, aber durch die Vorbereitung bereits während der Implementierung bleibt der Weg offen.
Wichtig: Organisationen müssen nicht vom ersten Tag an entscheiden, ob sie komplett aussteigen. Aber sie sollten von Beginn an exit-fähig bleiben.
Es sollte ein gemeinsames Programm für Implementierung und Exit-Fähigkeit geben, keine zwei separaten Projekte. Teilnehmer sollten sein:
Dieser Rat entscheidet nicht nur über MS365-Konfigurationen, sondern auch über:
Eine Exit-Strategie funktioniert nur, wenn klar ist, welche Daten wohin fließen dürfen. Die folgende Klassifizierung ist ein typisches Modell für Organisationen:
| Datenklasse | Beispiele | MS365-Nutzung? | Zielstrategie |
|---|---|---|---|
| Öffentlich | Website-Inhalte, öffentliche Materialien | Möglich | Unkritisch |
| Intern | Arbeitsdokumente, Protokolle | Eingeschränkt möglich | Exportfähig halten |
| Personenbezogen | Kundendaten, Mitarbeiterdaten | Nur nach Prüfung | Souveräne Dienste bevorzugen |
| Besonders sensibel | Gesundheitsdaten, sensible Projektdaten | Möglicherweise nicht | Lokale/föderierte Dienste |
| Finanzdaten | Rechnungen, Bilanzen, Buchhaltung | Kritisch | DMS/Dokumentenmanagement-System |
| Strategische Daten | Businesspläne, F&E-Ergebnisse | Kritisch | Lokale/föderierte Dienste |
Diese Klassifizierung sollte bereits während der MS365-Implementierung in Richtlinien, Schulungen und IT-Policies übersetzt werden.
Vermeiden Sie bestimmte Lock-in-Fallen bereits bei der Baseline-Konfiguration.
Ein besonders wichtiger Punkt: Entra ID darf nicht zum zentralen Identitätssystem werden, wenn Exit-Fähigkeit gewünscht ist.
Besser ist:
Organizational IAM / LDAP / AD / Shibboleth / Keycloak
|
Keycloak or Federation Service with MFA
|
MS365, openDesk, other services
Ziel:
Dies ist eine der wichtigsten technischen Voraussetzungen für jeden späteren Exit.
Während MS365 implementiert wird, sollte parallel eine souveräne Zielplattform evaluiert werden. Ein überzeugendes Modell:
| MS365-Funktion | Alternative zur parallelen Evaluation |
|---|---|
| Teams / SharePoint Workspaces | openDesk-CE |
| OneDrive | Nextcloud / ownCloud |
| Office Online | Collabora Online / OnlyOffice |
| Planner | OpenProject, Taiga |
| Forms | LimeSurvey |
| Teams Chat | Matrix/Element, Mattermost |
| Video-Calls | BigBlueButton, Jitsi Meet |
| OneNote / Knowledge Base | XWiki, HedgeDoc |
| Exchange | SOGo, Open-Xchange, Postfix/Dovecot |
openDesk-CE eignet sich besonders gut als Plattform zur parallelen Evaluation, da es mehrere dieser Funktionen out-of-the-box integriert: Dateispeicher, Online-Office, Projektmanagement, Wissensarbeit, Kommunikation und Identitätsintegration.
Parallel zur MS365-Implementierung sollten Organisationen Regeln verankern, die zukünftige Abhängigkeiten begrenzen.
Beispiele:
Diese Regeln verhindern, dass sich Organisationen während der Implementierung tiefer binden, als beabsichtigt.
Eine Exit-Strategie parallel zur Implementierung bedeutet nicht, zwei völlig getrennte Welten aufzubauen. Besser ist eine kontrollierte Koexistenz:
MS365: Kurzfristig verfügbare Standardplattform
openDesk/OS Services: Strategische souveräne Zielplattform
Organisatorisches IAM: Gemeinsame Identitätsbasis Datenklassifizierung: Entscheidet über den Speicherort Governance: Steuert Nutzung und Migration
**Beispielkonfiguration**:
- Teams anfangs für die allgemeine Kommunikation erlaubt
- openDesk/Nextcloud empfohlen für sensible Ausschussarbeit
- Web-Systeme bleiben führend für öffentliche Materialien
- CRM-Systeme bleiben führend für Kundendaten
- Neue Projekträume vorzugsweise mit openDesk pilotiert
- Stark Microsoft-abhängige Szenarien erhalten ein Sunset-Datum oder ein Überprüfungsintervall
---
## Exit-Plan pro MS365-Service erstellen
Bereits während der Implementierung sollte für jeden Service ein „Exit-Brief“ existieren.
### Service: OneDrive
- Welche Daten dürfen hinein?
- Wie werden die Daten exportiert?
- Zielsystem: Nextcloud/openDesk oder bestehende Dateidienste der Organisation
- Verantwortlich: IT-Abteilung
- Risiken: Berechtigungen, externe Links, private Daten
- Exit-Aufwand: mittel
- Überprüfung nach: 12 Monaten
### Service: Teams
- Nutzung erlaubt für: Chat, Meetings, einfache Workspaces
- Nicht erlaubt für: Dauerhafte Archivierung, sensible Daten, kritische Prozesse
- Zielalternativen: Matrix/Element, BigBlueButton, openDesk
- Exportproblem: Chat-Historien und Kanalstruktur
- Exit-Strategie: Neue Gruppen später bevorzugt in openDesk
### Service: SharePoint
- Nutzung erlaubt für: Einfache Dokumentenarbeit
- Nicht erlaubt für: Komplexe Prozesse ohne Genehmigung
- Zielalternativen: Nextcloud, XWiki, Dokumentenmanagementsysteme, OpenProject
- Exit-Risiko: Hoch
- Obligatorisch: Seitenkatalog, Eigentümer, Exportkonzept
### Service: Exchange Online
- Nutzung erlaubt für: E-Mail/Kalender, falls entschieden
- Zielalternativen: Bestehender Mail-Service, SOGo, Open-Xchange
- Exit-Risiko: Hoch
- Besondere Berücksichtigung: Kalendereinträge, Ressourcenplanung, mobile Endgeräte, Archivierung
---
## Vertragliche und beschaffungsrechtliche Exit-Klauseln
Parallel zur Implementierung sollten Verträge und interne Beschaffungsrichtlinien angepasst werden.
**Kernanforderungen**:
- Datenexport in maschinenlesbaren Formaten
- Klare Datenlöschungsregeln nach Vertragsende
- Unterstützung bei der Migration
- Keine dauerhafte Bindung an proprietäre Schnittstellen
- API-Dokumentation
- Audit- und Nachweisfähigkeiten
- Datenschutz nach Risikoanalyse
- Transparenz über Zusatzkosten
- Exit-Fristen und Übergangsregeln
- Vermeidung automatischer Funktionserweiterungen ohne erneute Bewertung
Bei Open-Source-Alternativen sollten auch Betrieb, Support und Exit-Fähigkeit vertraglich berücksichtigt werden.
---
## Zeitliche Kopplung von Implementierung und Exit-Strategie
Mögliche Roadmap:
| Zeitplan | MS365 Einführung | Exit- / Souveränitätsmaßnahmen |
| ----------- | ---------------------------------- | ------------------------------------------------------------------------- |
| 0-3 Monate | Projekt-Kick-off, Tenant-Planung | Governance, Datenklassifizierung, Exit-Richtlinien |
| 3-6 Monate | Pilot MS365 | openDesk-CE/Nextcloud-Pilot, IAM-Entkopplung |
| 6-12 Monate | Rollout ausgewählter MS365-Services | No-new-lock-in-Regeln, Exporttests, Schulungen |
| Jahr 2 | Breitere Nutzung | Standard für neue sensible Projekte auf OSS-Plattform |
| Jahr 3 | Konsolidierung | Reduzierung neuer Teams/SharePoint-Seiten, Migration erster Bereiche |
| Jahr 4+ | Lizenzoptimierung | Mögliche teilweise oder vollständige De-Provisionierung einzelner MS365-Services |
So entsteht kein Widerspruch zwischen Rollout und Exit: MS365 wird kontrolliert genutzt, während Alternativen wachsen.
---
## Praktische Zielvision für Organisationen
Eine sinnvolle Formulierung könnte sein:
> Die Organisation integriert MS365 nur unter der Bedingung, dass Identitäten, Daten, Prozesse und Dokumentenformate so gestaltet sind, dass eine spätere Migration auf offene oder souveräne Plattformen möglich bleibt. Parallel werden openDesk-CE und andere Open-Source-Dienste als strategische Zielumgebungen aufgebaut und für geeignete Nutzungsszenarien bevorzugt.
Diese Vision schafft Klarheit: MS365 ist nicht verboten, aber die Nutzung erfolgt unter Bedingungen, die sicherstellen, dass die Exit-Fähigkeit erhalten bleibt.
---
## Wichtigste Handlungsempfehlungen
Kurze Zusammenfassung:
1. **MS365-Einführung und Exit-Strategie gemeinsam planen**
2. **Organisatorisches IAM als führendes Identitätssystem beibehalten**
3. **Datenklassifizierung verbindlich machen**
4. **SharePoint, Power Platform und Teams begrenzen**
5. **Offene Formate und Schnittstellen vorschreiben**
6. **openDesk-CE/Nextcloud/Collabora/Matrix/OpenProject parallel pilotieren**
7. **Für jeden MS365-Service einen Exit-Brief erstellen**
8. **Keine kritischen Prozesse in MS365 ohne dokumentierten Exit-Pfad**
9. **Export- und Migrationstests bereits während der Implementierung durchführen**
10. **MS365-Lizenzen regelmäßig auf Reduktionspotenzial prüfen**
Der wichtigste Punkt: Eine Organisation sollte MS365 nicht „blind“ implementieren und erst später über den Exit nachdenken. Sie sollte MS365 von Anfang an so nutzen, dass ein späterer Ausstieg technisch, organisatorisch und rechtlich möglich ist.
---
_Dieser Artikel spiegelt Erfahrungen aus der Implementierung digitaler Souveränität in Organisationen verschiedener Größe im Zeitraum von 2023 bis 2026 wider._