Co-Existenz statt Big-Bang: Phasenweise Migration von Microsoft 365

Q: Was tun, wenn die Identitäts-Synchronisation zwischen Keycloak und Entra ID fehlschlägt?

Es gibt keinen nativen Konnektor von Keycloak zu Entra ID – die Synchronisation von Attributen (Abteilung, Vorgesetzte:r, Ein-/Austrittsdatum) muss eigens aufgebaut werden, üblicherweise über SCIM oder ein Custom-Skript. Ohne diese Synchronisation lösen Entra-ID-Governance-Workflows (Joiner/Mover/Leaver) nicht mehr korrekt aus.

Q: Was tun, wenn Mitarbeitende weiterhin das alte System nutzen (Schatten-IT-Risiko)?

Während der Parallelphase ist das ein normales Übergangsphänomen. Klar kommunizieren, bis wann welches System verbindlich wird, und den Zugriff erst nach Ablauf dieser Frist gemäß Schritt 8 abschalten.

Q: Was tun, wenn eine Abteilung nach der Migration eine kritische Funktion vermisst?

Nicht vollständig zurückmigrieren – stattdessen prüfen, ob ein Koexistenz-Modell für diese spezifische Funktion (z. B. weiterhin Teams für externe Kunden nutzen, während interne Kommunikation auf Element läuft) sinnvoller ist als ein erzwungener Komplett-Umstieg.

Umsetzung & Migration How-To

Eine Migration weg von Microsoft 365 gelingt am zuverlässigsten in Phasen: erst die Identitäts-Grundlage, dann eine Pilotabteilung, dann Komponente für Komponente. Diese Anleitung führt in acht Schritten von der Vorentscheidung bis zur Abschaltung des Alt-Systems – jeweils mit prüfbarem Zwischenresultat.

Von Nicolas GrossmanDigitale Systeme, Souveränität & Strategie
Veröffentlicht am 24. September 2026

Co-Existenz statt Big-Bang: Phasenweise Migration von Microsoft 365

Auf dieser Seite · 4 Min. Lesezeit

01 Voraussetzungen und Startpunkt 02 Die acht Schritte im Überblick 03 Die 8 Schritte Kernteil 04 Fehlerbehebung 05 Wann ist die Migration abgeschlossen?

Voraussetzungen und Startpunkt

Womit die Migration beginnt, hängt vom Unternehmen ab. Die Tabelle zeigt, welcher Startpunkt zu welcher Ausgangslage passt.

Womit starten?

Empfehlung

Ausgangslage	Empfohlener Startpunkt
Höchster Compliance-/NIS2-Druck bei einer bestimmten Datenkategorie	Mit der Komponente beginnen, die diese Daten hält (z. B. Cloud-Speicher für sensible Dokumente)
Keine eigene IT-Kapazität für Selbstbetrieb	Partnerbetrieb/SaaS-Variante wählen, nicht Self-Hosting auf eigener Kubernetes-Infrastruktur
Geringes Risiko, viele Testfreiwillige vorhanden	Mit einer nicht-kritischen Abteilung als Pilotgruppe beginnen, unabhängig von der Komponente

Das wird für den Einstieg benötigt

Übersicht der aktuell genutzten M365-Dienste pro Abteilung (Mail, Dateiablage, Chat, Video)
Entscheidung für eine Zielarchitektur: vollständiges openDesk oder Einzelkomponenten (z. B. nur Nextcloud)
Eine IT-Person oder ein Partner mit Kubernetes-/Identity-Management-Erfahrung (bei Self-Hosting zwingend)
Zeitrahmen: mehrere Monate für eine vollständige Umstellung.

Risiko vorab einordnen

Die Migration bedeutet einen Zeitraum im Doppelbetrieb, mit doppelten Lizenzkosten und zusätzlichem Administrationsaufwand. Beides gehört in die Zeitplanung.

Die acht Schritte im Überblick

01 Identitäts-Grundlage schaffen (Föderation statt Komplett-Wechsel)
02 Pilotbereich und erste Komponente festlegen
03 Komponente parallel aufbauen und testen
04 Daten für den Pilotbereich migrieren
05 Nutzerakzeptanz und Stabilität prüfen
06 Schrittweise auf weitere Komponenten/Abteilungen ausrollen
07 Laufenden Betrieb etablieren
08 Alt-System für migrierte Bereiche abschalten

Die 8 Schritte

01

Identitäts-Grundlage schaffen

Keycloak (bzw. bei openDesk: Univention Nubus, das auf Keycloak basiert) als Identity Provider einrichten und per SAML/OIDC mit Entra ID föderieren, sodass Microsoft 365 währenddessen weiter funktioniert. Ort: Keycloak Admin Console (Identity Providers → SAML v2.0) und Entra ID Enterprise Applications.

Achtung: Die Föderation verlagert die Kontrolle über Authentifizierung, Credential-Speicher und Sitzungsverwaltung zu Keycloak. Entra ID verarbeitet weiterhin Authentifizierungs-Anfragen und stellt M365-Tokens aus, solange M365 im Einsatz bleibt. Wer keine US-Infrastruktur im Identitätsfluss zulassen darf, ist damit noch nicht am Ziel.

