Is Your Business AI-Ready?
Mergers happen. Companies get acquired, kind of reassembled, then renamed, you know. IT infrastructure gets merged, sometimes quietly, other times not. And somewhere along the way, in that same meeting room, someone just says it, maybe half laughing, “We need to move Dynamics 365 to a new tenant.”
That's when things get complicated.
A Microsoft tenant-to-tenant migration sounds like a fairly contained project on paper. Move the data, recreate the users, flip the switch. In practice, it involves Dataverse environments, user identity mapping, Power Automate flows, SharePoint configurations, mailbox setups, and a long list of components that need to be handled in a specific sequence, or broken post-migration.
78% of enterprises now manage more than one Microsoft 365 tenant. So moving Dynamics 365 is a challenge, that a lot of organisations will end up facing. But, the errors people make when they first start are, almost always basically the same. They underestimate the whole scope, they ignore the pre-migration audit, and they assume it is more automated than it really is. In a word, they treat it like it will just run by itself, but it doesn’t.
So this guide, it kind of walks through what a Dynamics 365 tenant-to-tenant migration really means in practice, including the steps, the usual traps, and what you need to nail down ahead of time so you end up on the other side without data loss, or any noticeable downtime.
Before getting into the how, it's worth being precise about the what.
Tenant-to-tenant migration means transferring a Dynamics 365 environment and its Dataverse data configurations users, and connected applications from one Microsoft tenant to another. Microsoft's own documentation states that the environment does not physically "move"; it gets tied to a new tenant while at the same time being dissociated from the source. No UI changes, no version changes, but a considerable change in how everything is managed and accessed.
This is different from a standard data migration. You're not just moving records. You're moving an environment with dependencies, Power Apps, Power Automate flows, server-side sync, SharePoint integration services, Outlook configurations, many of which need to be manually handled before and after the migration.
The most common triggers are:
This is where a lot of migration projects run into their first surprise.
Microsoft supports tenant-to-tenant migration for production and sandbox environments only. Default, developer, trial, and Teams environments are not supported. That matters if your organisation uses any of those environment types for live work.
There's also a list of components that cannot be migrated through the standard process:
Additionally, Power Apps, Power Automate flows, Power Pages, and Copilot Studio bots all require manual handling, either manual export before migration or manual reconfiguration after. Customer connectors, connections, and gateways must be manually rebuilt in the destination tenant. None of this is automatic.
Knowing these limitations before you start is the difference between a realistic project plan and one that quietly falls apart on migration day.
Here's a practical tenant-to-tenant migration step by step breakdown, covering the stages most guides skip over.
With pre-migration steps complete, the migration itself is initiated through the Power Platform Admin Centre. Admin privileges at the Power Platform or Dynamics 365 level are required. The PowerShell for Power Platform Administrators module is Microsoft's recommended method for handling the process.
The migration links the environment to the destination tenant. During this window, the environment is inaccessible. Plan this for low-traffic periods and communicate clearly to affected users before it starts.
This is where the actual work continues, and where teams who assumed the migration was "done" find the gaps.
Post-migration tasks typically include:
One IT Partner case study involving 1,200 users on a phased 30-day migration achieved 98% user satisfaction, zero HIPAA violations, and zero data loss, but that outcome came from a carefully structured pre-migration compliance checklist and phased rollout, not from winging it.
Microsoft's built-in tools only facilitate the main migration process and still need a lot of manual intervention to deal with connected components. When dealing with complicated environments, third-party tenant to tenant migration tools are used as patch solutions, performing identity mapping, large scale content migration, and delta syncs that minimise downtime windows.
When evaluating tools, the key questions are:
If the migration is big or complicated, it is better to hire professional Microsoft Dynamics 365 developers who have done cross-tenant projects, rather than doing it with the in-house team which is inefficient and inexperienced.
A straightforward migration, a small environment, limited integrations, clear user mapping can be managed internally with careful planning and Microsoft's documentation.
But if your environment includes:
Then hiring Dynamics 365 experts who have executed this migration type before is the more practical decision. The consequences of errors could be very serious - data loss, user disruption, missed deadlines, or compliance exposure - all of these tend to cost more than hiring the right Microsoft consultants from the beginning.
Dotsquares is a Cloud Solution Partner who has first-hand experience of Microsoft tenant-to-tenant migrations and Dynamics 365 environments. Do you require the entire migration support or just need cloud consulting to plan the right approach for your specific set up? The team is always ready to discuss your project with you.
A Dynamics 365 tenant-to-tenant migration is one of those projects that seems smaller than it is, until you’re actually in it. Yes, the route from the source tenant to the destination tenant is well documented, but then you hit the bits that don’t move automatically, the identity mapping effort, the reconfiguration after migration, and the ongoing coordination across IT, operations, and business stakeholders. All of that adds up, and it tends to reward careful planning far more than it rewards speed.
Make a realistic checklist, know what Microsoft's native tools cover and don't cover, and lastly, do not underestimate the post-migration phase - this is the time when most of the actual work takes place.
It's the process of moving a Dynamics 365 environment, data, users, configurations, and connected apps, from one Microsoft tenant to another. Most commonly triggered by mergers, acquisitions, or restructuring.
Yes, Microsoft supports it through the Power Platform Admin Centre and PowerShell, but many components (Power Apps, flows, connectors) require manual export or rebuild. It's not a one-click process.
Dynamics 365 Customer Voice, Omnichannel for Customer Service, Customer Insights (Journeys and Data), component libraries, and any Dataverse environment linked to a finance and operations organisation.
Simple environments can be done in days. Complex setups with multiple apps, integrations, and compliance requirements typically take weeks of planning and phased execution.
Identity mapping errors, data loss, compliance exposure, extended downtime, and broken integrations that weren't caught during the pre-migration audit.
Not always, but for complex environments, tight M&A deadlines, or strict compliance requirements, bringing in experienced Dynamics 365 specialists is usually the lower-risk and faster path.
June 11, 2026Learn the key differences between AI agents and bots, including intelligence, learning capabilities, decision-making, and business use cases.
Keep Reading June 11, 2026Planning a Dynamics 365 tenant-to-tenant migration? Here's a practical step-by-step guide covering from pre-migration prep to post-migration cleanup.
Keep Reading
June 11, 2026Explore the leading data migration tools in 2026 and learn how to select the right platform for secure, efficient, and scalable cloud data migration.
Keep Reading