Tenant-zu-Tenant-Migrationen gehören zu den technisch anspruchsvollsten Vorgängen im Microsoft 365-Ökosystem. Auf der Oberfläche erscheinen sie wie jede andere Migration: Postfächer verschieben, Dateien verschieben, Traffic umleiten. In der Praxis umfassen sie Identitätssynchronisation über zwei separate Entra ID-Mandanten, Lizenzverwaltung mit harten Fristen, selten dokumentierte Service-Abhängigkeiten und die nahezu sichere Gewissheit, dass während des Cutover-Fensters etwas Unerwartetes passiert.
Migrationen, die reibungslos verlaufen, sind nicht jene, bei denen nichts Unerwartetes passiert. Sie sind jene, bei denen das Team gut genug vorbereitet ist, um damit umzugehen.
Diese Checkliste umfasst 47 Prüfpunkte in sieben Arbeitsbereichen. Nicht abzuhakende Punkte sind Ihr Risikoregister für das Projekt.
Bevor Benutzerdaten verschoben werden, muss die Identität in beiden Mandanten in einem bekannten Zustand sein.
- UPN-Ausrichtung bestätigt. Das Ziel-UPN-Suffix (z. B. unternehmen.de) ist im Ziel-Entra ID-Mandanten hinzugefügt und verifiziert.
- Entra ID Connect-Synchronisierungsumfang definiert. Wenn die Quelle Entra ID Connect zur Synchronisierung mit lokalem Active Directory verwendet, ist der Synchronisierungsumfang des Zielmandanten definiert und getestet.
- Doppelte UPNs geprüft. Vergleich der Quell- und Ziel-Benutzerlisten zur Identifizierung von UPN-Konflikten. Konflikte verursachen stille Migrationsfehler.
- Gastkonten auditiert. Quell-Mandant-Gäste, die migriert oder übergeleitet werden müssen, sind identifiziert. Externe Mitarbeiter, die zu internen Benutzern im Ziel werden, sind dokumentiert.
- Dienstprinzipale und App-Registrierungen inventarisiert. Anwendungen, die im Quell-Entra ID-Mandanten registriert sind und im Ziel äquivalente Registrierungen benötigen, sind aufgelistet.
- Verwaltete Identitäten bewertet. Azure-Ressourcen, die verwaltete Identitäten im Quell-Abonnement verwenden, benötigen einen Migrationsplan.
- Break-Glass-Konten im Ziel erstellt. Notfallzugriffskonten im Zielmandanten sind erstellt und getestet.
- Verzeichnis-Synchronisierungskonflikte aufgelöst. Objekte in der Quelle mit Synchronisierungsfehlern sind bereinigt.
Lizenztiming in Tenant-zu-Tenant-Migrationen ist eine Einschränkung, kein Detail. Fehler hier verursachen Serviceunterbrechungen.
- Lizenzverfügbarkeit im Zielmandanten bestätigt. Ausreichend Lizenzen des richtigen Typs sind im Zielmandanten verfügbar, bevor Benutzer migriert werden.
- Lizenz-Zuweisungszeitplan geplant. Das Fenster zwischen Entnahme der Quell-Lizenz und Zuweisung der Ziel-Lizenz muss minimiert werden. Für Exchange verursacht diese Lücke Zustellungsfehler.
- Spezialisierte Lizenzen identifiziert. Benutzer mit Defender für Endpoint, Purview-Compliance oder anderen speziellen Lizenzen benötigen entsprechende Lizenzen im Ziel.
- Testlizenzen aus dem Migrationsumfang ausgeschlossen.
- Post-Migrations-Lizenz-Audit geplant. Nach der Migration bestätigt ein Lizenz-Audit, dass alle Benutzer die richtigen Berechtigungen haben.
Exchange Online-Migration ist der Arbeitsbereich mit den sichtbarsten Fehlermodi.
- MX-Record-TTL im Voraus reduziert. Mindestens 48 Stunden vor dem Cutover auf 300 Sekunden (5 Minuten) reduzieren.
- Freigegebene Postfächer und Ressourcenpostfächer inventarisiert. Alle freigegebenen Postfächer, Raum- und Ausstattungspostfächer mit ihren aktuellen Eigentümern und Berechtigungen dokumentiert.
- Verteilerlisten und E-Mail-aktivierte Gruppen zugeordnet. Jede Verteilerliste im Quellmandanten benötigt ein Äquivalent im Ziel.
- Mail-Kontakte für Koexistenz konfiguriert. Während der Migrationsperiode müssen bereits migrierte und noch nicht migrierte Benutzer gegenseitig erreichbar sein.
- Mail-Flow-Regeln (Transportregeln) dokumentiert. Verschlüsselungs-, Routing- und Compliance-Transportregeln dokumentiert und für die Neuerstellung im Ziel vorbereitet.
- Exchange Online Protection-Konfiguration überprüft. Anti-Spam-, Anti-Phishing- und Safe-Links-Richtlinien dokumentiert.
- Archiv-Postfächer berücksichtigt. Benutzer mit Exchange Online Archiv oder Compliance-Archiv benötigen das Archiv im Migrationsumfang.
- SMTP-Relay-Konfiguration verifiziert. Lokale Systeme, Drucker und Anwendungen, die SMTP-Relay über Exchange Online nutzen, müssen auf den Relay-Endpunkt des Zielmandanten umkonfiguriert werden.
- Invalidierung von Teams-Meeting-Links kommuniziert. Alle bestehenden Teams-Meeting-Links aus dem Quellmandanten funktionieren nach dem Cutover nicht mehr. Benutzer müssen wiederkehrende Meetings neu planen. Kommunikationsplan erforderlich.
- Teams-Kanal-Registerkarten und Connectors inventarisiert. Benutzerdefinierte Registerkarten, Power-Automate-Connectors und Drittanbieter-Integrationen müssen identifiziert und im Ziel neu konfiguriert werden.
- SharePoint-Berechtigungen dokumentiert. Berechtigungen auf Website-Ebene, eindeutige Ordnerberechtigungen und freigegebene Links in SharePoint vor der Migration dokumentiert.
- Externe Freigabe-Links adressiert. "Jeder"- und "Personen in Ihrer Organisation"-Links werden nach der Migration ungültig.
- OneDrive-Migrationsquota verifiziert. Benutzer mit großen OneDrive-Repositories (>100 GB) benötigen einen Migrationszeitplan, der die Übertragungsgeschwindigkeit berücksichtigt.
- SharePoint-Website-Vorlagenkompatibilität geprüft. Benutzerdefinierte Website-Vorlagen und Branding an einem repräsentativen Sample getestet.
- Teams-Aufzeichnungsspeicher migriert. Teams-Meeting-Aufzeichnungen in SharePoint oder OneDrive explizit in den Migrationsumfang aufgenommen.
- Autopilot-Profile im Zielmandanten vorbereitet. Windows-Autopilot-Bereitstellungsprofile erstellt und getestet.
- Intune-Compliance-Richtlinien neu erstellt. Geräte-Compliance-Richtlinien, Konfigurationsprofile und App-Schutzrichtlinien im Ziel-Intune-Mandanten neu erstellt — kein Export/Import, sondern Neuaufbau aus Dokumentation.
- Geräte-Registrierungsstrategie bestätigt. Entscheidung: Neuregistrierung (Gerät zurückgesetzt) oder Migration mit einem Tool wie dem Opsora Endpoint Migrator, der Geräte ohne Wipe verschiebt.
- Conditional-Access-Richtlinien vorbereitet. Zielmandanten-Richtlinien müssen konfiguriert sein, bevor die Gerätmigration beginnt.
- BYOD (persönliche Geräte) adressiert. Persönliche Geräte, die im Quell-Intune-Mandanten registriert sind, benötigen einen separaten Kommunikations- und Migrationsplan.
- Zertifikatsprofile bewertet. Geräte mit SCEP- oder PKCS-Zertifikatsprofilen benötigen replizierte oder äquivalente Zertifikatsinfrastruktur im Ziel.
- Migrationswellen definiert. Benutzer nach Abteilung, Standort oder Risikotoleranz in Wellen gruppiert. Die erste Welle sollte IT-Personal und freiwillige Tester sein.
- Rollback-Verfahren dokumentiert. Bei kritischem Ausfall: Verfahren zur Wiederherstellung des Dienstes dokumentiert und getestet.
- Kommunikationsplan genehmigt. Benutzer erhalten mindestens 5 Arbeitstage vorher eine verständliche Benachrichtigung über Migrationsfenster, Änderungen und Ansprechpartner.
- Helpdesk gebrieft und eingeplant. First-Level-Support weiß, was passiert, kennt häufige Probleme und wie sie zu lösen sind. Zusätzliche Helpdesk-Abdeckung für 48 Stunden nach jeder Migrationswelle.
- Migrationstool an einer Pilotgruppe getestet. Das Migrationstool an einer Pilotgruppe von 5–10 Benutzern getestet, bevor produktive Wellen beginnen.
- DNS-Änderungsberechtigung bestätigt. Wer hat Zugriff auf DNS-Eintragsänderungen, und wie lange dauert die Propagierung? Muss vor dem Cutover-Fenster bestätigt sein.
- Cutover-Fenster-Timing vereinbart. Migrations-Cutover sollte außerhalb der Geschäftszeiten der betroffenen Benutzerpopulation erfolgen.
- Post-Cutover-Verifikationstests definiert. Standardtests: Test-E-Mail senden und empfangen, auf freigegebenes Postfach zugreifen, OneDrive-Sync verifizieren, Teams-Zugriff bestätigen, Conditional-Access-Konformität prüfen.
- Zeitplan für Quellmandanten-Dekommissionierung vereinbart. Wann Lizenzen entfernt und wann der Mandant geschlossen wird.
- DNS-Bereinigung abgeschlossen. Alte MX-Einträge, SPF-Einträge, DKIM-Selektoren und andere DNS-Einträge, die auf den Quellmandanten verweisen, entfernt.
- Residualer Zugriff widerrufen. Dienstkonten, Gastkonten und Admin-Konten im Quellmandanten überprüft und entfernt.
- Dokumentation aktualisiert. IT-Dokumentation, Runbooks, Onboarding-Leitfäden und Support-Verfahren auf den neuen Mandanten aktualisiert.
- Post-Migrations-Gesundheitscheck geplant. 30 Tage nach der letzten Migrationswelle: Lizenz-Compliance prüfen, verwaiste Konten bestätigen, Überwachungsprotokollaufbewahrung überprüfen, Conditional-Access-Richtlinieneffektivität prüfen.
Mail-Koexistenz nicht konfiguriert. Der störendste Fehlermodus in einer phasenweisen Tenant-zu-Tenant-Migration ist, dass keine E-Mails zwischen bereits migrierten und noch nicht migrierten Benutzern fließen. Dies erfordert explizite Koexistenzkonfiguration und muss getestet werden, bevor der erste Benutzer wechselt.
Gerätemigrierung unterschätzt. Unternehmen, die Geräte löschen und neu registrieren wollen, stellen häufig fest, dass ein erheblicher Teil des Geräteparks nicht remote erreichbar ist. Ein Migrationsansatz, der die Geräteregistrierung ohne Wipe verschiebt — wie der Opsora Endpoint Migrator — eliminiert diese Problemklasse.
Teams-Meeting-Link-Kommunikation vergessen. Jedes geplante Teams-Meeting in der Organisation hat einen Link, der beim Cutover nicht mehr funktioniert. Das wird zum Support-Vorfall, wenn Benutzer nicht im Voraus gewarnt wurden.
Tenant-zu-Tenant-Migrationen sind nicht von Natur aus gefährlich, aber sie verzeihen keine unvollständige Vorbereitung. Jeder Punkt auf dieser Checkliste repräsentiert einen entdeckten Fehlermodus aus echten Migrationen.
Wenn Sie eine Migration planen und erfahrene Programmleitung benötigen, erfahren Sie, wie Opsora Tenant-zu-Tenant-Migrationen durchführt.