MS365 Exit-Strategien: Warum digitale Souveränität bei der Implementierung beginnt

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.

---

Die Lock-in-Falle: Warum es so schwer ist, MS365 zu verlassen

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.

Technischer Lock-in

• Identity Management: Wenn Entra ID zur zentralen Identitätsquelle wird, ist ein späterer Ersatz komplex. Gruppen, Rollen und Berechtigungen werden zunehmend in Microsoft-spezifische Strukturen abgebildet.
• Datenformate: SharePoint-Dokumentbibliotheken, Power BI-Berichte, Power Apps-Anwendungen, OneNote-Notizbücher – all dies sind proprietäre Formate, die durch Standard-Exportfunktionen nur unvollständig freigegeben werden.
• Workflows & Automatisierung: In Power Automate oder SharePoint-Workflows kodiertes Prozesswissen lässt sich nur mühsam in andere Systeme migrieren.
• Integrationsschnittstellen: Graph API, Microsoft Graph Connector und proprietäre Authentifizierungen funktionieren nur in Microsoft-zentrierten Welten.

Organisatorischer Lock-in

• Schulungen: Mitarbeiter lernen Microsoft-Tools, nicht grundlegende Konzepte. Ein Wechsel erfordert umfangreiche Umschulungsmaßnahmen.
• Prozessdesign: Workflows entstehen rund um Teams-Strukturen, SharePoint-Sites und OneDrive-Verzeichnisse und verfestigen sich so in der Organisation.
• Change Management: Wenn MS365 tief in allen Abteilungen integriert ist, wird jede Änderung zu einem großen Transformationsprojekt.

Finanzieller Lock-in

• Lizenzverpflichtungen: Entscheidungen für E5-Lizenzen und Add-ons schaffen laufende Kosten. Eine Reduzierung der Lizenzen ist nach den Investitionen politisch schwierig.
• Preiserhöhungen: Microsoft erhöht regelmäßig die Preise. Ohne Exit-Optionen sind Organisationen an Anbieteränderungen gebunden.
• Undurchsichtiger Kosten-Drift: Warum werden Lizenzen notwendig? Wenn MS365 das Standard-Tool ist, werden Anforderungen automatisch zu Microsoft-Lizenzbedarfen.

Die Kosten des Nichtstuns: Technische Schulden als Exit-Barriere

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:

• 3+ TB Daten ausschließlich in SharePoint
• 150+ Power Automate-Workflows, die kritische Prozesse automatisieren
• 40+ Power Apps, die tief in den täglichen Betrieb integriert sind
• Alle Identitäten laufen über Entra ID

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.

---

Exit-by-Design: Das Kernprinzip

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.

Kernfragen während der Implementierung

Bereits während der Einführung sollten diese Fragen geklärt werden:

• Welche Daten dürfen in MS365 verarbeitet werden?
• Welche Daten sollen bewusst nicht in MS365 fließen?
• Welche Dienste werden nur temporär genutzt?
• Welche Alternativen werden parallel aufgebaut?
• Welche offenen Standards sind bindend?
• Wie werden Daten exportiert, archiviert oder migriert?
• Welche Microsoft-spezifischen Funktionen sind erlaubt – und welche nicht?

Die Exit-Strategie wird so nicht zu einem späteren Sonderprojekt, sondern Teil der MS365-Governance.

---

Definition des strategischen Ziels: Was bedeutet „Exit“?

Organisationen können unterschiedlichen Zielbildern folgen. Ein kompletter Ausstieg ist nicht die einzige Option.

Option A: Reduzierte MS365-Nutzung

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.

Option B: Souveräne Hybrid-Strategie

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.

Option C: Kompletter Exit als langfristiges Ziel

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.

---

Governance parallel zur MS365-Implementierung

Es sollte ein gemeinsames Programm für Implementierung und Exit-Fähigkeit geben, keine zwei separaten Projekte. Teilnehmer sollten sein:

• Geschäftsführung / CIO
• IT-Abteilung / Rechenzentrum
• Datenschutzbeauftragter
• Informationssicherheit
• Rechtsabteilung
• Betriebsrat / Personalrat
• Fachabteilungen / Endnutzer
• Einkauf
• Externe Beratung oder Anbieter

Dieser Rat entscheidet nicht nur über MS365-Konfigurationen, sondern auch über:

• Erlaubte Nutzungsszenarien
• Datenklassifizierung
• Alternative Plattformen
• Migrierbarkeit
• Lizenzstrategie
• Exit-Kriterien
• Evaluierung von Open-Source-Plattformen wie openDesk

---

Datenklassifizierung als zentrales Steuerungsinstrument

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.

---

MS365 so konfigurieren, dass ein Exit möglich bleibt

Vermeiden Sie bestimmte Lock-in-Fallen bereits bei der Baseline-Konfiguration.

Vermeiden oder einschränken

• Komplexe SharePoint-Workflows
• Power Automate als Standard-Workflow-Plattform
• Power Apps für zentrale administrative Prozesse ohne Exit-Konzept
• Proprietäre Teams-Strukturen als einziger Projekt-Workspace
• OneDrive als einzige Speicherlösung
• Microsoft Forms für langfristige Angelegenheiten
• OneNote als einziges Wissensarchiv
• Proprietäre Office-Makros ohne Dokumentation
• Zentrale Identität ausschließlich in Entra ID

Bevorzugen

• Offene Dateiformate, wo möglich: ODF, PDF/A, CSV, Markdown
• Standardisierte Schnittstellen: IMAP, CalDAV, CardDAV, WebDAV, SAML, OIDC
• Klar dokumentierte Gruppen- und Rechtekonzepte
• Export- und Archivierungsprozesse
• Externe Identitätsführung im eigenen IAM
• Trennung von Identität, Daten und Anwendung

---

Identitätsmanagement nicht an Microsoft verlieren

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:

• Die organisatorische Identität bleibt außerhalb von MS365 als Lead
• Gruppen und Rollen werden zentral verwaltet
• MS365 ist ein angehängter Dienst, nicht die Source of Truth
• Single Sign-On via SAML/OIDC
• MFA so unabhängig planbar wie möglich
• Spätere Entkopplung einzelner Dienste bleibt möglich

Dies ist eine der wichtigsten technischen Voraussetzungen für jeden späteren Exit.

---

Open-Source-Alternativen parallel pilotieren

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.

---

"No New Lock-in"-Regeln einführen

Parallel zur MS365-Implementierung sollten Organisationen Regeln verankern, die zukünftige Abhängigkeiten begrenzen.

Beispiele:

1. Neue zentrale administrative Prozesse dürfen nicht in Power Automate/Power Apps ohne ein Exit-Konzept implementiert werden.
2. SharePoint darf anfangs nur für einfache Team-Arbeitsdateien und Arbeitsbereiche genutzt werden.
3. Jede SharePoint-Seite benötigt einen Owner, eine Löschfrist und eine Export-Verantwortlichkeit.
4. Kritische Datenklassen dürfen nicht in OneDrive/Teams abgelegt werden.
5. Neue Projekte mit sensiblen Daten sollten Nextcloud/openDesk bevorzugen.
6. Dokumente mit Archivierungswert sollten in offenen oder archivfähigen Formaten gespeichert werden.
7. MS365-Gruppen dürfen nicht das einzige Rechte- und Organisationsmodell sein.
8. Für jede MS365-Komponente sollte eine mögliche Alternative dokumentiert werden.

Diese Regeln verhindern, dass sich Organisationen während der Implementierung tiefer binden, als beabsichtigt.

---

Parallelbetrieb bewusst steuern

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._