Microsoft 365 Migration Orchestrator: Nahtlose Tenant-zu-Tenant Migration

Tenant-zu-Tenant-Migrationen in Microsoft 365 haben den Ruf, mühsam zu sein. Wenn zwei Unternehmen fusionieren oder ein Geschäftsbereich ausgegliedert wird, erforderte das Verschieben von E-Mails, Dateien und Teams-Daten von einem Microsoft-365-Tenant in einen anderen bisher teure Drittanbieter-Tools, monatelange Planung und ein erhebliches Risiko für Datenverluste oder -beschädigungen.

Der Migration Orchestrator von Microsoft ändert das Bild. Es ist ein natives Microsoft-Werkzeug — keine Drittanbieterlizenz erforderlich — das die Orchestrierung tenantübergreifender Workload-Verschiebungen mit Abhängigkeitserkennung übernimmt. Dieser Beitrag erklärt, was es konkret leistet, wo seine Grenzen liegen und welche Planungsschritte darüber entscheiden, ob eine Migration gelingt oder scheitert. Unser Managed-Microsoft-365-Service umfasst vollständige Migrationsunterstützung bei Fusionen, Übernahmen und Reorganisationen.

Wann eine Tenant-zu-Tenant-Migration wirklich nötig ist

Nicht jedes Szenario erfordert eine vollständige Tenant-Migration. Es lohnt sich, vorab zu klären, welche Situation vorliegt:

• Fusion oder Übernahme: Unternehmen A übernimmt Unternehmen B. Beide haben bestehende Microsoft-365-Tenants. Das Ziel ist die Konsolidierung in einem einzigen Tenant.
• Ausgliederung oder Spin-off: Ein Geschäftsbereich trennt sich vom Mutterunternehmen und benötigt einen eigenen Microsoft-365-Tenant mit seinen historischen Daten.
• Rebranding mit Domänenwechsel: Ein Unternehmen wechselt seine primäre Domäne und möchte in einen sauberen Tenant migrieren, statt innerhalb des bestehenden umzubenennen.
• Trennung eines Partnerunternehmens: Eine Shared-Services-Vereinbarung endet, und jede Einheit benötigt eine eigene unabhängige Umgebung.

Wer lediglich von einem Drittanbieter-E-Mail-System (Google Workspace, Zimbra, IMAP) auf Microsoft 365 wechselt, steht vor einem anderen Prozess — einer initialen Tenant-Migration, nicht einer tenantübergreifenden. Der Migration Orchestrator ist ausschließlich für Microsoft-365-zu-Microsoft-365-Verschiebungen gedacht.

Was der Migration Orchestrator verschiebt — und was nicht

Die Scope-Grenze zu verstehen ist entscheidend, bevor man beginnt. Hier ist, was der Orchestrator übernimmt:

Das häufigste Missverständnis betrifft Teams-Kanäle. Wenn ein Mitarbeiter migriert wird, wandert der Teams-Chatverlauf mit dem Postfach mit. Die Teams-Kanäle — in denen die Projektgespräche und geteilten Dateien des Teams liegen — bleiben jedoch im Quell-Tenant. Migrierten Nutzern fehlt nach der Migration der Zugriff auf ihre alten Kanal-Inhalte, es sei denn, es wird ein Gastzugang eingerichtet oder ein Drittanbieter-Tool für die Kanalmigration eingesetzt.

Für viele Organisationen ist das akzeptabel. Für Unternehmen, in denen Teams-Kanäle das primäre Projektgedächtnis sind, erfordert das einen differenzierteren Migrationsplan.

Lizenzvoraussetzungen: Was vor dem Start nötig ist

Der Migration Orchestrator ist nicht für alle Nutzer kostenlos verfügbar. Die Lizenzanforderungen sind konkret:

• Quell- und Ziel-Tenant-Lizenzierung: Beide Tenants müssen Microsoft 365 E3, E5 oder entsprechende Enterprise-Lizenzen vorweisen. Business-Tier-Lizenzen (Business Basic, Business Standard, Business Premium) sind nicht zulässig. Das ist eine harte Grenze für kleinere Organisationen — liegt einer der Tenants auf Business-Plänen, muss er entweder hochgestuft oder vorübergehend mit Add-on-Lizenzen ausgestattet werden.
• Cross-Tenant User Data Migration Add-on: Jeder Nutzer, dessen Postfach oder OneDrive verschoben werden soll, benötigt eine Cross-Tenant-User-Data-Migration-Lizenz. Das ist ein benutzergebundenes Add-on, das über den Microsoft-Partner bezogen wird. Die Kosten liegen bei etwa 5–8 € pro Nutzer und Monat — und werden nur für die Dauer des Migrationsprojekts benötigt.
• Globaler Administrator oder Exchange-Administrator in beiden Tenants ist für die Einrichtung der tenantübergreifenden Beziehung erforderlich.

