Microsoft 365 Tenant-zu-Tenant-Migration planen

Microsoft 365 · Mandantenmigration

Ein Wechsel des IT-Dienstleisters erfordert normalerweise keinen neuen Microsoft-365-Tenant. Eine mandantenübergreifende Migration wird erst nötig, wenn Benutzer, Domains oder Daten eine Organisationsgrenze verlassen sollen – etwa bei einer Unternehmensabspaltung, der Zusammenführung mehrerer Mandanten oder einer Umgebung, die dem eigenen Unternehmen nicht eindeutig zugeordnet ist. Dann müssen Identitäten, Postfächer, OneDrive, SharePoint, Teams-Abhängigkeiten und die Geschäftsdomain in einer festgelegten Reihenfolge umziehen.

Die Kurzantwort: Erst die Organisationsgrenze klären, dann über eine Migration entscheiden

Ein Tenant ist die technische und administrative Grenze einer Microsoft-365-Organisation. Innerhalb dieses Mandanten liegen Benutzeridentitäten, Lizenzen, Domains, Postfächer, Dateien, Gruppen, Richtlinien und Protokolle. Solange diese Grenze zum Unternehmen passt, werden Administratoren oder Lizenzpartner gewechselt, ohne sämtliche Daten in einen neuen Tenant zu verschieben.

Wann ein Tenantwechsel typischerweise erforderlich ist
Ausgangslage	Tenantwechsel?	Begründung
Neuer IT-Dienstleister	In der Regel nein	Administratorrollen, Partnerbeziehungen und Dokumentation können im bestehenden Unternehmenstenant geändert werden.
Anderer Lizenzanbieter	In der Regel nein	Abonnements und Bezugsweg lassen sich häufig wechseln, ohne Identitäten oder Daten zu migrieren.
Neue Firmenbezeichnung oder zusätzliche Domain	Meist nein	Eine neue verifizierte Domain kann einem bestehenden Tenant hinzugefügt werden.
Unternehmensbereich wird rechtlich ausgegliedert	Häufig ja	Benutzer und Daten müssen in eine eigenständig kontrollierte Organisation überführt werden.
Mehrere Microsoft-365-Mandanten sollen vereinheitlicht werden	Häufig ja	Identitäten, Zusammenarbeit und Administration sollen in einer Organisationsgrenze zusammengeführt werden.
Konten liegen im Sammeltenant eines Dienstleisters	Regelmäßig zu prüfen	Das Unternehmen benötigt einen eigenen Mandanten mit eigener Vertrags-, Domain- und Administrationskontrolle.

Die Entscheidung darf nicht allein aus einem unangenehmen Tenantnamen oder einer historischen Einrichtung abgeleitet werden. Die interne onmicrosoft.com-Domain ist zwar dauerhaft an den Mandanten gebunden, im normalen E-Mail-Verkehr kann jedoch die eigene Geschäftsdomain verwendet werden. Ein unschöner technischer Name rechtfertigt den Aufwand und das Risiko einer vollständigen Migration selten.

Entscheidungsnachweise vor jedem Migrationsprojekt

Quelle und Ziel sind rechtlich, vertraglich und administrativ den richtigen Unternehmen zugeordnet.
Der gewünschte Zustand lässt sich nachweislich nicht durch Rollen-, Domain- oder Partneränderungen im bestehenden Tenant erreichen.
Für jeden Microsoft-365-Dienst ist geklärt, ob er verschoben, neu aufgebaut, archiviert oder beendet wird.
Lizenz-, Werkzeug- und Betriebsaufwand stehen in einem vertretbaren Verhältnis zum Nutzen des neuen Mandanten.

1. Ein neuer Anbieter, eine neue Domain oder neue Lizenzen bedeuten noch keinen neuen Tenant

Die kostengünstigste und technisch sauberste Lösung besteht häufig darin, den vorhandenen Mandanten zu übernehmen und zu ordnen. Dafür muss er dem Unternehmen gehören und von ihm kontrollierbar sein.

Beim Dienstleisterwechsel werden Zugänge und Zuständigkeiten übergeben

