Dynamics 365 Tenant to Tenant Migration: The Complete Guide

• Last updated: 15 October 2026
• Dynamics 365,Migration
• Editorial Team

If your understanding of Dynamics 365 tenant-to-tenant migration is “you have to open a Microsoft Support ticket and wait,” that’s out of date. Microsoft now runs this as a self-service feature inside the Power Platform admin center, with a PowerShell path for automation, and the documentation behind it was last updated just weeks before this guide was written. That’s genuinely good news for IT teams planning a merger, acquisition, or tenant consolidation that includes a Dynamics 365 or Power Platform environment.

The catch, and there’s always one, is that “self-service” doesn’t mean “automatic.” The Dataverse data itself moves cleanly. Nearly everything built on top of it, Power Automate flows, Power Apps, Copilot Studio bots, Power Pages websites, and every security group, needs manual rework before and after. This guide covers exactly what Microsoft’s native tool does, what it doesn’t, and where the real work in a Dynamics 365 tenant migration actually lives.

• Key takeaway: Microsoft’s tenant-to-tenant migration feature is self-service, through the Power Platform admin center or PowerShell, and was last updated in September 2026.
• Key takeaway: The environment doesn’t physically move. It’s unlinked from the source tenant and linked to the destination tenant, keeping the same URL, organization ID, and name.
• Key takeaway: Security groups are never migrated. Any admin not listed in the user-mapping file will see what looks like a completely empty environment after migration, a permissions issue, not data loss.
• Key takeaway: Only production and sandbox Dataverse environments are supported. Default, developer, trial, and Teams environments cannot be migrated this way, and GCC-to-public-cloud moves aren’t supported at all.
• Key takeaway: The Dataverse move itself typically completes within 24 hours, but the full project, including rebuilding flows, apps, and permissions, takes considerably longer.

What Is Dynamics 365 Tenant to Tenant Migration?

Dynamics 365 tenant-to-tenant migration is the process of moving a Dataverse environment, and everything built on it, CRM and ERP data, Power Apps, Power Automate flows, and more, from one Microsoft tenant to another. It’s a distinct workstream from a standard Microsoft 365 tenant-to-tenant migration, which handles mailboxes, OneDrive, SharePoint, and Teams. Dataverse environments live in a separate administrative layer, the Power Platform admin center, with their own migration mechanics entirely.

This comes up most often in the same scenarios that drive a broader Microsoft 365 migration:

• A company using Dynamics 365 Sales, Customer Service, or Field Service is acquired and needs its CRM environment moved into the parent organization’s tenant
• A business divests a division running its own Dynamics 365 or Power Platform environment
• Multiple tenants with separate Dataverse environments are being consolidated into one
• A custom line-of-business app built on Power Apps and Dataverse needs to follow its users into a new tenant

The tenant-to-tenant pillar guide for broader Microsoft 365 migrations flags this exact gap: Dynamics 365 and Power Platform data need separate handling from mailboxes and SharePoint. This guide is that separate handling.

Does Microsoft Have a Native Tool for Dynamics 365 Tenant to Tenant Migration?

Yes. Microsoft’s tenant-to-tenant migration feature, available directly in the Power Platform admin center and through PowerShell, moves a Dataverse environment’s data and schema between tenants without a third-party tool. This documentation was updated September 4, 2026, confirming the capability is current and actively maintained, not a legacy feature quietly left in place.

The environment doesn’t physically relocate. Instead, it’s unlinked from the source tenant and linked to the destination tenant. The URL, organization ID, and environment name stay exactly the same, which matters for any integrations or bookmarks pointing at the environment.

What Does Microsoft’s Native Tool Actually Cover?

The native tool supports production and sandbox environments that contain Dataverse. It does not support default, developer, trial, or Teams environments, and it does not support migration between Government Community Cloud and public cloud tenants in either direction. A handful of specific Dynamics 365 components also fall outside what this tool handles.

• Not supported at all: Dynamics 365 Customer Voice, Omnichannel for Customer Service, and the component library.
• Needs separate handling: Dynamics 365 Customer Insights – Journeys and Customer Insights – Data each require their own migration process, and Customer Insights – Journeys specifically requires contacting Microsoft technical support directly rather than using the self-service tool.
• Cannot be migrated: A Dataverse organization linked to a Finance and Operations organization cannot move through this process at all.

If your environment includes any of these, budget extra time and, in the case of Customer Insights – Journeys, plan on a support-assisted process running in parallel with the self-service Dataverse move.

What Are the Prerequisites Before You Start?

Microsoft requires a short list of prerequisites to be in place before a migration request can even be submitted, and skipping any of them is a guaranteed stall later in the process.