Der Migrationsprozess: Phase für Phase

Phase 1: Tenantübergreifende Beziehung einrichten

Bevor Daten bewegt werden, müssen Administratoren in beiden Tenants der Migrationsbeziehung zustimmen. Dazu gehört die Konfiguration eines Migrations-Endpunkts im Ziel-Tenant und die Autorisierung durch den Quell-Tenant. Der Prozess ist in PowerShell dokumentiert und dauert für einen erfahrenen Administrator 2–4 Stunden. Beide Tenants müssen zu diesem Zeitpunkt die passenden Lizenzen besitzen.

Phase 2: Identitätszuordnung und Vorab-Benutzererstellung

Jeder zu migrierende Nutzer muss bereits im Ziel-Tenant existieren, bevor seine Daten verschoben werden können. Das ist die arbeitsintensivste Phase. Für jeden Nutzer sind folgende Schritte nötig:

1. Benutzerkonto im Ziel-Entra-ID mit dem Ziel-Domänen-UPN anlegen
2. MailUser-Objekt konfigurieren, das während der Koexistenz auf das Quellpostfach zeigt
3. Ziel-Lizenz zuweisen
4. Die ExchangeGuid des Quellnutzers auf das MailUser-Objekt im Ziel-Tenant abbilden — das ist die Identitätsverknüpfung, die der Orchestrator verwendet

Ab 50 Nutzern aufwärts sollte dieser Schritt geskriptet werden. Manuell ist er bei größeren Mengen fehleranfällig und zeitraubend.

Phase 3: Batch-Migration

Sind die Identitäten angelegt, werden Migrations-Batches im Exchange Admin Center des Ziel-Tenants erstellt. Der Orchestrator synchronisiert Postfachinhalte inkrementell — erst läuft eine initiale Synchronisation, dann holen Delta-Syncs neue E-Mails nach, bis der endgültige Cutover ausgelöst wird. Für OneDrive gilt das gleiche inkrementelle Vorgehen.

Die Batch-Strategie ist wichtig. Eine Gesamtmigration in einem Ereignis reduziert die Koexistenz-Komplexität, schafft aber einen Single Point of Failure. Phasenweise Batches nach Abteilung oder Standort erlauben es, Probleme zu beheben, ohne alle zu beeinträchtigen.

Phase 4: Cutover und DNS-Update

Der Cutover für jeden Nutzer umfasst den Abschluss der letzten Delta-Synchronisation, die Umwandlung des MailUser in ein vollständiges Postfach im Ziel-Tenant sowie die Aktualisierung der DNS-MX-Records, damit neue E-Mails in den Ziel-Tenant geroutet werden. Nach dem Cutover wird das Quellpostfach in einen Weiterleitungs-Stub umgewandelt, der eingehende E-Mails an die neue Adresse weiterleitet.

DSGVO-Aspekte bei der tenantübergreifenden Migration

Eine Tenant-zu-Tenant-Migration verarbeitet personenbezogene Daten — Mitarbeiter-E-Mails, Kalender, Dokumente. Nach der DSGVO erfordert das eine Rechtsgrundlage und in den meisten M&A-Szenarien einen Auftragsverarbeitungsvertrag zwischen den beteiligten Einheiten, wenn eine im Auftrag der anderen handelt.

Konkret bedeutet das: Das Migrationsprojekt sollte eine rechtliche Prüfung der Datenverarbeitungsbeziehung, eine Dateninventur des zu verschiebenden Materials und die Dokumentation der Migration im DSGVO-Verarbeitungsverzeichnis umfassen. Microsoft verarbeitet die Daten in Ihrem Auftrag gemäß dem Data Processing Addendum — die Frage ist, ob die empfangende Einheit (Ziel-Tenant-Inhaber) eine geeignete Grundlage für den Datenempfang hat.

Bei Übernahmen ist das typischerweise durch den Übernahmevertrag gedeckt. Bei Ausgliederungen erfordert es eine explizite Regelung vor dem Migrationsstart. Wird diese auf nach der Migration verschoben, entsteht regulatorisches Risiko.