What to Check Before a Tenant Move

Acquisitions, mergers, spin-offs or group restructurings: there are a handful of occasions when a complete Dataverse environment has to move into another Microsoft tenant. Microsoft offers a tenant-to-tenant migration for this, which administrators can now run themselves. Until recently this was handled through a Microsoft support ticket. The environment is assigned to the new tenant together with its data (Microsoft Learn: Tenant-to-tenant migration). Even so, such moves rarely go smoothly, because an environment has more threads into its tenant than are visible.

What breaks systematically during the move

Everything with a sign-in. Flow connections, custom connectors, mailbox configurations, application users: the identities behind them do not exist in the new tenant, or with different IDs. Microsoft says this explicitly in its guide. Connections and custom connectors are set up again by hand in the target tenant, and canvas apps and copilot agents are exported by hand beforehand. So the question beforehand is not whether but how many. The answer is in the export, in the connection references and in the flow definitions.

User references in the configuration. Assignments to specific users or teams in processes, owners of flows: references to identities of the old tenant sit everywhere there. Users are carried over during the move through a mapping file. But every hard-wired ID in a process definition is a candidate for silent misbehavior afterwards.

Hard-wired addresses. The environment itself is only re-attached, and its address stays the same at first. What changes are the references around it: SharePoint sites and mailboxes of the old tenant, its domain in email addresses, and often also the (SharePoint) environment URL, if it is switched to the new company name after an acquisition. Every absolute address in scripts, email templates, flow actions or web resources then points to the old world. The old URL keeps answering for months, depending on the transition arrangement, and hides errors wonderfully. Searching for the old domains across the entire export is one of the most productive single checks there is.

Integrations from outside. Everything that accesses the environment from outside authenticates against the old tenant: app registrations, stored secrets. This other side is in no export. It sits in the systems of the integration partners and is, by experience, the part with the longest coordination paths.

License and environment framework. Less technical but just as real: the target tenant needs the matching licenses and enough Dataverse capacity before the move starts. Both sound obvious and have still made deadlines burst, because procurement took longer than the migration itself.

The checklist as a project basis

The four technical blocks give you the up-front inventory, in the same spirit as the analysis before a Dynamics migration: count connections, search process definitions for user and team references, hunt absolute URLs across the export, and agree the integration list with the operators. The result is not a formality but the work plan for the weekend of the move. On that weekend, each of these items needs someone to work it off.

On the organizational frame: the administrators of both tenants carry out the move themselves. That means a request in the source tenant, approval in the target tenant, preparation with the user mapping, and then the actual migration within a time window. This needs coordination between two admin teams who often belong to (until now) different companies. The migration window means downtime for the users. Both belong in the project plan before dates are communicated.

One more piece of advice on timing: the inventory pays off weeks before the date, not days. Not because of the inventory itself. But because it regularly turns up things that should still be repaired or retired before the move.