• Users created in the destination tenant. Every user who needs access post-migration must already exist in Microsoft 365 and Microsoft Entra ID in the target tenant, with the correct license assigned.
• Admin privileges. You need Power Platform or Dynamics 365 administrator credentials in both the source and destination tenants to complete the request, approval, and migration steps.
• PowerShell for Power Platform Administrators. This is Microsoft’s recommended module for the admin-level commands involved, and both source and target admins need it installed if you’re migrating via PowerShell rather than the admin center UI.

Microsoft’s own guidance is also direct about testing first: copy the production environment to a new sandbox environment, then migrate that sandbox copy before touching production. This surfaces preparation mistakes, missing users, broken mappings, forgotten Power Pages sites, in a low-stakes environment instead of during the real cutover.

What Needs Manual Handling Before and After Migration?

Power Automate flows, Power Apps, Copilot Studio chatbots, and Power Pages websites all require manual export and reimport around the migration, and security groups are never migrated at all. This is where most of the real project effort lives, not in the Dataverse move itself.

• Power Automate

  Flows already defined inside a Dataverse solution require no extra prep work. Any flow that isn’t needs to be added to a solution before migration, which can be done in bulk with Microsoft’s Add-AdminFlowsToSolution PowerShell command. After migration, every imported flow is turned off by default and needs to be manually re-enabled, and any HTTP-triggered flow generates a new URL on import, meaning every external system or app calling that flow needs updating.

• Power Apps

  Solution-aware apps need to be exported from the Solutions page and deleted from the source environment before migration, canvas apps, custom pages, and component libraries left in place simply won’t work after the move. Apps that aren’t solution-aware need to be exported individually through the Export package option. Customer connectors, connections, and gateways aren’t migrated at all and must be manually rebuilt in the destination.

• Copilot Studio

  Chatbots are solution-aware, so they export and import the same way solution-aware Power Apps do. Dependent components, connections, environment variables, and custom connectors, typically still need manual reconfiguration during or after the move.

• Power Pages

  This is the gotcha most teams miss: Power Pages websites must be deleted from the environment before migration can proceed. There’s no export-and-reimport path. After migration, each site needs to be reprovisioned from scratch in the new environment using the same portal type and language.

  Security Groups

  Security group migration isn’t supported, full stop. Every security group needs to be recreated and reassigned in the destination tenant after the move completes.

Admin Center UI or PowerShell: Which Should You Use?

The Power Platform admin center UI works well for a single environment move with a manageable user count, while PowerShell is the better choice for migrating multiple environments, automating repeatable steps, or integrating the migration into a larger scripted cutover plan. Both paths run through the same underlying process and produce the same result.

Through the admin center, a source admin selects the environment, chooses Move Environment from the command bar, and enters the destination tenant ID. The destination tenant sees a pending request banner, and once approved, a Begin Move button appears on the source side to walk through uploading and validating the user-mapping file before the actual move executes.

The PowerShell path uses a specific sequence of cmdlets, TenantToTenant-SubmitMigrationRequest to start the request, TenantToTenant-ViewApprovalRequest and TenantToTenant-ManageMigrationRequest for the destination admin to approve it, then TenantToTenant-UploadUserMappingFile, TenantToTenant-PrepareMigration, and finally TenantToTenant-MigratePowerAppEnvironment to execute the move. A TenantToTenant-GetMigrationStatus command is available at each stage to check progress, which matters since the prepare and migrate steps can each take meaningful time to complete, especially with larger user-mapping files.

Whichever path you choose, the 7-day clock matters in two places: the destination tenant’s approval window expires after 7 days, and once validation succeeds, you have 7 days to complete the actual move before needing to re-validate from scratch.

What Happens to Mailbox and Outlook Integration After Migration?

If a mapped user already has a mailbox in the destination tenant, Dynamics 365’s mailbox configuration carries over automatically. If they don’t, or if the environment was using the default onmicrosoft.com domain, mailbox settings need to be manually reconfigured after migration. This affects server-side sync and Dynamics 365 for Outlook specifically.

The distinction matters in practice: an organization migrating into a tenant where users’ mailboxes were already provisioned ahead of time, as part of the broader Microsoft 365 migration, sees mailbox integration continue working with no extra effort. An organization still using onmicrosoft.com addresses on either side needs to plan on reconfiguring Exchange Online connections for every affected user as a distinct post-migration task, not an assumption.

How Do You Build the User Mapping File?

Every Dynamics 365 tenant-to-tenant migration requires a usermapping.csv file pairing each source user with their destination tenant account, and Microsoft’s validation process checks this file closely enough that small formatting mistakes are the most common reason migrations stall before they start.

• The file must be named usermapping.csv exactly. The filename check is case-sensitive.
• Records must be comma-separated, not semicolon-separated, with exactly two columns per line: source email and destination email.
• Every user listed must already exist and hold a valid license in the destination tenant before validation will succeed.
• Application users cannot be mapped through this process by design. Create them fresh in the destination tenant instead.