Ein bisheriger Dienstleister kann administrative Rollen, eine Partnerbeziehung oder delegierte Verwaltungsrechte besitzen. Diese Berechtigungen werden dokumentiert, an persönliche Administratorkonten des Unternehmens beziehungsweise des neuen Beauftragten übergeben und anschließend entzogen. Postfächer, SharePoint-Websites und Teams müssen dafür nicht umziehen.

Zur Übergabe gehören globale und dienstspezifische Administratoren, Notfallzugänge, Domainregistrar, DNS, Abonnements, Rechnungsstellung, Supportkontakte, Anwendungsregistrierungen und Wiederherstellungswege. Fehlt die Kontrolle über einzelne Bereiche, wird zuerst deren Eigentum geklärt. Eine vorschnelle Neuanlage eines zweiten Tenants verdoppelt sonst nur das Problem.

Eine Geschäftsdomain kann im bestehenden Mandanten ergänzt werden

Bei Umfirmierung, neuer Marke oder zusätzlicher E-Mail-Domain lässt sich die Domain im vorhandenen Tenant verifizieren. Benutzer können neue primäre Adressen erhalten, während bisherige Adressen als Alias bestehen bleiben. Anwendungen, Websiteversand, SPF, DKIM und DMARC werden entsprechend angepasst.

Ein Tenantwechsel wird erst dann relevant, wenn die Domain einer anderen Microsoft-365-Organisation zugeordnet werden soll. Eine benutzerdefinierte Domain kann nicht gleichzeitig in zwei Tenants als verifizierte Domain geführt werden. Ihr Transfer wird deshalb zu einem eigenen Arbeitspaket mit Übergangsadressen, Bereinigung aller Abhängigkeiten und einem klaren Umschaltzeitpunkt.

Ein falscher organisatorischer Eigentümer ist ein belastbarer Migrationsgrund

Kritisch wird eine Umgebung, wenn mehrere rechtlich unabhängige Kunden in demselben Tenant geführt werden oder nur der Dienstleister die Vertrags- und Administrationskontrolle besitzt. Der Tenant bildet dann keine saubere Unternehmensgrenze. Datenschutz, Lizenzierung, Protokollzugriff, Richtlinien und eine spätere Übergabe lassen sich nicht zuverlässig dem einzelnen Kunden zuordnen.

Vor der Migration muss trotzdem geklärt werden, welche Konten, Domains und Daten tatsächlich zum Unternehmen gehören. Eine technisch erreichbare Datei oder ein sichtbares Postfach ist noch kein Eigentumsnachweis. Verträge, Weisungsbefugnisse und gegebenenfalls Aufbewahrungspflichten bestimmen den zulässigen Umfang.

2. Die Bestandsaufnahme erfasst Dienste, Identitäten und Abhängigkeiten gemeinsam

Ein Benutzer besitzt nicht nur ein Postfach. Derselbe Identitätseintrag kann OneDrive-Dateien, Teams-Mitgliedschaften, SharePoint-Berechtigungen, Anwendungszugriffe, Gerätezuordnungen und Aufbewahrungsanforderungen verbinden.

Benutzer und Gruppen erhalten eine eindeutige Quell-Ziel-Zuordnung

Für jede Person werden Quellobjekt, Zielobjekt, heutiger Benutzername, künftiger Benutzername, primäre E-Mail-Adresse, Aliasse, Lizenz, Postfach, Archiv, OneDrive und benötigte Gruppen festgehalten. Gäste, Funktionskonten, freigegebene Postfächer, Räume und technische Identitäten bleiben eigene Objektarten.

Die Zuordnung darf nicht nur auf identischen Anzeigenamen beruhen. Objekt-IDs, primäre Adressen und die für das Migrationsverfahren erforderlichen Exchange- beziehungsweise SharePoint-Attribute werden geprüft. Eine falsche Identitätszuordnung kann Inhalte oder Berechtigungen der falschen Person zuweisen und ist deshalb ein Abbruchgrund.

Jeder Dienst erhält eine eigene Migrationsentscheidung

Exchange, OneDrive, SharePoint, Teams, Planner, Power Platform, Intune, Enterprise-Anwendungen und Sicherheitsrichtlinien besitzen verschiedene Datenmodelle und Werkzeuge. Eine erfolgreiche Postfachmigration sagt nichts über Teams-Kanäle, SharePoint-Workflows oder Gerätekonfigurationen aus.

