Warum Microsoft 365 Tenant-to-Tenant-Migrationen scheitern und wie Sie die häufigsten Risiken vermeiden

Tenant-zu-Tenant-Migrationen sind komplexe Prozesse, die Wochen oder sogar Monate in Anspruch nehmen können. Während des Wechsels müssen IT-Teams Tausende von Assets verschieben, Domänen über mehrere Systeme hinweg neu zuweisen und unzählige Benutzerberechtigungen verwalten.

Diese Komplexität ist der Grund dafür, dass wenn Migrationen ins Stocken geraten, selten ein einzelner technischer Fehler die Ursache ist. Vielmehr liegt das Problem häufig in der Identitätsfehlanpassung, in Abhängigkeitslücken und in einer unvollständigen Bestandsaufnahme. Jeder Workload – SharePoint, Exchange, Teams und OneDrive – ist auf Entra ID-Objekte angewiesen. Wenn diese nicht korrekt identifiziert, zugeordnet oder neu erstellt werden, bricht der Zugriff zusammen.

Dieser Leitfaden erläutert, wie Sie Microsoft 365-Tenants zu einem anderen Tenant migrieren. Wir zeigen auf, welche Fehler während des Wechsels zu erwarten sind und wie Sie diese vermeiden können.

Warum können Tenants nicht einfach zusammengeführt werden?

Jeder Microsoft 365-Tenant ist ein separates Entra ID-Verzeichnis mit eigenen Benutzerobjekten, Gruppen und Lizenzen. Da Entra ID (früher Azure AD) diese Grenzen definiert, ist eine einfache Zusammenführung zweier Tenants nicht möglich.

Anstatt eine einfache Übertragung durchzuführen, arbeiten Sie die Tools im gesamten M365-Ökosystem um. Sie müssen:

• OneDrive- und SharePoint-Assets sowie Berechtigungen ermitteln, neu zuordnen und neu erstellen.
• E-Mail-Benutzer im neuen Tenant einrichten, um Postfächer zu übertragen.
• Kanäle, Kanalinhalte und verbundene Dienste in Teams und M365 Groups übertragen.

Microsoft stellt einige native M365-Migrationsfunktionen bereit – hat den gesamten Tenant-zu-Tenant-Migrationsprozess jedoch in keiner wesentlichen Hinsicht vereinfacht. Die integrierten Tools sind verstreut und erfordern zwei Lizenz-Add-ons zur Verwaltung von Benutzer- und freigegebenen Daten. Teams-Migrationen stellen ebenfalls eine Herausforderung dar, da keine native Software für die Übertragung von Teams-Unterhaltungen vorgesehen ist. Stattdessen können Sie Teams-Inhalte in den neuen Tenant übertragen, jedoch ohne Beibehaltung der ursprünglichen Kanalstruktur. Für umfangreichere Workloads mit komplexen SharePoint-Sitestrukturen oder Teams-Umgebungen mit verbundenen Diensten werden Sie wahrscheinlich auf Drittanbieter-Migrationstools angewiesen sein.

Selbst mit der Unterstützung dieser Plattformen können Fehler auftreten. Daher ist die Erstellung eines Migrationsplans so wichtig – die Vorbereitung auf häufige Fehler bedeutet, dass IT-Teams wissen, was zu tun ist, wenn während des Wechsels ein Problem auftritt.

‍

Warum Microsoft 365-Tenant-zu-Tenant-Migrationen scheitern

Die meisten Probleme bei Tenant-zu-Tenant-Migrationen lassen sich auf dieselben Grundursachen zurückführen: eine zu oberflächliche Bestandsaufnahme, unzureichende Planung von Identitäten und Zugriffsrechten sowie Abhängigkeiten, die vor Beginn der Umsetzung nicht identifiziert wurden. Dabei handelt es sich nicht um unvorhersehbare technische Fehler – es sind wiederkehrende, erkennbare Muster, die projektübergreifend in verschiedenen Umgebungen und Tools auftreten. Mit dem richtigen Ansatz lassen sie sich jedoch vermeiden.

Eine unvollständige Bestandsaufnahme führt zu ungenauer Planung

Die Dimensionierung einer Migration ausschließlich anhand des Speichervolumens ist eine der zuverlässigsten Methoden, um mit einem Plan zu enden, der mitten im Projekt scheitert. Das Speichervolumen sagt Ihnen eines: wie viele Gigabyte (oder Terabyte) Daten vorhanden sind. Es sagt Ihnen nicht, wie viele Elemente verschoben werden müssen, wo diese Daten in den Microsoft 365-Workloads gespeichert sind oder welche Abhängigkeiten bestehen – Faktoren, die die Migrationskomplexität und den Durchsatz direkt beeinflussen.