Microsoft’s validation returns specific, documented error codes when something’s wrong. Reading and fixing these before resubmitting saves far more time than guessing at what went wrong.

Error Code	What It Means	How to Fix It
SourceUserIdMissingInUserMap	The source user field is empty	Check and fix the source user entry in the mapping file
TargetUserIdMissingInUserMap	The target user field is empty	Check and fix the target user entry in the mapping file
SourceUserIdIsNotValidGuid	The source user isn’t a valid GUID	Correct the source user value to a valid GUID
SourceUserDoesNotExistInOrgDB	No matching user found in the source organization	Remove that entry from the mapping file
TargetUPNDoesNotExistInAAD	The target user isn’t found in the destination tenant’s Entra ID	Fix the target user or remove the entry
ApplicationUserCannotBeMapped	The source entry is an application user	No action needed; create application users fresh in the destination instead

Most of these come down to the same root cause: the user-mapping file was built before the destination tenant’s users, licenses, and Entra ID accounts were fully in place. Finishing identity and licensing work in the target tenant before building the mapping file avoids the majority of these errors entirely.

What Are the Most Common Mistakes in a Dynamics 365 Tenant Migration?

The most common and most disruptive mistake is forgetting that security groups don’t migrate, which makes a perfectly successful migration look like a total data loss to any admin who wasn’t included in the user-mapping file. Microsoft’s own documentation calls this out directly because it happens often enough to warrant a specific warning.

• The “empty environment” scare. An admin who migrates successfully but wasn’t in the user-mapping file opens the destination environment and sees nothing. This is a permissions issue, not data loss. Assigning the System Administrator role to validating admins immediately after migration prevents this entirely.
• Skipping the Power Pages deletion step. Since websites must be deleted before migration rather than exported, teams that don’t realize this in advance lose time rebuilding sites they assumed would carry over.
• Missing the 7-day windows. Both the target tenant’s approval window and the post-validation migration window expire after 7 days. Missing either means restarting that stage from scratch.
• Forgetting flows are disabled on import. Teams that assume a successful migration means a fully functional environment are often surprised when none of their Power Automate flows are actually running.
• Skipping the sandbox test run. Microsoft explicitly recommends copying production to a sandbox environment and migrating that copy first. Skipping this step means the production migration is your first and only chance to catch preparation mistakes.

How Long Does a Dynamics 365 Tenant to Tenant Migration Take?

The Dataverse environment move itself typically completes within 24 hours once validation succeeds, but the full project, covering preparation, manual app and flow rework, and validation, runs considerably longer depending on how much is built on top of the environment.

Environment Complexity	Dataverse Move	Full Project (Apps, Flows, Validation)
Data only, minimal customization	Under 24 hours	1 to 2 weeks
Moderate apps and flows	Under 24 hours	2 to 4 weeks
Heavy customization, Power Pages, Copilot bots	Under 24 hours	4 to 8 weeks
Enterprise, Customer Insights, multiple environments	Under 24 hours per environment	8 to 16 weeks or more

The gap between those two columns is the whole point of this guide. The headline migration speed is fast. The project around it is where the real timeline lives.

What Licensing Does the Destination Tenant Need?

The destination tenant needs Dynamics 365 and Power Platform licenses matching the source environment’s usage before migration, since licensing isn’t transferred automatically and a missing license on even one mapped user will fail validation outright. This is worth confirming well before migration day, not discovered during the validation step.

• Every mapped user needs an assigned license in the destination tenant. Microsoft’s validation explicitly checks for this, and an unlicensed destination user is one of the documented failure points.
• Managed environments need the matching license in the destination. If the source environment had managed environment features enabled, the destination tenant needs the license tier that supports re-enabling that after migration.
• Dataverse storage capacity should be checked ahead of time. The destination tenant’s Dataverse storage allocation needs enough headroom for the incoming environment’s data, a detail that’s easy to overlook when the focus is on user licenses alone.

Running a Dataverse capacity and license audit on the destination tenant as part of pre-migration planning, not as an afterthought once validation starts failing, avoids one of the more frustrating ways this project stalls partway through.

What Should You Validate After Migration Completes?

Before treating a Dynamics 365 tenant migration as finished, confirm the environment is genuinely usable, not just technically present, by working through flows, apps, permissions, and integrations one by one rather than assuming a successful move means a working environment.

