Was vor einem Tenant-Wechsel geprüft werden sollte

Firmenübernahmen, Fusionen, Abspaltungen oder Konzernumbauten: Es gibt eine handvoll Anlässe bei denen eine komplette Dataverse-Umgebung in einen anderen Microsoft-Tenant umziehen muss. Microsoft bietet dafür eine Tenant-zu-Tenant-Migration an welche Administratoren inzwischen selbst ausführen. Bis vor kurzem wurden diese noch durch ein Microsoft Support Ticket erledigt. Die Umgebung wird dabei samt Daten dem neuen Tenant zugeordnet (Microsoft Learn: Tenant-to-tenant migration). Trotzdem gehen solche Umzüge selten glatt denn eine Umgebung hat mehr Fäden in ihren Tenant als sichtbar.

Was beim Umzug systematisch bricht

Alles mit Anmeldung. Verbindungen von Flows, Custom Connectors, Postfach-Konfigurationen und Anwendungsbenutzer: Die Identitäten dahinter existieren im neuen Tenant nicht oder mit anderen IDs. Microsoft sagt das in der Anleitung ausdrücklich: Verbindungen und Custom Connectors werden im Ziel-Tenant von Hand neu eingerichtet, Canvas Apps und Copilot-Agenten vorher von Hand exportiert. Die Frage vorher ist deshalb nicht ob sondern wie viele. Die Antwort steht im Export bei den Connection References und in den Flow-Definitionen.

Benutzerbezüge in der Konfiguration. Zuweisungen an konkrete Benutzer oder Teams in Prozessen, Besitzer von Flows: Überall dort stecken Verweise auf Identitäten des alten Tenants. Benutzer werden beim Umzug zwar über eine Zuordnungsdatei übernommen. Aber jede fest verdrahtete ID in einer Prozessdefinition ist ein Kandidat für stilles Fehlverhalten danach. Auch werden alte und mittlerweile deaktivierte Nutzer selten mit in den neuen Tenant migriert. Dennoch haben sie oftmals verweise zu alten Datensätzen, dies sollte vor dem Umzug bereinigt werden.

Fest verdrahtete Adressen. Die Umgebung selbst wird nur umgehängt ihre Adresse bleibt zunächst gleich. Was sich ändert sind die Bezüge rundherum: SharePoint-Seiten und Postfächer des alten Tenants, dessen Domain in Mailadressen und oft auch die (SharePoint-) Umgebungs-URL, wenn sie nach einer Übernahme auf den neuen Firmennamen umgestellt wird. Jede absolute Adresse in Skripten, E-Mail-Vorlagen, Flow-Aktionen oder Web-Ressourcen zeigt danach auf die alte Welt. Die alte URL antwortet je nach Übergangsregelung noch monatelang und verschleiert damit Fehler wunderbar. Die Suche nach den alten Domains über den gesamten Export gehört zu den ergiebigsten Einzelprüfungen überhaupt.

Integrationen von außen. Alles was von außerhalb auf die Umgebung zugreift authentifiziert sich gegen den alten Tenant: App-Registrierungen, hinterlegte Schlüssel. Diese Gegenseite steht in keinem Export. Sie steht in den Systemen der Integrationspartner und ist erfahrungsgemäß der Teil mit den längsten Abstimmungswegen.

Lizenz- und Umgebungsrahmen. Weniger technisch aber ebenso real: Der Ziel-Tenant braucht die passenden Lizenzen und ausreichend Dataverse-Kapazität bevor der Umzug startet. Beides klingt selbstverständlich und hat trotzdem schon Termine platzen lassen, weil die Beschaffung länger dauerte als die Migration selbst. Hier ist für einen Übergangzeitraum eine Doppellizensierung notwendig.

Die Prüfliste als Projektgrundlage

Aus den vier technischen Blöcken ergibt sich die Vorab-Inventur: Verbindungen zählen, Benutzer- und Team-Verweise in Prozessdefinitionen suchen, absolute URLs über den Export jagen, Integrationsliste mit den Betreibern abstimmen. Das Ergebnis ist keine Formalie sondern der Arbeitsplan für das Wochenende des Umzugs. An diesem Wochenende braucht jede dieser Positionen jemanden der sie abarbeitet.

Zum organisatorischen Rahmen: Den Umzug führen die Administratoren beider Tenants selbst aus - Antrag im Quell-Tenant, Freigabe im Ziel-Tenant, Vorbereitung mit der Benutzerzuordnung und dann die eigentliche Migration in einem Zeitfenster. Das braucht Abstimmung zwischen zwei Admin-Teams welche oft zu (bisher) verschiedenen Unternehmen gehören. Das Migrations Zeitfenster bedeutet Stillstand für die Nutzer. Beides gehört in die Projektplanung bevor Termine kommuniziert werden.

Ein Rat noch zum Zeitpunkt: Die Inventur lohnt sich Wochen vor dem Termin, nicht Tage. Nicht wegen der Inventur selbst. Sondern weil sie regelmäßig Dinge zutage fördert die vor dem Umzug noch repariert oder stillgelegt werden sollten.