So ist die Migration einer einzelnen 50-GB-Datei beispielsweise etwas ganz anderes als das Verschieben von 50 GB E-Mails, Anhängen und Listenelementen, die über Dutzende von Postfächern, SharePoint-Sites und Teams-Kanäle verteilt sind. Das Speichervolumen ist identisch, aber das zweite Szenario erfordert deutlich mehr API-Aufrufe, da die Anzahl der Elemente viel höher ist. Jeder Workload verwendet zudem unterschiedliche APIs und hat verschiedene Servicegrenzen (bei denen Drosselungen auftreten können), sodass derselbe Speicherbedarf sehr unterschiedliche Migrationszeiträume bedeuten kann. Dies hängt sowohl von der Anzahl der Elemente als auch von der Verteilung der Daten über die Workloads ab.

Dies gilt auch für miteinander verbundene Dienste. Teams und M365 Groups sind nicht nur Ordner, sondern ein Geflecht aus SharePoint-Sites, Gruppenpostfächern und Chatverläufen. Eine genaue Zuordnung hilft Ihnen, die Komplexität der Migration zu verstehen.

‍

Identitätsfehlanpassungen beeinträchtigen Zugriff und Eigentümerschaft

Jede Berechtigung in Microsoft 365 – Dateizugriff, Site- und Team-Mitgliedschaft, Postfachverwaltung – ist an ein Identitätsobjekt in Entra ID gebunden: Benutzerkonten (einschließlich Gastkonten), Gruppen (einschließlich Sicherheitsgruppen und Microsoft 365-Gruppen), Geräte (registrierte oder verknüpfte Geräte, die Entra ID für den Zugriff verwenden) und Anwendungen (App-Objekte und Dienstprinzipale). Bei einer Tenant-zu-Tenant-Migration werden diese Objekte nicht zusammen mit Ihren Daten verschoben. Sie müssen im Ziel-Tenant als neue Objekte mit neuen Objekt-IDs neu erstellt werden – und ohne eine explizite Zuordnung zwischen Quell- und Zielidentitäten können die Berechtigungen, die auf diese Objekte im Quell-Tenant verwiesen haben, im Ziel-Tenant nicht erneut angewendet werden.

Wenn die Identitätszuordnung nicht ordnungsgemäß dokumentiert und wiederhergestellt wird, können nach dem Wechsel folgende Zugriffsfehler auftreten:

• Benutzer sind vom migrierten Inhalt ausgesperrt: Wenn vorhandene Berechtigungen im Ziel-Tenant nicht korrekt zugeordnet werden, können Benutzer in ihrer neuen Microsoft 365-Umgebung nicht auf Inhalte zugreifen, selbst wenn die Inhalte selbst erfolgreich migriert wurden.
• Nicht aufgelöste Gruppenmitgliedschaften: SharePoint-Berechtigungen und Teams-Mitgliedschaften sind von Microsoft 365-Gruppen- und Sicherheitsgruppen-Objekten abhängig. Identitätslücken oder -fehlanpassungen führen dazu, dass Benutzer von Ressourcen ausgeschlossen werden, auf die sie Zugriff haben sollten – oder Zugriff auf Ressourcen erhalten, auf die sie keinen Zugriff haben sollten.
• Verlust des Gastzugriffs: Gastkonten sind Entra ID-Objekte, die spezifisch für den Quell-Tenant sind. Sie existieren im Ziel-Tenant erst, wenn sie dort explizit als neue Objekte mit neuen Objekt-IDs bereitgestellt werden – das bedeutet, dass jeder Gastzugriff, der im Ziel nicht berücksichtigt und neu eingerichtet wird, nach der Migration verloren geht.
• Lücken in Richtlinien für bedingten Zugriff: Da Richtlinien für bedingten Zugriff eng mit Entra ID-Benutzerobjekten, -IDs und -Anwendungen verknüpft sind, können sie nicht nativ als Teil einer Inhaltsmigration „verschoben" werden, sondern müssen in der neuen Umgebung neu erstellt und zugeordnet werden. Wenn sie nicht vor dem Wechsel vorhanden sind, können Benutzer mit unerwarteten Authentifizierungsfehlern konfrontiert werden oder vollständig ausgesperrt sein.

