MS365 und die Notwendigkeit einer Exit-Strategie — Digitale Souveränität beginnt bei der Einführung | Thoughts & Talks

Einleitung: Die Einführung, die später zur Gefahr wird

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.

Die Lock-in-Falle: Warum MS365 so schwer wieder loszuwerden ist

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.

Technischer Lock-in

Identitätsmanagement: Wenn Entra ID zur führenden Identitätsquelle wird, ist eine spätere Ablösung komplex. Gruppen, Rollen und Berechtigungen werden zunehmend in Microsoft-spezifischen Strukturen abgebildet.
Datenhaltungsformate: SharePoint-Dokumentbibliotheken, Power BI-Reports, Power Apps-Apps, OneNote-Notebooks — all das sind proprietäre Formate, die Standardexportfunktionen nur unvollständig herauslösen.
Workflows und Automatisierung: In Power Automate oder SharePoint Workflows verbautes Prozesswissen lässt sich nur mit Aufwand in andere Systeme übertragen.
Integrationsschnittstellen: Graph API, Microsoft Graph Connector und proprietäre Authentifizierung verstehen nur Microsoft-Welten.

Organisatorischer Lock-in

Schulung: Mitarbeiter lernen Microsoft-Tools, nicht grundlegende Konzepte. Ein Wechsel erfordert umfangreiche Schulungsmaßnahmen.
Prozessdesign: Arbeitsabläufe entstehen um Teams-Strukturen, SharePoint-Sites oder OneDrive-Ordner zu arbeiten. Diese Strukturen werden tief in Organisationen eingegraben.
Change Management: Wenn MS365 tief in alle Abteilungen integriert ist, wird jede Änderung zur großen Transformationsprojekts.

Finanzieller Lock-in

Lizenzbindungen: Die Entscheidung für E5-Lizenzen und Erweiterungen schafft laufende Kosten. Ein Abbau ist oft politisch schwierig, weil bereits investiert wurde.
Kostenanstieg: Microsoft erhöht Preise regelmäßig. Ohne Exit-Optionen bleiben Organisationen Lieferantenänderungen ausgeliefert.
Opaque Kostentreiber: Warum werden Lizenzen benötigt? Wenn MS365 das Standardwerkzeug ist, werden Anforderungen automatisch zu Microsoft-Lizenzbedarfen.

Die Kosten der Untätigkeit: Techniker Schulden als Exit-Barriere

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:

Über 3 TB Daten ausschließlich in SharePoint
150+ Power Automate Workflows automatisieren kritische Prozesse
40+ Power Apps sind schwer in das Tagesgeschäft integriert
Alle Identitäten laufen in Entra ID

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.

Exit-by-Design: Das Grundprinzip

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.

Kernfragen bei der Einführung

Schon bei der Einführung sollten diese Fragen geklärt werden:

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

Die Exit-Strategie ist dann kein späteres Sonderprojekt, sondern Teil der MS365-Governance.

Strategische Zieldefinition: Was bedeutet "Exit"?

Organisationen können unterschiedliche Zielbilder verfolgen. Ein vollständiger Exit ist nicht die einzige Option.

Variante A: Reduzierte MS365-Nutzung

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.

Variante B: Souveräne Hybridstrategie

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.

Variante C: Vollständiger Exit als Langfristziel

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.

Governance parallel zur MS365-Einführung

Es sollte ein gemeinsames Programm für Einführung und Exit-Fähigkeit geben, nicht zwei getrennte Projekte. Beteiligt sein sollten:

Organisationsleitung / CIO
IT-Abteilung / Rechenzentrum
Datenschutzbeauftragte
Informationssicherheit
Rechtsabteilung
Personalrat / Betriebsrat
Fachabteilungen / Anwendende
Einkauf / Beschaffung
Ggf. externe Beratung oder Partnerverbund

Dieses Gremium entscheidet nicht nur über MS365-Konfigurationen, sondern auch über:

erlaubte Nutzungsszenarien
Datenklassifikation
Alternativdienste
Migrationsfähigkeit
Lizenzstrategie
Exit-Kriterien
Evaluierung von Open-Source-Plattformen wie openDesk

Datenklassifikation als zentrales Steuerungsinstrument

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.

MS365 so konfigurieren, dass der Exit möglich bleibt

Bereits bei der Einführung sollten bestimmte Lock-in-Fallen vermieden werden.

Vermeiden oder begrenzen

komplexe SharePoint-Workflows
Power Automate als Standard-Workflowplattform
Power Apps für zentrale Verwaltungsprozesse ohne Exit-Konzept
proprietäre Teams-Strukturen als alleinige Projektablage
OneDrive als einzige Speicherlösung
Microsoft Forms für langfristig relevante Erhebungen
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, Datenablage und Anwendung

Identitätsmanagement nicht an Microsoft verlieren

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:

Organisationsidentität bleibt außerhalb von MS365 führend
Gruppen und Rollen werden zentral verwaltet
MS365 ist angebundener Dienst, nicht die Quelle der Wahrheit
Single Sign-on über SAML/OIDC
MFA möglichst unabhängig planbar
spätere Ablösung einzelner Dienste bleibt möglich

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

Open-Source-Alternativen parallel pilotieren

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.

„No new lock-in“-Regeln einführen

