The Hidden Challenges of Dynamics 365 Tenant-to-Tenant Migration

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.

What Is a Tenant-to-Tenant Migration?

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:

• Mergers and acquisitions requiring IT consolidation
• Company divestitures separating business units onto different tenants
• Rebranding or corporate restructuring
• Security or compliance requirements mandating a clean tenant environment

What Microsoft Supports (And What It Doesn't)

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:

• Dynamics 365 Customer Voice
• Omnichannel for Customer Service
• Component library
• Dynamics 365 Customer Insights, Journeys
• Dynamics 365 Customer Insights, Data
• A Dataverse organisation linked to a finance and operations organisation

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.

Dynamics 365 Migration Checklist: The Steps That Actually Matter

Here's a practical tenant-to-tenant migration step by step breakdown, covering the stages most guides skip over.

Phase 1 - Pre-Migration Preparation

• Audit your environment thoroughly: Map out every component in the source tenant: users and their roles, Power Apps (solution-aware and non-solution-aware separately), Power Automate flows, Power Pages sites, Copilot Studio bots, SharePoint integrations, and any third-party connections. Anything you don't document now will surprise you after cutover.
• Create target tenant users first, before the migration even starts: users have to exist in the destination tenant already, created in Microsoft 365 and Microsoft Entra ID, with licences assigned. You’ll also need to build a user mapping file, that maps source users to destination users. This is what tells the migration process who becomes who. Without it, nothing maps correctly.
  
  
• Handle Power Apps manually: Solution-aware apps need to be exported from the source environment and deleted from it before migration starts. Non-solution-aware apps need to be exported individually as packages. If you don't delete solution-aware canvas apps from the source environment before migrating, they won't function after migration.
  
  
• Prepare Power Automate flows: Flows that aren't already defined in Dataverse solutions need to be added to solutions before migration. Microsoft's PowerShell cmdlet Add-AdminFlowsToSolution can do this in bulk. This step gets skipped more often than it should.
  
  
• Delete Power Pages sites: Any Power Pages website in the environment must be deleted before the migration. It can be recreated post-migration. This one catches people off guard.
  
  
• Migrate and configure mailboxes on the target tenant: If you have custom domains, then the mailboxes on the new tenant have to be configured before the migration starts. Being on the default microsoft domain, the domain name will be changed after migration and mailboxes will need re-configuration in any case.

Phase 2 - Executing the Migration

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.

Phase 3 - Post-Migration Configuration

This is where the actual work continues, and where teams who assumed the migration was "done" find the gaps.

Post-migration tasks typically include:

• Reconfiguring server-side sync - email synchronisation between Dynamics 365 and Exchange needs to be set up again in the destination tenant.
• Reconnecting SharePoint integration - the document management integration between Dynamics 365 and SharePoint needs to be re-established.
• Reconfiguring Dynamics 365 for Outlook - this doesn't carry over automatically
• Rebuilding custom connectors and connections - any connectors or Power Automate connections involving external services need to be recreated.
• Reimporting Power Apps packages - non-solution-aware apps exported pre-migration need to be imported into the destination tenant.
• Testing all critical workflows - before handing things back to users, you should run end-to-end tests on every workflow, every integration, and every automated process, even the ones that “usually work” 
• Validating data integrity - confirm that records, relationships, and attachments have migrated correctly and that nothing is missing, ensuring teams can continue using Dynamics 365 to identify potential customers and manage customer relationships effectively. 

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.

The Hidden Risks Most Teams Underestimate

• Identity mapping errors: In most enterprise environments, identity models aren't straightforward; multiple domains, hybrid identities, guest users, and legacy UPNs can all lead to incorrect user-data mapping during migration. Getting identity reconciliation right before the migration starts is non-negotiable.
• Trying to do too much at once: The typical mistake is trying to solve continuity, standardisation, content cleanup, and perfect governance all at once, which usually ends in delay, support overload, and frustration. Migration day means the business operates. It doesn't mean everything is perfectly configured from the start.
• Compliance exposure: Compliance violations are a serious consequence of a migration gone wrong; mishandling sensitive data during the process can lead to legal and regulatory consequences. For organisations in regulated industries, this isn't a theoretical risk.
• Underestimating downtime impact: Even a well-executed migration involves a window of inaccessibility. For organisations relying on Dynamics 365 for sales, service, or operations in real time, that window needs to be planned for, communicated, and kept as short as possible.

Choosing the Right Tenant-to-Tenant Migration Tool

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:

• Does it support Dynamics 365 and Dataverse environments specifically?
• How does it handle user identity mapping and domain changes?
• Can it migrate incrementally (reducing the downtime window)?
• What reporting and validation does it offer post-migration?

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.

When to Bring in Expert Help

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:

• Multiple Power Apps with complex dependencies
• Active Power Automate flows integrated with external systems
• Dynamics 365 modules that aren't supported in the native migration path
• Strict compliance or data residency requirements
• A hard deadline tied to an M&A close date

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.

Final Thought

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.

FAQs

What is a Dynamics 365 tenant-to-tenant migration?

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.

Is there a native Microsoft tool for tenant-to-tenant migration?

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.

What components can't be migrated natively?

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.

How long does a Dynamics 365 tenant-to-tenant migration take?

Simple environments can be done in days. Complex setups with multiple apps, integrations, and compliance requirements typically take weeks of planning and phased execution.

What are the biggest risks during migration?

Identity mapping errors, data loss, compliance exposure, extended downtime, and broken integrations that weren't caught during the pre-migration audit.

Do we need external help for a tenant-to-tenant migration?

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.