Die Inventarliste nennt pro Dienst Datenmenge, Objektzahl, Eigentümer, Berechtigungen, externe Abhängigkeiten, unterstütztes Verfahren, bekannte Ausschlüsse und Abnahmetest. Nicht benötigte Altstrukturen können bewusst zurückbleiben. Ein Werkzeuglimit darf dagegen nicht als stillschweigende fachliche Entscheidung behandelt werden.

Aufbewahrung und Sperren werden vor dem Termin geprüft

Postfächer mit einem Hold werden durch Microsofts native Cross-Tenant-Mailboxmigration blockiert. Auch OneDrive- oder SharePoint-Bestände können durch Aufbewahrung, Customer Key oder andere Schutzfunktionen besondere Voraussetzungen erhalten. Solche Konfigurationen werden nicht am Umschalttag überrascht entfernt.

Eine erforderliche Änderung an einer Aufbewahrungs- oder Verschlüsselungskonfiguration wird rechtlich und technisch bewertet, dokumentiert und im Ziel wiederhergestellt. Wenn eine Vorgabe die Migration ausschließt, muss das Projektverfahren angepasst werden. Die technische Bequemlichkeit entscheidet nicht über die zulässige Aufbewahrung geschäftlicher Daten.

Mindestbestand für eine belastbare Aufwandsschätzung

Alle aktiven, inaktiven und ausgeschiedenen Benutzer einschließlich Postfach- und Archivgrößen
Freigegebene Postfächer, Verteiler, Microsoft-365-Gruppen, Teams, Räume und Gäste
OneDrive-Konten, SharePoint-Websites, Objektzahlen, Versionen, Pfadlängen und Speichergrößen
Geschäftsdomains, Aliasse, DNS-Verwaltung und sämtliche legitimen E-Mail-Absender
Aufbewahrungsrichtlinien, Holds, Sensitivity Labels, DLP und Verschlüsselungsfunktionen
Enterprise-Anwendungen, OAuth-Zustimmungen, Automationen, Power Apps und Schnittstellen
Verwaltete Geräte, Richtlinien, Zertifikate und Benutzerprofile
Mindestens fünf vollständige Arbeitsabläufe für Pilot und Abnahme

3. Zielidentitäten und Domaintransfer bestimmen die Reihenfolge

Benutzer werden im Ziel vorbereitet, ohne die zu migrierenden Dienste versehentlich bereits anzulegen. Anschließend verknüpft ein Identitätsmapping jedes Quellobjekt mit genau einem Zielobjekt.

Vorbereitete Zielkonten dürfen die späteren Zielobjekte nicht blockieren

Für native Microsoft-Verfahren werden Zielbenutzer und Gruppen vorab angelegt. Ein Exchange-Zielobjekt benötigt die aus der Quelle übernommenen Identitätsattribute und wird zunächst als MailUser vorbereitet. Bei OneDrive darf im Ziel noch keine OneDrive-Website für die betreffende Person existieren; ein vorhandener Bestand kann nicht einfach überschrieben oder mit der Quelle zusammengeführt werden.

Microsoft verlangt beim aktuellen mandantenübergreifenden Identitätsmapping, dass die Zuordnung vor der Vergabe von Workload-Lizenzen erfolgt, damit nicht vorzeitig Postfächer oder OneDrive-Websites entstehen. Die genaue Reihenfolge wird für das ausgewählte Verfahren dokumentiert und mit einem Testbenutzer erprobt.

Die Geschäftsdomain wechselt in einem kontrollierten Engpass

Vor der Entfernung aus dem Quelltenant darf die Domain nicht mehr in Benutzeranmeldenamen, E-Mail-Adressen, Gruppen, Teams oder anderen abhängigen Objekten verwendet werden. Diese Objekte erhalten vorübergehend Adressen einer tenantgebundenen Domain oder einer vorbereiteten Übergangsdomain. Erst danach kann die Geschäftsdomain entfernt, im Ziel verifiziert und dort wieder zugewiesen werden.

Der Ablauf erzeugt einen Zeitraum, in dem sich Benutzername, primäre E-Mail-Adresse und Mailrouting verändern können. DNS-TTL, MX, Autodiscover, SPF, DKIM und DMARC werden mit exakten Ausgangs- und Zielwerten vorbereitet. Der Plan nennt außerdem, welche Systeme E-Mail im Namen der Domain versenden und wann sie umgestellt werden.