Prüfen:Testnutzer kann sich über Keycloak anmelden und weiterhin auf M365 zugreifen.
02

Pilotbereich und erste Komponente festlegen

Anhand der Entscheidungstabelle oben eine Abteilung und eine Komponente auswählen (Beispiel im weiteren Verlauf: Cloud-Speicher/Nextcloud für eine nicht-kritische Abteilung).

Prüfen:Schriftliche Festlegung von Pilotabteilung, Startkomponente und Erfolgskriterien für Schritt 5.
03

Komponente parallel aufbauen

Zielkomponente (z. B. Nextcloud) auf gewählter Infrastruktur (Self-Hosting, Partnerbetrieb oder SaaS) einrichten, ohne den bestehenden M365-Zugriff der Pilotabteilung zu deaktivieren.

Prüfen:Pilotabteilung kann parallel auf beide Systeme zugreifen, ohne dass eines davon abgeschaltet wurde.
04

Daten migrieren

Für die Dateimigration (SharePoint/OneDrive → Nextcloud) dienen die Nextcloud-Dokumentation und die openDesk-Migrationshinweise als Grundlage. Migration zunächst nur für die Pilotabteilung durchführen, nicht unternehmensweit.

Prüfen:Alle Dateien der Pilotabteilung sind im neuen System vorhanden, Stichprobenprüfung auf Vollständigkeit durchgeführt.
05

Nutzerakzeptanz und Stabilität prüfen

Wir empfehlen 2–4 Wochen Beobachtungszeitraum mit der Pilotabteilung, Feedback zu Bedienkomfort und fehlenden Funktionen einholen.

Prüfen:Dokumentierte Entscheidung: Ausrollen fortsetzen, Anpassungen vornehmen oder Ansatz überdenken.
06

Schrittweise ausrollen

Nach erfolgreicher Pilotphase: nächste Komponente (z. B. E-Mail über Open-Xchange) oder nächste Abteilung nach demselben Muster (Schritt 3–5) hinzunehmen. Priorisierung nach Risiko: unkritische Anwendungen zuerst. Wie ein E-Mail-Umzug im Einzelnen abläuft, zeigt die Anleitung E-Mail von Microsoft 365 zu Mailcow migrieren am Beispiel von Mailcow.

Prüfen:Rollout-Plan mit Reihenfolge und Zeitrahmen für die verbleibenden Komponenten/Abteilungen.
07

Laufenden Betrieb etablieren

Verantwortlichkeit für Patch-Management festlegen (eigene IT oder vertraglich beim Partnerbetreiber), Update-Monitoring einrichten.

Achtung: Ein aus mehreren Open-Source-Komponenten zusammengesetzter Stack braucht einen eigenen Patch-Prozess. Sicherheitsupdates erscheinen unabhängig vom Feature-Rhythmus, teils mehrfach im Monat (siehe die openDesk-Release-Hinweise). Ohne einen eingespielten Prozess sammeln sich offene Sicherheitslücken an.

Prüfen:Dokumentierter Prozess mit benannter Verantwortlichkeit für Sicherheitsupdates.
08

Alt-System abschalten (für migrierte Bereiche)

Erst nach bestätigter Stabilität (Schritt 5 wiederholt für jede neue Komponente/Abteilung) den M365-Zugriff für die betroffenen Nutzer deaktivieren – nicht vorher, um Datenverlustrisiko zu vermeiden.

Prüfen:M365-Lizenzen für migrierte Nutzer sind gekündigt oder auf Minimal-Plan reduziert, Doppelkosten entfallen für diesen Bereich.

Fehlerbehebung

01Was tun, wenn die Identitäts-Synchronisation zwischen Keycloak und Entra ID fehlschlägt?

02Was tun, wenn Mitarbeitende weiterhin das alte System nutzen (Schatten-IT-Risiko)?

03Was tun, wenn eine Abteilung nach der Migration eine kritische Funktion vermisst?

Wann ist die Migration abgeschlossen?

Die Migration eines Bereichs gilt als abgeschlossen, wenn:

alle Daten vollständig übertragen sind,
die Pilot-/Nutzergruppe seit mindestens 4 Wochen stabil im neuen System arbeitet,
der Patch-Management-Prozess dokumentiert und einer Person/Stelle zugeordnet ist,
die alten Lizenzen für diesen Bereich gekündigt sind.

Als Nächstes lesen

Vergleich · Kosten & Wirtschaftlichkeit

openDesk vs. Microsoft 365: Was der Umstieg für den Mittelstand wirklich bedeutet

Für Unternehmen mit Souveränitätspriorität die bessere Wahl – aber nicht ohne Voraussetzungen. Ein Vergleich entlang des gesamten Nutzungszeitraums.

Listicle · Tools & Alternativen

Europäische Cloud-Anbieter im Überblick: IONOS, STACKIT & Co.

Sechs europäische Cloud-Infrastruktur-Anbieter ohne US-Mutterkonzern im Vergleich – mit Auswahlhilfe.

← Alle Beiträge im Überblick

Alle Leistungen im Überblick →

Migration planen, ohne den Betrieb zu riskieren?

Migration gemeinsam planen

Gespräch anfragen →

Wir klären mit Ihnen Pilotbereich, Startkomponente und Zeitrahmen.