Nicht erkannte Abhängigkeiten gefährden Zeitpläne

Während einer Domänenumstellung werden folgende Abhängigkeiten häufig übersehen:

• SharePoint-Vererbung: Berechtigungen, die auf Bibliotheks-, Ordner- oder Elementebene von übergeordneten Elementen getrennt werden, erfordern, dass individuelle Berechtigungszuweisungen gelesen, zugeordnet und im Ziel-Tenant erneut angewendet werden. Der Umfang dieser Arbeit ist oft erst sichtbar, wenn die Migration bereits läuft.
• Verbundene Dienste: Teams-Apps von Drittanbietern, eingebettete Power BI-Berichte und benutzerdefinierte Power Automate-Flows haben alle tenant-spezifische Abhängigkeiten, die unterbrochen werden, wenn Inhalte in einen neuen Tenant verschoben werden.
• Verwaltete Metadaten: Ausdrucksspeicher und verwaltete Metadatenspalten sind tenant-spezifisch – Inhalte, die auf ihnen basieren, können im Ziel-Tenant mit leeren oder nicht zugeordneten Feldern ankommen.

‍

12 Best Practices für die M365-Tenant-zu-Tenant-Migration

Diese Best Practices sind entscheidend für einen erfolgreichen Wechsel. Wir haben jede in eine dreiphasige Struktur unterteilt: vor der Migration, während der Migration und nach der Migration.

Vor einer Tenant-zu-Tenant-Migration

Wenn Sie einen Zeitplan festlegen, bevor der Umfang der Migration definiert ist, werden Sie in Rückstand geraten. Teams stehen dann unter Druck, alles auf einmal zu übertragen, was Migrationen teurer und komplizierter macht, als nötig wäre. Investieren Sie stattdessen Zeit in die Vorab-Definition des Umfangs, indem Sie folgende Schritte durchführen.

1. Erstellen Sie eine vollständige, nach Workload gegliederte Bestandsaufnahme

Prüfen Sie Elementanzahlen und Abhängigkeiten in Exchange (einschließlich Archive), SharePoint, OneDrive und Teams. Jeder Workload hat spezifische API-Einschränkungen und ein eigenes Speichervolumen, die beide potenzielle Drosselungen beeinflussen und sich auf Ihren Zeitplan auswirken können.

2. Bereinigen Sie Daten vor der Migration

Legen Sie fest, was migriert werden soll, indem Sie entscheiden:

• Was unverändert migriert wird
• Was vor der Migration behoben werden muss (fehlerhafte Berechtigungen, nicht unterstützte Dateinamen, Probleme mit der Pfadlänge, Sites/Teams/Gruppen ohne Besitzer, die in den Ziel-Tenant übertragen werden müssen)
• Was archiviert wird (aufbewahrt, aber nicht in den neuen Tenant verschoben)
• Was vollständig außer Betrieb genommen wird

3. Dokumentieren und ordnen Sie Identitätsobjekte zu

Führen Sie eine Lückenanalyse durch, indem Sie eine Bestandsaufnahme aller betroffenen Identitätsobjekte erstellen, eine explizite Quell-zu-Ziel-Zuordnung anlegen und nach Lücken suchen, bei denen Zielobjekte noch nicht vorhanden sind. Stellen Sie auf Basis dieser Informationen Identitätsobjekte im neuen Tenant bereit und erstellen Sie sie neu, bevor die Migration beginnt.

4. Benutzer vorab anlegen und Lizenzen aktivieren

Bevor Sie die Migration auslösen, registrieren Sie eine Lizenz für den neuen Tenant und erstellen Sie Benutzerprofile im Ziel-Tenant.

5. Wählen Sie Ihren Migrationsansatz und die geeigneten Tools

Entscheiden Sie, ob eine risikoreichere Einzel-Migration oder eine risikoärmere Batch-Migration besser zu Ihren Anforderungen passt. Die Entscheidung hängt von der Datenmenge ab, die Sie verschieben müssen. Kleinere Organisationen sind mit einer Einzel-Migration möglicherweise besser bedient, da sie weniger Dateien, Berechtigungen und Benutzer verwalten müssen. Größere Unternehmen bevorzugen möglicherweise ein langsameres Vorgehen, um Fehler und Datenverluste zu minimieren.

Wählen Sie nach der Entscheidung für einen Ansatz das geeignete Migrationstool aus. Microsoft bietet einige native Optionen, die jedoch nicht alle Anf