Koexistenz wird für E-Mail, Kalender und Zusammenarbeit getrennt geplant

Bei gestaffelten Umzügen existieren Benutzer zeitweise in beiden Tenants. Für E-Mail werden Routingziele und Quell-MailUser so vorbereitet, dass Nachrichten den bereits migrierten Empfänger erreichen. Transportregeln, Spamfilter und Compliance-Funktionen können dabei in beiden Organisationen wirken.

Kalenderverfügbarkeit und tenantübergreifende Zusammenarbeit benötigen eigene Einstellungen. Teams-Föderation oder Cross-Tenant-Access kann Kommunikation ermöglichen, ersetzt aber keine Datenmigration. Ein funktionierender Chat zwischen beiden Organisationen sagt nichts über Kalender, Besprechungsobjekte oder Zugriffe auf alte Teamdateien aus.

4. Jeder Microsoft-365-Dienst bewegt andere Inhalte und hinterlässt andere Grenzen

Microsoft stellt inzwischen native Werkzeuge für mandantenübergreifende Postfach-, OneDrive- und SharePoint-Migrationen sowie einen Orchestrator für mehrere Benutzerworkloads bereit. Verfügbarkeit, Lizenzierung und Funktionsumfang werden vor Projektbeginn im betreffenden Tenant geprüft.

Exchange verschiebt Benutzerinhalte, aber keine vollständige Organisationskonfiguration

Die native Cross-Tenant-Mailboxmigration bewegt sichtbare Postfachinhalte wie E-Mails, Kontakte, Kalender, Aufgaben und Notizen sowie bestimmte wiederherstellbare Elemente. Nach einem erfolgreichen Move wird das Quellpostfach entfernt und im Quelltenant als MailUser für das Routing weitergeführt. Diese Wirkung unterscheidet sich von einer einfachen Kopie und verlangt einen geprüften Zielzustand.

Microsoft-365-Gruppen werden durch dieses Postfachverfahren nicht migriert. „Senden im Auftrag von“ muss nach Microsofts Dokumentation im Ziel erneut gesetzt werden. Im Postfach gespeicherte Vollzugriffsrechte können mitwandern, wenn beteiligte Benutzer passend gemeinsam migriert und zugeordnet sind. Signaturen und manche Organisationsfunktionen müssen neu eingerichtet werden.

OneDrive ist ein einmaliger Move ohne inkrementelle Nachläufe

Microsofts native OneDrive-Migration verschiebt das Konto in einem einmaligen Vorgang. Delta- oder inkrementelle Durchläufe sind bei diesem Verfahren nicht möglich. Während eines kurzen Teils des Moves ist das Quell-OneDrive schreibgeschützt; anschließend verweist die alte Position über eine Weiterleitung auf das Ziel, solange die Quelle und der Redirect bestehen.

Das Ziel-OneDrive darf vor oder während der Migration nicht erstellt sein. Microsoft nennt außerdem Grenzen von fünf Terabyte beziehungsweise einer Million Elemente pro Konto sowie 400 Zeichen für vollständige Pfade. Versionen zählen bei der Elementgrenze mit. Große oder tief strukturierte Konten werden deshalb vorab geprüft und gegebenenfalls bereinigt.

SharePoint kann Websites verschieben, aber keine vorhandenen Ziele zusammenführen

Moderne, klassische, Kommunikations- und gruppenverbundene SharePoint-Websites können mit Microsofts Cross-Tenant-Verfahren in den Zieltenant verschoben werden. Zielwebsite, Gruppen und Identitäten werden nach den Verfahrensregeln vorbereitet. Eine bereits mit Inhalten vorhandene Zielwebsite lässt sich nicht einfach mit der Quelle verschmelzen.

Links zu migrierten Dateien können über Weiterleitungen weiter funktionieren. Webparts mit Verweisen auf andere Websites, E-Mail oder Kalender benötigen dennoch eine Prüfung. Workflows, Apps, Power Apps und Automationen gehören nicht automatisch zum vollständigen Site-Move und müssen je nach Funktion neu veröffentlicht oder angepasst werden.