• Assign System Administrator roles. Do this immediately for every admin who needs to validate the migration, before anyone panics about an apparently empty environment.
• Re-enable managed environments. If the source environment was a managed environment, it needs to be re-enabled in the destination tenant, and the destination tenant needs the appropriate license for that feature.
• Recreate security groups and reassign roles. Since none of this carries over, rebuilding it is a required step, not an optional cleanup task.
• Re-enable and test every Power Automate flow. Start child flows before parent flows that call them, and update any external references to HTTP-triggered flow URLs.
• Reimport and verify Power Apps. Confirm solution contents match what was exported, and manually reconfigure any connectors, connections, or gateways that didn’t carry over.
• Reprovision Power Pages sites. Match the original portal type and language, since these were deleted rather than migrated.
• Review generative AI and environment-level settings. These reset to default values on the destination side and may need to be reconfigured to match your prior setup.
• Delete the orphaned source environment. Once the destination environment is validated and the data is confirmed no longer needed in the source tenant, clean up the leftover shell environment there.

How Does This Fit Into a Broader Microsoft 365 Tenant Migration?

Dynamics 365 tenant-to-tenant migration runs on its own track, through the Power Platform admin center, separate from the Exchange, SharePoint, OneDrive, and Teams workstreams in a standard Microsoft 365 migration, and the two need to be sequenced deliberately rather than run in isolation.

User identities need to exist in the destination tenant before either migration can succeed, so identity and licensing work comes first regardless of which workload you’re moving. From there, many organizations run the Dataverse migration in parallel with mailbox and file migrations handled by a tool like ShareGate or BitTitan, since they touch entirely different administrative surfaces and rarely block each other. Organizations with heavier identity and coexistence requirements across the whole migration sometimes standardize on a single platform like Quest On Demand Migration for the Microsoft 365 side specifically because of its Active Directory and coexistence depth, while still running the Dynamics 365 move through Microsoft’s native Power Platform tooling, since no third-party tool replaces it for Dataverse itself.

How Does Apps4Rent Help with Dynamics 365 Tenant to Tenant Migration?

Apps4Rent manages the full migration, the native Dataverse move alongside every manual rebuild step Microsoft’s tool leaves to you, so your Dynamics 365 environment is actually functional in the new tenant, not just technically present.

• Pre-migration assessment. Inventorying every Power App, flow, chatbot, and Power Pages site tied to the environment before anything moves.
• User mapping and validation. Building an accurate usermapping.csv and resolving validation errors before they stall the project.
• Sandbox testing. Running a test migration against a sandbox copy first, exactly as Microsoft recommends, to catch issues before production is on the line.
• Full rebuild. Reconnecting flows, reimporting apps and bots, reprovisioning Power Pages sites, and reassigning security roles and groups in the destination tenant.
• Sequencing with your broader migration. Coordinating the Dynamics 365 track against your Exchange, SharePoint, and Teams migration timeline so neither blocks the other.

FAQs About Dynamics 365 Tenant to Tenant Migration

1. Does Microsoft have a native tool for Dynamics 365 tenant-to-tenant migration?

   Yes. Microsoft’s tenant-to-tenant migration feature, available in the Power Platform admin center and through PowerShell, moves a Dataverse environment’s data and schema to another tenant at no additional software cost. The documentation was last updated in September 2026.

2. Does the environment physically move to the new tenant?

   No. The environment stays in place but is unlinked from the source tenant’s Dataverse organization and linked to a new one in the destination tenant. The URL, organization ID, and environment name remain the same.

3. What happens to security groups during a Dynamics 365 tenant migration?

   Security group migration is not supported. Every security group must be recreated and reassigned manually in the destination tenant after migration. Admins not included in the user-mapping file will see what appears to be an empty environment until their System Administrator role is assigned.

4. Do Power Automate flows work immediately after migration?

   No. All imported flows are disabled by default and must be manually re-enabled. HTTP-triggered flows also generate new URLs on import, so any external system calling them needs to be updated.

5. Can Power Pages websites be migrated along with the environment?

   No. Power Pages websites must be deleted from the environment before migration and reprovisioned from scratch in the destination tenant afterward. There is no export-and-reimport path for Power Pages sites in this process.

6. Which Dynamics 365 components are not supported by the native migration tool?

   Dynamics 365 Customer Voice, Omnichannel for Customer Service, and the component library are not supported at all. Customer Insights – Journeys and Customer Insights – Data each require separate migration processes, and Journeys specifically requires a Microsoft support request rather than self-service migration.

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

   The Dataverse environment move itself typically completes within 24 hours once validation succeeds. The full project, including manual rework for apps, flows, and permissions, typically takes 1 to 16 weeks depending on how much customization and how many Power Platform components are built on the environment.

8. Can GCC and commercial cloud Dynamics 365 environments migrate to each other?

   No. Migration between Government Community Cloud and public cloud tenants is not supported in either direction through this tool.

9. Does Apps4Rent handle both the Dynamics 365 and Microsoft 365 sides of a tenant migration?

   Yes. Apps4Rent manages the native Dynamics 365 and Power Platform migration alongside Exchange, SharePoint, OneDrive, and Teams migrations, sequencing both tracks so identity and licensing work supports the whole project rather than each piece running in isolation.