Fusionieren Unternehmen oder spalten sich Teile ab, landet man im M365-Umfeld fast immer bei der Tenant-zu-Tenant-Migration. In vielen Tenants, die ich zuletzt betreut habe, geht es derzeit vor allem um die native Unterstützung für Exchange-Online-Postfächer und OneDrive. Noch vor ein paar Jahren kam man dafür an Dritttools kaum vorbei. Mit der sogenannten Migration Application und der Cross-Tenant Mailbox Migration (offizielle Dokumentation) bietet Microsoft nun einen nativen, mehrstufigen Prozess an. So reibungslos, wie das Marketing ihn beschreibt, läuft er in der Praxis allerdings nicht.

Vor der ersten Migration müssen beide Tenants einander vertrauen

Am Anfang steht die Vorbereitung. Im Ziel-Tenant registriert ihr zunächst eine Migration Application im Entra-Portal (unter Entra ID → Anwendungen), damit zwischen den beiden Tenants eine Vertrauensstellung entsteht. Außerdem braucht es in beiden Tenants eine Organisationsbeziehung, die ihr in der Exchange Online PowerShell einrichtet und nicht im Admin Center. Fehlt sie, bleiben die Tenants für die Migration komplett voneinander getrennt. In jedem Quell-Tenant legt ihr zudem eine E-Mail-aktivierte Sicherheitsgruppe an, über die bestimmt wird, welche Benutzer migriert werden. Die MailUser-Objekte im Ziel-Tenant brauchen zwingend die ExchangeGuid und den legacyExchangeDN, Letzteren als X500-Proxyadresse. Nur so lassen sich die Postfachidentitäten sauber zuordnen. Genau daran scheitern Projekte häufig, vor allem wenn die Identitäten vorher lediglich synchronisiert wurden. Wie Cross-Tenant Synchronization und Migration zusammenspielen, beschreibe ich ausführlicher in meinem Beitrag zur Cross-Tenant-Synchronisierung.

Jeder Benutzer im Ziel-Tenant benötigt außerdem eine Lizenz vom Typ Cross-Tenant User Data Migration. Ohne sie hängt die Migration bereits beim Start fest, und das merkt man leider oft erst spät im Projekt. Wer blind auf die automatische Lizenzzuweisung vertraut, fällt hier gern herein.

# Zuweisung der Cross-Tenant Migration Lizenz
# PowerShell 7, Microsoft Graph PowerShell-Modul, Global Admin oder Lizenzadministrator im Ziel-Tenant erforderlich
Update-MgUserLicense -UserId [email protected] -AddLicenses @(@{SkuId = 'c1d23c74-d3e9-43b1-8c5e-d9c1b0cc1d48'})

Die OneDrive-Migration macht Fortschritte, hat aber noch Lücken

Für OneDrive gibt es inzwischen ebenfalls eine native Lösung (Dokumentation). Sie stützt sich auf dieselben Vertrauensstellungen wie die Postfachmigration, und auch der Ablauf ist ähnlich: Im Ziel-Tenant kommt die Migration Application zum Einsatz, in der OneDrive-Admin-Konsole verbindet ihr Quelle und Ziel, und den Migrationsauftrag startet ihr anschließend per PowerShell-Skript oder über die Konsole. Kopiert werden dabei nur die Inhalte. Metadaten wie Links, die außerhalb des Tenants geteilt wurden, Freigaben für externe Nutzer und Workflows bleiben auf der Strecke. Ebenfalls nicht migriert werden etwa die OneDrive-Einstellungen, Inhalte aus dem Personal Vault und Dateien mit Sensitivity Labels, solange der Ziel-Tenant diese Labels nicht kennt.

Praxistipp: Prüft vor dem Cutover unbedingt, wie sich Freigabelinks und Zugriffsrechte nach der Migration verhalten. Bei geteilten Dokumenten haben wir in Pilotprojekten immer wieder Überraschungen erlebt.

Identitäten, MailUser-Objekte und Cross-Tenant Sync greifen ineinander

