Microsoft 365 Migration Orchestrator: Tenant-zu-Tenant-Migration erklärt

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.

Wenn Sie den gesamten Umzug lieber abgeben möchten, übernimmt unsere Microsoft 365 Migration für KMU Tenant-zu-Tenant-Projekte mit festem Umfang und Termin, einschließlich der unten beschriebenen Lizenzanalyse und Identitätszuordnung.

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: Das Add-on ist für Microsoft 365 Business Basic, Standard und Premium verfügbar sowie für Microsoft 365 F1/F3/E3/E5, Office 365 F3/E1/E3/E5, Exchange Online, SharePoint und OneDrive. Business-Tier-Lizenzen sind damit zulässig, kleinere Organisationen müssen also nicht vorab auf einen Enterprise-Plan wechseln. Jeder Nutzer benötigt zusätzlich in beiden Tenants eine Teams-Lizenz und einen Exchange-Online-Plan.
• 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. Abgerechnet wird eine einmalige Gebühr pro Nutzer statt eines monatlichen Abonnements; die Lizenz kann wahlweise dem Quell- oder dem Ziel-Benutzerobjekt zugewiesen werden.
• Globaler Administrator in beiden Tenants ist für die Einrichtung der tenantübergreifenden Beziehung erforderlich. Die Migrationsbefehle selbst laufen im Ziel-Tenant und können alternativ von einem Microsoft 365 Migration Administrator ausgeführt werden.

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 vom Ziel-Tenant aus über Microsoft Graph erstellt, maximal 100 Nutzer pro Batch. Der Orchestrator synchronisiert Postfachinhalte inkrementell: erst läuft eine initiale Synchronisation, dann holen Delta-Syncs neue E-Mails nach, bis das gesetzte CompleteAfterDate den Cutover auslöst. Für OneDrive gilt das nicht: OneDrive-Inhalte bewegen sich erst beim Cutover, inkrementelle oder Delta-Durchläufe sind nicht möglich.

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.