Teams-Inhalte werden nach Chat, Besprechung, Gruppe und SharePoint getrennt bewertet

Eine Teams-verbundene SharePoint-Website enthält die Kanaldateien, ist aber nicht das gesamte Team. Microsoft weist beim Cross-Tenant-Site-Move ausdrücklich darauf hin, dass Teams-Inhalte, Kanäle und die zugehörige Struktur dadurch nicht mitmigriert werden. Der aktuelle Migration Orchestrator kann benutzerbezogene Teams-Chats und Besprechungen als eigene Workloads koordinieren; dafür gelten zusätzliche Identitäts-, App- und Lizenzvoraussetzungen.

Teams, Microsoft-365-Gruppen, Planner-Pläne, Apps, Bots, Registerkarten und Verknüpfungen werden deshalb einzeln inventarisiert. Ein Zielteam kann neu angelegt, eine SharePoint-Website verschoben und ein Benutzerchat separat behandelt werden. Die Abnahme prüft jede dieser Ebenen und verwendet nicht den sichtbaren Teamnamen als Beleg für Vollständigkeit.

Werkzeugauswahl nach Ziel und Grenze

Cross-Tenant-Mailboxmigration für unterstützte Exchange-Online-Postfächer
Cross-Tenant-OneDrive-Migration für persönliche Dateibestände ohne vorhandenes Ziel-OneDrive
Cross-Tenant-SharePoint-Migration für geeignete Websites und gruppenverbundene Sites
Migration Orchestrator für koordinierte Benutzerworkloads einschließlich Exchange, OneDrive/SharePoint sowie unterstützten Teams- und Besprechungsdaten
Gesonderte Neuimplementierung für nicht unterstützte Gruppenstrukturen, Apps, Workflows, Geräteverwaltung und Automationen
Partnerwerkzeug nur nach dokumentiertem Funktionsvergleich, Datenschutzprüfung und Testmigration

5. Pilot und Umschaltplan verbinden technische Moves mit dem Arbeitsbeginn im Ziel

Ein erfolgreicher Synchronisationsstatus reicht nicht. Der Pilot muss zeigen, dass ein Benutzer sich im Ziel anmeldet, seine Arbeit fortsetzt und mit bereits sowie noch nicht migrierten Personen zuverlässig zusammenarbeitet.

Der Pilot umfasst zusammenhängende Benutzer und Berechtigungen

Ein einzelner isolierter Testbenutzer bildet Delegationen und Zusammenarbeit nicht ab. Ein geeigneter Pilot umfasst beispielsweise Führungskraft und Assistenz, Besitzer und Mitglied eines Teams, einen Benutzer mit großer OneDrive-Ablage, eine externe Freigabe und ein freigegebenes Postfach. Verbundene Rechte werden möglichst im selben Migrationslos behandelt.

Der Pilot verwendet keine künstlich leeren Konten. Er enthält repräsentative Mailboxordner, Kalender, Dateien, Versionen, Freigaben und Arbeitsabläufe. Personenbezogene oder vertrauliche Daten werden nur im erforderlichen Umfang genutzt; Prüfergebnisse beschreiben Befund und Objekt, ohne unnötige Inhalte in Protokolle zu kopieren.

Der Umschalttag besitzt messbare Freigabe- und Rückfallkriterien

Vor Beginn stehen erlaubte Restfehler, maximal tolerierbare Unterbrechung, Entscheidungsträger und spätester Rückfallzeitpunkt fest. Ein Rückfall ist nur möglich, solange das jeweilige Verfahren und der Datenstand dies zulassen. Bei einem vollzogenen OneDrive-Move oder erfolgreich verschobenen Quellpostfach ist „einfach zurückschalten“ keine belastbare Annahme.

Die Reihenfolge verbindet Identitätsmapping, Lizenzierung, Mailboxsynchronisation, Domaintransfer, Mailrouting, OneDrive- und SharePoint-Fenster, Teams-Abhängigkeiten und Clientanmeldung. Jede Änderung besitzt einen Verantwortlichen, einen Nachweis und eine Kommunikationszeit. Parallele Schritte werden nur dort ausgeführt, wo keine unkontrollierte Abhängigkeit besteht.