Damit eine Postfachmigration sauber durchläuft, muss die Identität im Ziel-Tenant schon vorhanden sein. Dafür sorgt entweder eine mandantenübergreifende Synchronisierung per Entra ID Cross-Tenant Synchronization, oder ihr legt die MailUser-Objekte von Hand an. Die Synchronisierung läuft parallel zur Migration weiter, damit Identitätsbeziehung und Entra-ID-Objekte konsistent bleiben. Für eine Übergangszeit existieren beide Tenants also in einer Art „Koexistenz“ nebeneinander, und die will gepflegt sein. Wer Cross-Tenant Sync bisher nicht eingeführt hat, sollte für den eigenen Fall genau abwägen, was dafür und was dagegen spricht. Meine Erfahrungen dazu habe ich im Beitrag Cross-Tenant-Synchronisierung: B2B-Nutzer automatisch bereitstellen zusammengetragen.

Ohne korrekt zugeordnete ExchangeGuid und legacyExchangeDN an den MailUser-Objekten funktionieren Outlook-Profile und Kalendereinträge nicht richtig, besonders Serientermine. In Projekten sehe ich oft, dass diese Werte nicht als X500-Proxyadresse gesetzt oder nach der Migration wieder gelöscht werden. Bleiben sie dagegen korrekt erhalten, arbeiten Autovervollständigen, Antworten auf ältere Mails und der Kalender weiter wie gewohnt.

Das folgende vereinfachte Ablaufdiagramm zeigt, wie die einzelnen Schritte der Cross-Tenant-Mailbox-Migration technisch aufeinander aufbauen:

flowchart TD
    Quelle["Quell-Tenant"] --> OrgBeziehungQ["Org.-Beziehung konfigurieren"]
    Ziel["Ziel-Tenant"] --> OrgBeziehungZ["Org.-Beziehung konfigurieren"]
    OrgBeziehungQ --> MigrationApp["Migration Application registrieren"]
    OrgBeziehungZ --> MigrationApp
    MigrationApp --> Lizenz["Lizenz zuweisen"]
    Lizenz --> MailUser["MailUser-Objekt anlegen"]
    MailUser --> MigrationStart["Migration starten"]
    MigrationStart --> Postfach["Postfach migriert"]

Abbildung: Ablauf der nativen Cross-Tenant-Mailbox-Migration

Manche Daten bleiben im alten Tenant zurück

Trotz der Fortschritte gibt es nach wie vor deutliche Grenzen. Nicht alle Postfacheinstellungen ziehen mit um, ebenso wenig bestimmte Compliance- und Litigation-Hold-Daten oder die Audit-Logs. Häufig werde ich gefragt, ob die Cross-Tenant-Migration auch Teams-Chats, Planner-Aufgaben oder Delegierungen automatisch übernimmt. Das tut sie bis heute nicht. Bei OneDrive verlieren Freigabelinks für externe Nutzer nach der Migration ihre Gültigkeit, und Workflows sowie Power-Automate-Flows verbleiben im alten Tenant. Wer mit komplexen Freigabestrukturen arbeitet, sollte das früh an die Betroffenen weitergeben.

Heikel ist auch die Planung des Cutovers. Viele unterschätzen, wie viel Zeit das endgültige Umschalten und die Nacharbeiten kosten, also neue Outlook-Profile, die Kontrolle der Proxyadressen und gegebenenfalls angepasste Regeln und Signaturen. Gut gefahren bin ich in Projekten damit, zunächst eine kleine Pilotgruppe durch den kompletten Prozess einschließlich OneDrive-Migration zu schicken, bevor alle anderen folgen. Für die Gesamtplanung ist die Microsoft-Vorlage zu Mergers, Acquisitions and Divestitures hilfreich, eigene Tests erspart sie euch aber nicht.

Die native Migration ist ein Fortschritt mit Tücken

Aus Sicht eines Admins bringt die native Tenant-zu-Tenant-Migration für Exchange Online und OneDrive einen klaren Fortschritt, besonders in größeren Projekten, die ohne Werkzeuge von Drittherstellern auskommen sollen. Vieles bleibt trotzdem Handarbeit, vor allem das Identitätsmapping und die Lizenzzuweisung. Auch die Koexistenzphase mit Cross-Tenant-Synchronisierung verdient Aufmerksamkeit, denn gerade dann tauchen viele kleine Probleme mit Proxyadressen und Zugriffsrechten auf. Wer sich gründlich vorbereitet, mit Pilotgruppen beginnt und die technischen Hürden rund um ExchangeGuid, X500 und Lizenzen beherrscht, migriert heute deutlich verlässlicher als noch vor zwei Jahren.