Digital Souverän Digital Souverän
Gespräch anfragen

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

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.

Porträt von Nicolas Grossman, Berater für digitale Systeme, Souveränität und Strategie bei DigiPub

Von Digitale Systeme, Souveränität & Strategie
Veröffentlicht am

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

Auf dieser Seite · 4 Min. Lesezeit

01 Bevor der erste Schritt beginnt 02 Kurze Schrittübersicht 03 Die 8 Schritte Kernteil 04 Fehlerbehebung 05 Abschlussprüfung

Bevor der erste Schritt beginnt

Diese Anleitung geht nicht von einem einzigen, immer gleichen Ablauf aus, sondern von einer Vorentscheidung, die je nach Unternehmen unterschiedlich ausfällt.

Entscheidungshilfe: 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

Benötigt für den Einstieg

  • Ü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)
  • Realistischer Zeitrahmen: mehrere Monate für eine vollständige Umstellung, nicht Wochen

Risiko vorab einordnen

Diese Migration ist keine einmalige Aktion, sondern beginnt einen dauerhaften Doppelbetrieb-Zeitraum mit doppelten Kosten (Parallellizenzen) und zusätzlichem administrativem Aufwand, der bei der Zeitplanung eingepreist werden muss.

Kurze Schrittübersicht

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

Die 8 Schritte

  1. 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: Diese Föderation ist kein vollständig souveränes Setup – Entra ID verarbeitet weiterhin die Authentifizierungs-Anfrage und stellt M365-Tokens aus, solange M365 im Einsatz bleibt. Was sich dadurch verlagert, ist die Kontrolle über Authentifizierung, Credential-Speicher und Sitzungsverwaltung – nicht die vollständige Unabhängigkeit von Microsoft. Für Unternehmen mit der Anforderung „keine US-Infrastruktur darf irgendwo im Identitätsfluss beteiligt sein“ reicht dieser Zwischenschritt nicht aus.

    ✓ ZwischenresultatTestnutzer kann sich über Keycloak anmelden und weiterhin auf M365 zugreifen.

  2. 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).

    ✓ ZwischenresultatSchriftliche Festlegung von Pilotabteilung, Startkomponente und Erfolgskriterien für Schritt 5.

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

    ✓ ZwischenresultatPilotabteilung kann parallel auf beide Systeme zugreifen, ohne dass eines davon abgeschaltet wurde.

  4. 04

    Daten migrieren

    Für die Dateimigration (SharePoint/OneDrive → Nextcloud) die offizielle Nextcloud-Migrationsdokumentation sowie die openDesk-Migrationshinweise (bei jedem Versions-Update im Changelog verlinkt) als Grundlage nutzen; ergänzend stehen Werkzeuge für hybriden Betrieb zur Verfügung (z. B. Synchronisations-Tools, die Kalender/Kontakte zwischen beiden Systemen während der Übergangszeit abgleichen). Migration zunächst nur für die Pilotabteilung durchführen, nicht unternehmensweit.

    ✓ ZwischenresultatAlle Dateien der Pilotabteilung sind im neuen System vorhanden, Stichprobenprüfung auf Vollständigkeit durchgeführt.

  5. 05

    Nutzerakzeptanz und Stabilität prüfen

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

    ✓ ZwischenresultatDokumentierte Entscheidung: Ausrollen fortsetzen, Anpassungen vornehmen oder Ansatz überdenken.

  6. 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 auch bei Identity-Migrationen allgemein üblich.

    ✓ ZwischenresultatRollout-Plan mit Reihenfolge und Zeitrahmen für die verbleibenden Komponenten/Abteilungen.

  7. 07

    Laufenden Betrieb etablieren (Day-2 Operations)

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

    Achtung: Dieser Schritt wird in Migrationsanleitungen häufig übersehen, ist aber entscheidend. Ein aus mehreren Open-Source-Komponenten zusammengesetzter Stack erfordert einen eigenständigen Patch-Prozess – Sicherheitsupdates erscheinen unabhängig vom Feature-Rhythmus, teils mehrfach im Monat. Ohne einen eingespielten Prozess sammeln sich offene Sicherheitslücken an.

    ✓ ZwischenresultatDokumentierter Prozess mit benannter Verantwortlichkeit für Sicherheitsupdates.

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

    ✓ ZwischenresultatM365-Lizenzen für migrierte Nutzer sind gekündigt oder auf Minimal-Plan reduziert, Doppelkosten entfallen für diesen Bereich.

Fehlerbehebung

Abschlussprüfung

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.