Parallel zur MS365-Einführung sollten Organisationen Regeln beschließen, die zukünftige Abhängigkeiten begrenzen.

Beispiele:

Neue zentrale Verwaltungsprozesse dürfen nicht ohne Exit-Konzept in Power Automate/Power Apps umgesetzt werden.
SharePoint darf zunächst nur für einfache Datei- und Teamablagen genutzt werden.
Jede SharePoint-Site braucht Eigentümer, Löschfrist und Exportverantwortung.
Kritische Datenklassen dürfen nicht in OneDrive/Teams gespeichert werden.
Neue Projekte mit sensiblen Daten nutzen bevorzugt Nextcloud/openDesk.
Dokumente mit Archivwert müssen in offenen oder archivfähigen Formaten abgelegt werden.
MS365-Gruppen dürfen nicht das einzige Rechte- und Organisationsmodell sein.
Für jede MS365-Komponente wird eine mögliche Zielalternative dokumentiert.

Diese Regeln verhindern, dass Organisationen sich während der Einführung tiefer binden, als sie eigentlich möchten.

Parallelbetrieb bewusst gestalten

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:

Für allgemeine Kommunikation kann Teams zunächst erlaubt sein.
Für sensible Gremienarbeit wird openDesk/Nextcloud empfohlen.
Für öffentliches Material bleiben Web-Systeme führend.
Für kundennahe Projekte bleiben CRM-Systeme führend.
Für neue Projekträume wird openDesk bevorzugt pilotiert.
Für stark Microsoft-abhängige Szenarien wird ein Ablaufdatum oder Review-Termin gesetzt.

Exit-Plan pro MS365-Dienst erstellen

Bereits bei Einführung sollte für jeden Dienst ein „Exit-Steckbrief" existieren.

Dienst: OneDrive

Welche Daten dürfen hinein?
Wie werden Daten exportiert?
Zielsystem: Nextcloud/openDesk
Verantwortlich: IT-Abteilung
Risiken: Freigaben, externe Links, private Daten
Exit-Aufwand: mittel
Review nach: 12 Monaten

Dienst: Teams

Nutzung erlaubt für: Chat, Meetings, einfache Arbeitsgruppen
Nicht erlaubt für: dauerhafte Aktenablage, sensible Daten, kritische Prozesse
Zielalternativen: Matrix/Element, BigBlueButton, openDesk
Exportproblem: Chatverläufe und Kanalstruktur
Exit-Strategie: neue Gruppen später bevorzugt in openDesk

Dienst: SharePoint

Nutzung erlaubt für: einfache Dokumentenablagen
Nicht erlaubt für: komplexe Workflows ohne Genehmigung
Zielalternativen: Nextcloud, XWiki, DMS, OpenProject
Exit-Risiko: hoch
Pflicht: Site-Katalog, Verantwortliche, Exportkonzept

Dienst: Exchange Online

Nutzung erlaubt für: Mail/Kalender, falls beschlossen
Zielalternativen: bestehender Maildienst, SOGo, Open-Xchange
Exit-Risiko: hoch
Besonderheiten: Kalenderbeiträge, Ressourcenplanung, mobile Geräte, Archivierung

Vertragliche und beschaffungsrechtliche Exit-Klauseln

Parallel zur Einführung sollten Verträge und interne Beschaffungsrichtlinien angepasst werden.

Wichtige Anforderungen:

Datenexport in maschinenlesbaren Formaten
klare Regelungen zur Löschung nach Vertragsende
Unterstützung bei Migration
keine dauerhafte Bindung an proprietäre Schnittstellen
Dokumentation von APIs
Audit- und Nachweismöglichkeiten
Datenschutz-Folgenabschätzung
Transparenz über Unterauftragnehmer
Exit-Fristen und Übergangsregelungen
Vermeidung von automatischer funktionaler Ausweitung ohne neue Bewertung

Auch bei Open-Source-Alternativen sollen Betrieb, Support und Exit-Fähigkeit vertraglich bedacht werden.

Zeitliche Kopplung von Einführung und Exit-Strategie

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.

Praktisches Zielbild für Organisationen

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.

Wichtigste Handlungsempfehlungen

Kurz zusammengefasst:

MS365-Einführung und Exit-Strategie gemeinsam planen
Organisations-IAM als führendes Identitätssystem behalten
Datenklassifikation verbindlich einführen
SharePoint, Power Platform und Teams kontrolliert begrenzen
Offene Formate und Schnittstellen vorschreiben
openDesk-CE/Nextcloud/Collabora/Matrix/OpenProject parallel pilotieren
Für jeden MS365-Dienst einen Exit-Steckbrief erstellen
Keine kritischen Prozesse ohne dokumentierten Ausstiegsweg in MS365 bauen
Export- und Migrationstests schon während der Einführung durchführen
MS365-Lizenzen regelmäßig auf Reduktionspotenzial prüfen

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.

Quellen

openDesk-CE: opendesk.software
Nextcloud: nextcloud.com
Collabora Online: collaboraoffice.com
Matrix Foundation: matrix.org
Bundesamt für Sicherheit in der Informationstechnik: Cloud-Computing Empfehlungen
Kompetenzzentrum Open Source Software (Kosmosloud): openDesk-CE