Arbeitsplätze und Mobilgeräte benötigen ein neues Identitätsprofil

Nach dem Tenantwechsel kann dieselbe sichtbare E-Mail-Adresse zu einer anderen Microsoft-Entra-Identität gehören. Outlook-, Teams-, OneDrive- und Office-Anmeldungen müssen auf das Zielkonto wechseln. Gespeicherte Token, Browserprofile, Windows-Arbeitskonten und mobile Apps können sonst weiterhin die Quellorganisation verwenden.

Geräteverwaltung und Sicherheitsrichtlinien werden separat geplant. Ein Gerät lässt sich nicht allein durch den Postfachmove vollständig in Intune oder eine neue Entra-Registrierung überführen. Zertifikate, Compliance, BitLocker-Schlüssel, App-Schutz und lokale Benutzerprofile werden nach dem gewählten Gerätekonzept behandelt.

Kontrollpunkte des Umschalttags

Identitätsmapping, Zielobjekte, Lizenzen und Migrationsberechtigungen bestätigen.
Synchronisations- und Kompatibilitätsstatus aller geplanten Workloads prüfen.
Bearbeitungsfenster für OneDrive, SharePoint und abhängige Anwendungen ausrufen.
Postfächer beziehungsweise Benutzerworkloads nach freigegebenem Los abschließen.
Geschäftsdomain aus dem Quelltenant lösen und im Ziel verifizieren.
DNS, Mailrouting und legitime Absender auf die Zielorganisation umstellen.
Benutzeranmeldung, Clients, Kalender, Dateien, Teams und Fachanwendungen testen.
Ergebnis kommunizieren und offene Fehler einem verantwortlichen Nachlauf zuweisen.

6. Die Abnahme prüft Daten, Rechte, Kommunikation und spätere Kontrolle

Eine Tenantmigration ist abgeschlossen, wenn die vereinbarten Geschäftsabläufe im Ziel funktionieren, die Unternehmensleitung den verbleibenden Umfang kennt und nicht mehr benötigte Quellzugriffe kontrolliert beendet werden können.

Positiv- und Negativtests belegen die neue Berechtigungsstruktur

Ein berechtigter Benutzer öffnet und bearbeitet repräsentative Dateien, Kalender und Postfächer. Zusätzlich wird mit einem unberechtigten Konto geprüft, dass vertrauliche Bereiche tatsächlich gesperrt sind. Externe Gäste erhalten nur die vorgesehenen Freigaben; alte Links werden auf Weiterleitung und Zielberechtigung getestet.

Bei delegierten Postfächern werden Vollzugriff, „Senden als“ und „Senden im Auftrag von“ getrennt geprüft. Bei SharePoint zählen Websitezugriff, Bibliotheksrechte, Einzeldateifreigaben und Gruppenmitgliedschaft. Eine erfolgreiche Administratoransicht ersetzt keinen Test mit dem normalen Benutzerkonto.

Protokolle und Stichproben unterscheiden Restfehler von Datenverlust

Migrationsberichte werden auf fehlgeschlagene, übersprungene und nicht unterstützte Objekte ausgewertet. Postfachordner, ältere E-Mails, Kalenderzeiträume, OneDrive-Dateien, Versionen und SharePoint-Bibliotheken werden anhand vereinbarter Stichproben verglichen. Zählabweichungen erhalten eine Erklärung und gegebenenfalls Nacharbeit.

Ein nicht funktionierender Link kann auf fehlende Berechtigung, eine noch nicht aktive Weiterleitung oder einen tatsächlich fehlenden Inhalt hinweisen. Diese Befunde werden getrennt diagnostiziert. Nur so lässt sich entscheiden, ob eine Korrektur, erneute Migration oder Benutzerinformation erforderlich ist.

Der Quelltenant bleibt bis zur dokumentierten Ablösung kontrolliert

Weiterleitungen, alte Freigabelinks, Compliance-Suchen und nicht migrierte Dienste können vorübergehend vom Quelltenant abhängen. Seine Lizenzen, Rollen und Aufbewahrungsfunktionen werden deshalb nicht pauschal beendet. Für jeden verbleibenden Zweck existieren Verantwortlicher und Endtermin.

