Recently, I had an rare opportunity to do a tenant to tenant Dynamics 365/Microsoft 365 migration for a public sector customer. To begin with the process seems to be a bit complicated in the beginning without any not clear guidelines in any Dynamics 365 community. The most closest information I came across on this topic from community blog posts was on how to get Microsoft support involved early in the process, but nothing regarding a checklist /sequence to follow to mitigate any risks while going live in the new office/Dynamics 365 tenant. So, I summarized my personal experience with observations/checklist points I followed in the migration project which might be helpful to community members.
Disclaimer: This is not an official guide/only right way to do the Dynamics 365 tenant to tenant migration. The circumstances and needs can vary for each situation.
Initiating the Process
The entire process of migrating a Dynamics 365 (Dataverse environment components) is carried by Microsoft support. The process of getting support team involved is very simple and can be done by raising a support ticket from Power Platform admin center as shown below.
Once you have a support engineer assigned to perform the migration, they will ask you to perform the following steps.
- Create a user mapping file which maps user from old office 365 tenant (Dataverse users) to new office 365 tenant (Dataverse users). Tip: make sure all the users that own any Dynamics 365 records (powerapps and connections used in any flows) are part of this mapping file and licensed in the destination environment. In case some users who own Dataverse records or connections in flows are not going part of the new Dataverse environment as licensed users, map these users to any other licensed admin user for the destination Dataverse environment.
- Create a full copy of current production environment (in source / old Dataverse tenant) in a sandbox environment. In addition create a sandbox environment in the new Dataverse/ destination environment. Microsoft support will use these two dataverse environments to do test migration later in the process.
2. Performing Test Migration
3. Migrating DataVerse Apps
Our support engineer told use that any apps (canvas and model driven) will not be migrated as part of Dataverse environment migration and needed to be migrated manually. In practice what we found that the PowerApps were migrated in the migration process. It is always wise to keep a back up from the source dev (unmanaged) dataverse environment.
4. Migrating PowerAutomate Flows
5. Migrating PowerApps Portal
The standard migration migrates the entire Dynamics 365 backend database, hence it migrates also all the customizations and settings for the PowerApps portal. The portal management app will also be migrated.
Tip #1: In actual migration of production dataverse environment you will need to reset the PowerApps Portal in the old(source) Dataverse tenant otherwise you will not able to re-create the portal in the new dataverse tenant.
Tip #2: If you are using any custom Azure B2C solution for an external authentication provider for the portal, then this needs to be reconfigured once gain for your solution, which means recreating Azure B2C client and re-configuring B2C provider.
6. Migrating Dataverse Security Groups and Application Users
If you are using Azure AD security groups in source environment to control access to Dynamics 365 apps (dataverse), you will need to recreate the Azure AD security group and link with the migrated Dynamics 365 environment.
The applications users records are migrated as the entire dataverse database is migrated, however you wont be able these as the link between registered apps under Azure active directory will be broken. The easiest way to solve this is to re-create app registrations under new active directory and create new application users that might be used in any custom integration solution.
7. Migrating Azure Infrastructure and Custom Code
8. Queues and User Mail boxes
The domain of the Office 365 tenant changes during the migration, hence email addresses of group mailboxes and user email addresses. In my scenario, I had to re activate mailboxes of users and queues (re-approve and re-activate).
9. Other Integrated Microsoft Products
In my scenario, the customer did not had any integrations with Sharepoint. I assume here, since the Sharepoint location need to be reconfigured and some automated tool/custom code to migrate the documents from old Dynamics 365 document location to the new Sharepoint site in new Office 365 tenant.
If you / your organization needs assistance for a Dynamics 365 tenant to tenant migration project, please don’t hesitate to contact me at email@example.com / +4746726207.