Wann eine Tenant-to-Tenant-Migration ansteht
Ein Microsoft-365-Tenant lässt sich nicht in einen anderen verschieben, nachträglich umbenennen oder mit einem zweiten verschmelzen. Sobald zwei Organisationen einen gemeinsamen Tenant brauchen oder eine Organisation ihren bisherigen Tenant verlassen muss, ist das ein Migrationsprojekt. Die typischen Auslöser:
- Fusion: Zwei Unternehmen werden eins und wollen ein gemeinsames Adressbuch, gemeinsame Teams und einheitliche Richtlinien. Meist bleibt der größere oder besser gepflegte Tenant bestehen, der andere wird hineinmigriert.
- Übernahme: Der Käufer übernimmt die Nutzer des gekauften Unternehmens in seinen Tenant. Oft gibt es eine vertragliche Frist, bis zu der die alte Umgebung abgeschaltet sein muss.
- Carve-out: Ein Geschäftsbereich wird verkauft oder ausgegründet und braucht einen eigenen Tenant, in den nur seine Postfächer, Dateien und Gruppen wandern, nicht die des Mutterunternehmens.
- Konsolidierung: Standorte oder Tochtergesellschaften haben über die Jahre eigene Tenants angelegt; die IT führt sie zu einem zusammen, um Lizenzen, Sicherheit und Verwaltung zu vereinheitlichen.
- Umbenennung oder Regionswechsel: Der ursprüngliche Tenant-Name (die onmicrosoft.com-Adresse) oder die Datenregion passt nicht mehr. Beides lässt sich nachträglich nicht frei ändern; ein neuer Tenant ist dann der saubere Weg.
Unabhängig vom Auslöser bleibt die Aufgabe gleich: Identitäten, Postfächer, Dateien und Gruppen müssen vollständig im Ziel ankommen, und die E-Mail-Domain muss an einem Stichtag den Tenant wechseln. Dieser Ratgeber beschreibt, wie das in der Praxis abläuft. Die Leistung selbst, mit Festpreis und Abschlussbericht, finden Sie unter Tenant-to-Tenant-Migration.
Begriffe: Tenant, Mandant, Office 365, M365
Die Suchbegriffe sind uneinheitlich, gemeint ist immer dasselbe. Ein Tenant ist die Instanz von Microsoft 365, die zu einer Organisation gehört: ein eigenes Verzeichnis in Entra ID (früher Azure AD), eigene Domains, Lizenzen, Richtlinien und Daten. Auf Deutsch heißt das Mandant; Microsoft verwendet in deutschen Oberflächen „Mandant“, in der Dokumentation meist „Tenant“. „Tenant zu Tenant“, „Tenant-to-Tenant“ und „T2T“ bezeichnen die Migration von einem Tenant in einen anderen. Office 365 ist der alte Produktname, Microsoft 365 (kurz M365) der aktuelle; technisch ist eine „Office 365 Tenant-to-Tenant-Migration“ nichts anderes als eine Microsoft-365-Tenant-Migration.
Was migriert wird und was nicht automatisch
Zwischen zwei Microsoft-365-Tenants nutzen Quelle und Ziel dieselben Konzepte, deshalb kommt auf dieser Route am meisten 1:1 mit. Mit unserer eigenen Migrationssoftware übertragen und validieren wir pro Objekt:
- Postfächer mit vollständiger Ordnerstruktur und Anhängen; freigegebene Postfächer nach Aufwand.
- Kalender inklusive Serienterminen und Teilnehmern.
- Kontakte und Kontaktgruppen der Nutzer.
- OneDrive mit Ordnerstruktur, bis 50 GB je Nutzer im Festpreis enthalten.
- SharePoint-Websites und Teams-Dateien, also die Dokumentbibliotheken hinter den Teams-Kanälen; Umfang nach Discovery-Analyse. Details auf der Seite SharePoint-Migration.
- Gruppen und Verteilerlisten mit Mitgliedern und Besitzern.
- Freigaben: Datei- und Ordnerfreigaben inklusive Freigabelinks, Gruppenbesitz sowie Kalenderfreigaben und -stellvertretungen; das ist eine Besonderheit der Route Microsoft 365 zu Microsoft 365.
Dazu gehört ehrlicherweise auch, was nicht automatisch mitkommt und im Ziel neu eingerichtet oder geprüft werden muss:
- Teams-Chats (Einzel- und Gruppenchats) und Kanalbeiträge. Die Dateien dahinter wandern mit, die Nachrichten nicht. Das gilt bei jedem Tenant-Wechsel, nicht nur bei uns.
- Postfach-Zugriffsrechte, Stellvertretungen auf Postfachebene, „Senden als“ und „Senden im Auftrag“.
- Posteingangsregeln, Signaturen und Outlook-Profile auf den Endgeräten.
- Gelesen-Status und Kategorien: Mails kommen im Ziel als ungelesen an.
- Ausnahmen einzelner Serientermine und sekundäre Kalender.
- Berechtigungen auf Site- und Bibliotheksebene in SharePoint.
- Admin-Rollen, Sicherheits- und Compliance-Richtlinien (Conditional Access, Aufbewahrung, DLP), Intune-Konfiguration, Power-Automate-Flows, Power Apps und App-Registrierungen.
- Der DNS-Wechsel selbst, also MX, Autodiscover und SPF/DKIM/DMARC für das Ziel.
Jeder dieser Punkte steht im Discovery-Bericht mit einem Verantwortlichen, damit er vor dem Stichtag erledigt ist.
Identitäten: Entra ID, Hybrid, UPN und Mapping
Bevor ein einziges Byte kopiert wird, muss klar sein, welches Quellkonto zu welchem Zielkonto gehört. Das Ergebnis ist eine Mapping-Tabelle: eine Zeile je Nutzer, je Gruppe und je freigegebenem Postfach mit Quelladresse, Zieladresse, Lizenz im Ziel und Status. Sie ist das zentrale Arbeitsdokument des Projekts; Testmigration, Vorab-Migration, Delta-Sync und Validierung arbeiten alle damit.
In reinen Cloud-Tenants legen wir die Zielkonten auf Wunsch mit an. Entscheidend ist der UPN (User Principal Name), mit dem sich der Nutzer anmeldet: Er enthält die Domain, und die Domain gehört bis zum Stichtag noch dem Quell-Tenant. Deshalb werden Zielkonten zunächst mit einer Übergangsdomain angelegt (etwa der onmicrosoft.com-Adresse des Ziels oder einer bereits im Ziel verifizierten Domain) und erst nach dem Domain-Wechsel auf die endgültige Adresse umgestellt. Nutzer, die bereits in beiden Tenants existieren, etwa weil der Käufer für die Zusammenarbeit schon Konten angelegt hat, müssen vorher bereinigt werden, sonst entstehen Dubletten.
Hybride Umgebungen mit lokalem Active Directory und Entra ID Connect brauchen eine Entscheidung mehr: Welche Seite führt die Identitäten künftig? Werden die Nutzer aus dem alten AD in das AD oder den Tenant des Ziels übernommen, muss die Synchronisierung im Quell-Tenant sauber beendet und im Ziel aufgesetzt werden; sonst überschreibt der Sync Änderungen oder legt Konten doppelt an. Das planen wir mit Ihrem IT-Team, denn der Zeitpunkt der Sync-Umstellung hängt am Domain-Wechsel.
Namenskonflikte sind der zweite Teil der Identitätsarbeit: gleiche Anzeigenamen in beiden Tenants, Aliasse, die es doppelt gibt, Gruppen mit identischem Namen, Nutzer ohne Lizenz im Ziel. Die Discovery-Analyse listet sie auf, und Sie entscheiden vor dem Angebot, wie sie aufgelöst werden.
Der Domain-Wechsel Schritt für Schritt
Eine Domain kann zu jedem Zeitpunkt nur in einem Microsoft-365-Tenant verifiziert sein. Das ist der Grund, warum eine Tenant-Migration genau einen Schritt hat, der eng getaktet werden muss, während alles andere entzerrt im Hintergrund läuft. Die Reihenfolge:
- Domain im Quell-Tenant loslösen. Alle Objekte, die die Domain noch verwenden, werden auf eine andere Domain umgestellt: Nutzer-UPNs und primäre Adressen, Aliasse, Gruppen, freigegebene Postfächer, Ressourcen. Solange ein einziges Objekt die Domain nutzt, lässt sie sich nicht entfernen. Dieser Schritt wird am häufigsten unterschätzt, weil Aliasse an Gruppen und alten Konten übersehen werden.
- Domain entfernen. Ist sie frei, wird sie im Quell-Tenant gelöscht. Die Freigabe kann etwas dauern; planen Sie das im Zeitfenster ein.
- Domain im Ziel-Tenant hinzufügen und verifizieren (TXT-Eintrag im DNS). Erst ab jetzt gehört die Domain dem Ziel.
- Adressen im Ziel setzen. Die Zielkonten erhalten ihre endgültigen UPNs und primären Adressen, die Aliasse werden nachgezogen. Hier zahlt sich die Mapping-Tabelle aus, weil nichts mehr überlegt, sondern nur abgearbeitet wird.
- MX und Autodiscover umstellen. Der MX-Eintrag zeigt auf den Ziel-Tenant, Autodiscover ebenfalls; SPF, DKIM und DMARC werden für das Ziel eingerichtet. Senken Sie die TTL dieser Einträge schon Tage vorher (etwa auf 300 Sekunden), damit die Änderung schnell greift. Die Details stehen im Ratgeber E-Mail-Umzug ohne Ausfall: MX umstellen.
- Delta-Sync. Alles, was seit der Vorab-Migration im Quell-Tenant dazugekommen ist, wird nachgezogen.
Während des Wechsels können eingehende E-Mails kurz nicht zugestellt werden; sendende Mailserver versuchen es bei vorübergehenden Fehlern üblicherweise über Stunden erneut. Trotzdem liegt das Fenster meist am Wochenende. Solange davor beide Tenants parallel laufen, richten wir mit Ihnen ein Mail-Routing ein, damit Nachrichten zwischen alter und neuer Umgebung zugestellt werden.
Lizenzen im Ziel-Tenant
Jedes Zielkonto braucht vor der Vorab-Migration eine Lizenz, die den jeweiligen Dienst enthält: Exchange Online für das Postfach, OneDrive für die Dateien, SharePoint für die Sites. Prüfen Sie dabei die Postfachgrößen: Wer im Quell-Tenant ein großes Postfach oder ein Archivpostfach hat, braucht im Ziel einen Plan mit passendem Kontingent. Die Lizenzen des Quell-Tenants lassen sich in der Regel nicht übertragen, sondern laufen dort aus; der Doppelbezug für die Übergangszeit gehört in die Kostenplanung. Plattformlizenzen sind in unseren Preisen nicht enthalten; auf Wunsch legen wir Nutzer, Gruppen und Lizenzen im Ziel an.
Microsofts eigenes Werkzeug: Cross-Tenant Mailbox Migration
Microsoft bietet in Exchange Online eine Funktion, um Postfächer zwischen Tenants zu verschieben („Cross-Tenant Mailbox Migration“). Sachlich eingeordnet: Sie überträgt laut Microsoft-Dokumentation die Inhalte des Postfachs (E-Mails, Kalender, Kontakte, Aufgaben, Notizen) und wird über PowerShell gesteuert. Voraussetzungen sind unter anderem eine Organisationsbeziehung und eine App-Registrierung zwischen beiden Tenants, für jedes Postfach ein vorab angelegtes Zielobjekt (Mail-Benutzer) mit passenden Attributen sowie eine zusätzliche Migrationslizenz je Nutzer. Postfächer mit Aufbewahrungssperre werden nicht verschoben; Zugriffsrechte, Regeln und Signaturen müssen anschließend neu gesetzt werden, und nach einem erfolgreichen Durchlauf wird das Quellpostfach laut Dokumentation entfernt.
Für OneDrive, SharePoint, Teams-Dateien und Gruppen ist das Werkzeug nicht zuständig. Und es liefert nach unserer Kenntnis keinen Abgleich pro Objekt, mit dem Sie gegenüber Geschäftsführung oder Datenschutzbeauftragtem belegen, dass im Ziel alles angekommen ist, bevor der Quell-Tenant gelöscht wird. Für reine Postfachprojekte mit PowerShell-Erfahrung im Haus kann es ein gangbarer Weg sein. Wir setzen stattdessen unsere eigene Software ein, die alle Datenarten über dieselbe Mapping-Tabelle migriert, den Quell-Tenant unangetastet lässt und am Ende den Abschlussbericht erzeugt. Nichts davon wird auf Endgeräten installiert.
Ablauf einer Tenant-Migration
- Discovery. Mit Admin-Zugang zu beiden Tenants erfassen wir Nutzer, Lizenzen, Domains, Gruppen, freigegebene Postfächer, OneDrive-Volumen, SharePoint-Sites und Teams. Ergebnis: Discovery-Bericht mit Mapping-Tabelle, Konfliktliste und der Liste der Punkte, die nicht automatisch migriert werden. Darauf basiert das Festpreis-Angebot.
- Testmigration. Zwei bis drei echte Postfächer samt OneDrive werden in den Ziel-Tenant migriert und von den Nutzern geprüft. Hier zeigt sich, ob Mapping, Lizenzen und Berechtigungen stimmen.
- Vorab-Migration. Der Großteil der Daten wird kopiert, während beide Tenants produktiv sind.
- Cutover mit Domain-Wechsel. Die oben beschriebene Abfolge in einem abgestimmten Fenster.
- Delta-Sync. Neue und geänderte Objekte seit der Vorab-Migration werden nachgezogen.
- Validierung und Abschlussbericht. Jedes Postfach, jeder Ordner, jedes Laufwerk wird gegen die Quelle abgeglichen. Der Bericht listet die Vollständigkeit pro Objekt und die Punkte, die manuell nachgezogen wurden.
Die sechs Phasen gelten für alle unsere Projekte und sind unter Ablauf beschrieben. Datenschutzrechtlich sind bei einer Tenant-Migration oft zwei Rechtsträger beteiligt; welche Verträge dann nötig sind, klären Sie mit Ihrem Datenschutzbeauftragten (keine Rechtsberatung). Die Daten laufen in jedem Fall ausschließlich über unsere Server in Deutschland und der EU, einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO stellen wir auf Wunsch. Mehr dazu im Ratgeber DSGVO-konforme Cloud-Migration.
Wie lange dauert eine Tenant-to-Tenant-Migration?
Die Dauer hängt an drei Größen: Zahl der Postfächer, Datenvolumen (vor allem OneDrive und SharePoint) und Vorbereitungsaufwand (Konflikte, Hybrid-Umstellung, Lizenzbeschaffung). Die Vorab-Migration selbst ist unkritisch, weil sie im Hintergrund läuft; sie dauert bei kleinen Umgebungen Stunden bis wenige Tage, bei großen mehrere Wochen. Eng ist nur der Domain-Wechsel, der in einem Fenster von einigen Stunden abgearbeitet wird, meist am Wochenende. Realistisch gilt: Kleine Umgebungen mit wenigen Dutzend Postfächern sind innerhalb weniger Tage umgestellt, größere brauchen ein bis mehrere Wochen Vorlauf, vor allem für Discovery, Testmigration und die Entscheidungen Ihrer Organisation.
Was kostet eine Tenant-to-Tenant-Migration?
Es gelten unsere öffentlichen Listenpreise, alle netto: 200 € Projektpauschale (Kickoff, Zugänge, Discovery, Testmigration, Cutover-Begleitung), 29 € je Postfach für E-Mails mit Ordnern inklusive Delta-Sync und Validierung, je 5 € für Kalender und Kontakte sowie 19 € je Nutzer für OneDrive bis 50 GB. Ab 50 Postfächern gibt es 10 % Rabatt auf die Postfach-Summe, ab 100 Postfächern 15 %; ab 250 Postfächern kalkulieren wir individuell.
Beispiel: 50 Postfächer mit allen vier Bausteinen (E-Mails, Kalender, Kontakte, OneDrive) kosten 2.810 € netto, also 200 € Pauschale plus 50 × 58 € abzüglich 10 % Rabatt. SharePoint-Websites, Teams-Dateien und freigegebene Postfächer kalkulieren wir nach der Discovery-Analyse, weil ihr Umfang stark schwankt. Nicht enthalten sind die Microsoft-365-Lizenzen im Ziel. Rechnen Sie Ihre Konfiguration im Preisrechner durch; die Kostenfaktoren erklärt der Ratgeber Was kostet eine E-Mail-Migration?.
Checkliste für die Tenant-Migration
| Phase | Aufgabe | Wer |
|---|---|---|
| Vorbereitung | Ziel-Tenant festlegen, Admin-Zugänge für beide Tenants bereitstellen, Stichtag grob planen | Kunde |
| Vorbereitung | Discovery beider Tenants, Mapping-Tabelle, Konfliktliste, Liste der manuellen Punkte | Migravault |
| Vorbereitung | Namenskonflikte entscheiden, Hybrid-Strategie (Entra ID Connect) festlegen | Kunde mit Migravault |
| Vorbereitung | Lizenzen im Ziel beschaffen, Zielkonten mit Übergangsdomain anlegen, DNS-Zugriff sicherstellen, TTL senken | Kunde (oder Migravault auf Wunsch) |
| Test | Testmigration mit zwei bis drei Postfächern, Nutzerfeedback einholen | Migravault, Kunde prüft |
| Vorab-Migration | Postfächer, Kalender, Kontakte, OneDrive, SharePoint und Gruppen in den Ziel-Tenant kopieren | Migravault |
| Vorab-Migration | Mail-Routing zwischen den Tenants für die Übergangsphase einrichten | Migravault mit Kunde |
| Vorab-Migration | Nutzer informieren: Stichtag, neue Anmeldung, Outlook-Profil, Teams-Chats sichern | Kunde |
| Cutover | Domain im Quell-Tenant loslösen und entfernen, im Ziel hinzufügen, Adressen setzen | Migravault mit Kunde |
| Cutover | MX, Autodiscover, SPF, DKIM und DMARC umstellen | Kunde nach Anleitung (oder Migravault) |
| Cutover | Delta-Sync aller Datenarten | Migravault |
| Nacharbeit | Zugriffsrechte, Stellvertretungen, Posteingangsregeln, Signaturen, Richtlinien, Flows neu einrichten | Kunde nach Liste aus dem Discovery-Bericht |
| Nacharbeit | Validierung pro Objekt, Abschlussbericht, Freigabe für die Abschaltung des Quell-Tenants | Migravault, Kunde entscheidet |
Typische Fehler
- Domain-Wechsel ohne Vorbereitung: Am Stichtag stellt sich heraus, dass Aliasse, Gruppen oder ein alter Dienstaccount die Domain noch nutzen. Die Freigabe scheitert, das Fenster verstreicht. Abhilfe: Vorher alle Objekte mit der Domain auflisten und umstellen.
- Lizenzen zu spät: Ohne Lizenz im Ziel gibt es kein Postfach, die Vorab-Migration kann nicht starten. Lizenzen gehören in die erste Projektwoche.
- Hybrid-Sync nicht bedacht: Entra ID Connect schreibt im Quell-Tenant weiter und überschreibt Änderungen oder blockiert das Entfernen der Domain.
- Teams-Chats nicht angekündigt: Nutzer erwarten ihre Chats im neuen Tenant und finden sie nicht. Wichtige Verläufe vorher exportieren oder in Dateien sichern lassen.
- Stellvertretungen und Regeln vergessen: Die Assistenz kann den Kalender der Geschäftsführung nicht mehr öffnen, Weiterleitungen greifen nicht. Beides steht im Discovery-Bericht; es braucht einen Verantwortlichen.
- Kein Abgleich vor der Abschaltung: Der Quell-Tenant wird gekündigt, bevor jemand geprüft hat, ob wirklich alles angekommen ist. Die Validierung pro Objekt ist genau dafür da.
Fazit
Eine Tenant-to-Tenant-Migration ist ein Projekt, in dem Identitäten, Domain, Lizenzen und Daten in fester Reihenfolge wandern. Die Datenmenge ist dank Vorab-Migration und Delta-Sync beherrschbar; die Arbeit steckt in Discovery, Mapping und dem eng getakteten Domain-Wechsel. Als Tenant-to-Tenant-Migration übernehmen wir diesen Ablauf zum Festpreis, mit eigener Software, Servern in Deutschland und der EU und einem Abschlussbericht pro Objekt. OneDrive-Laufwerke und weitere Dateiquellen laufen über die Cloud-Speicher-Migration. Die Erstanalyse beider Tenants ist kostenlos.
Häufige Fragen
Wie lange dauert eine Tenant-to-Tenant-Migration?
Die Vorab-Migration läuft im Hintergrund, während beide Tenants produktiv bleiben: bei kleinen Umgebungen Stunden bis wenige Tage, bei großen mehrere Wochen, abhängig von Postfachzahl und Datenvolumen. Eng getaktet ist nur der Domain-Wechsel mit MX-Umstellung in einem Fenster von einigen Stunden, meist am Wochenende. Insgesamt sind kleine Umgebungen innerhalb weniger Tage umgestellt, größere brauchen ein bis mehrere Wochen Vorlauf für Discovery, Testmigration und Entscheidungen.
Was kostet eine Tenant-to-Tenant-Migration?
Es gelten die Listenpreise: 200 € Projektpauschale, 29 € je Postfach für E-Mails mit Ordnern, je 5 € für Kalender und Kontakte, 19 € je Nutzer für OneDrive bis 50 GB. 50 Postfächer mit allen vier Bausteinen kosten 2.810 € netto, weil ab 50 Postfächern 10 % Rabatt auf die Postfach-Summe greifen. SharePoint-Websites, Teams-Dateien und freigegebene Postfächer kalkulieren wir nach der Discovery-Analyse. Microsoft-365-Lizenzen im Ziel sind nicht enthalten.
Bleiben die E-Mail-Adressen gleich?
Ja, wenn die Domain mitwandert. Beim Cutover wird sie im Quell-Tenant entfernt und im Ziel-Tenant hinzugefügt; danach erhalten die Nutzer dort ihre bisherigen Adressen und Aliasse. Bis zu diesem Zeitpunkt haben die Zielkonten eine Übergangsdomain. Bei Übernahmen, in denen die Nutzer die Domain des Käufers bekommen sollen, richten wir die alten Adressen als Aliasse ein, damit eingehende E-Mails weiter ankommen.
Was passiert mit Microsoft Teams?
Die Dateien der Teams-Kanäle liegen in SharePoint und werden mit den Sites migriert; Gruppenmitgliedschaften kommen ebenfalls mit. Chat-Nachrichten, Kanalbeiträge und Besprechungsverläufe lassen sich dagegen nicht in einen anderen Tenant übertragen. Wichtige Verläufe sollten vor dem Stichtag gesichert werden; die Nutzer melden sich nach dem Wechsel im neuen Tenant an und finden dort die migrierten Dateien.
Kann die Domain gleichzeitig in beiden Tenants sein?
Nein. Eine Domain ist zu jedem Zeitpunkt nur in einem Microsoft-365-Tenant verifiziert. Deshalb wird der Wechsel als feste Abfolge in einem kurzen Fenster durchgeführt: alle Objekte im alten Tenant auf eine andere Domain umstellen, Domain entfernen, im Ziel hinzufügen und verifizieren, Adressen setzen, MX umstellen. Die Daten sind zu diesem Zeitpunkt bereits weitgehend im Ziel.
Was müssen die Nutzer nach dem Wechsel tun?
Sie melden sich mit ihrem Konto im neuen Tenant an, in der Regel mit neuem Passwort und neu eingerichteter Mehrfaktor-Authentifizierung. Outlook, Teams und der OneDrive-Client auf den Endgeräten müssen mit dem neuen Konto verbunden werden, weil Profile und Anmeldungen nicht mitwandern. Signaturen, Posteingangsregeln und persönliche Einstellungen werden neu gesetzt. Eine kurze Anleitung für die Nutzer gehört zu jedem Projekt; installiert werden muss nichts.
Quellen & weiterführende Dokumentation
- Microsoft Learn: Planen einer Migration von Microsoft 365-Mandanten zu Mandanten — Microsofts Übersicht der Architekturen (Einzel-Event, phasenweise, Tenant-Split)
- Microsoft Learn: Mandantenübergreifende Postfachmigration — Cross-Tenant Mailbox Migration für Postfächer zwischen zwei Tenants
- Microsoft Learn: Übersicht über die mandantenübergreifende OneDrive-Migration — OneDrive-Inhalte zwischen Tenants verschieben
- Microsoft Learn: Übersicht über die mandantenübergreifende SharePoint-Websitemigration — SharePoint-Sites zwischen Tenants verschieben
- Microsoft Learn: Mandantenübergreifende Identitätszuordnung — Zuordnung der Benutzeridentitäten zwischen Quell- und Ziel-Tenant