Zum Projektabschluss werden Migrationsanwendungen und temporäre Vertrauensbeziehungen entfernt, soweit sie nicht mehr benötigt werden. Die Unternehmensdokumentation enthält Tenant-ID, Domains, Administrationskonten, Abonnements, Wiederherstellungswege, verbleibende Quellsysteme und offene Maßnahmen.

Abschlussnachweise für die Unternehmensleitung

Migrierte, neu aufgebaute, archivierte und bewusst ausgeschlossene Dienste
Ergebnisse der Migrationsberichte, Datenstichproben und Arbeitsablauftests
Nachgewiesene Zugriffe und Zugriffssperren für interne sowie externe Benutzer
Geschäftsdomains, DNS, E-Mail-Absender und neue primäre Adressen
Verbleibende Quellabhängigkeiten mit Verantwortlichen und Endterminen
Neue Administratoren, Partnerbeziehungen, Lizenzen und Supportwege
Entfernte temporäre Anwendungen, Berechtigungen und Vertrauensbeziehungen
Freigabe des Zielbetriebs und dokumentierte offene Nacharbeiten

Häufige Fragen zur Microsoft-365-Tenantmigration

Braucht ein Unternehmen beim Wechsel des IT-Dienstleisters einen neuen Tenant?

Üblicherweise nicht. Wenn der bestehende Tenant dem Unternehmen zugeordnet ist, werden administrative Rollen, Partnerbeziehungen, Dokumentation und gegebenenfalls Lizenzbezug geändert. Eine Datenmigration ist nur erforderlich, wenn tatsächlich eine Organisationsgrenze gewechselt werden muss.

Kann dieselbe Geschäftsdomain gleichzeitig in beiden Tenants liegen?

Nein. Eine benutzerdefinierte Domain kann nur in einem Microsoft-365-Tenant verifiziert sein. Vor dem Transfer müssen ihre Verwendungen im Quelltenant entfernt oder vorübergehend ersetzt werden. Danach wird sie im Ziel verifiziert und den dortigen Objekten zugewiesen.

Werden bei einem Postfachmove auch Teams und Microsoft-365-Gruppen migriert?

Nein. Die Cross-Tenant-Mailboxmigration behandelt Exchange-Postfachinhalte. Microsoft-365-Gruppen und Teams-Strukturen benötigen eigene Verfahren. Der aktuelle Migration Orchestrator kann bestimmte benutzerbezogene Teams- und Besprechungsdaten koordinieren, ersetzt aber keine vollständige Prüfung aller Teams-Komponenten.

Kann ein vorhandenes OneDrive im Ziel mit dem Quell-OneDrive zusammengeführt werden?

Nicht mit Microsofts nativem Cross-Tenant-OneDrive-Move. Das Ziel-OneDrive darf vor beziehungsweise während dieses Verfahrens nicht bestehen; eine Zusammenführung wird nicht unterstützt. Zielkonten und Lizenzreihenfolge müssen deshalb sorgfältig vorbereitet werden.

Bleiben alte Links zu OneDrive- und SharePoint-Dateien gültig?

Microsofts native Moves können an der alten Position eine Weiterleitung zum Ziel anlegen. Der Zugriff funktioniert trotzdem nur, wenn die betreffende Person im Ziel korrekt zugeordnet und berechtigt ist. Die Weiterleitung hängt außerdem vom Fortbestand der Quelle ab und wird ausdrücklich getestet.

Welche zusätzlichen Lizenzen werden benötigt?

Microsoft verlangt für native Cross-Tenant-Benutzerdatenmigrationen eine dafür vorgesehene, einmalig pro migriertem Benutzer zugewiesene Zusatzlizenz. Hinzu kommen passende Zielproduktlizenzen. Verfügbarkeit und Bedingungen werden vor der technischen Vorbereitung im konkreten Vertragsmodell geprüft.

Technische Quellen

Microsoft 365 in Frankfurt

Prüfen, ob ein Tenantwechsel wirklich erforderlich ist

fra.digital ordnet Eigentum, Domains, Administratoren und Microsoft-365-Dienste ein. Wenn ein Tenantwechsel erforderlich ist, werden Zielstruktur, Migrationslose, Domaintransfer, Benutzerumstellung und Abnahme getrennt geplant.

Ausgangslage prüfen lassen