In this article I will describe process of migration Dataverse database from one tenant to another. You can do this in several ways:
- By support ticket in Microsoft
- With the DataMigrationUtility In this article I will describe the second approach and the difficulties which are related with this process.
Migration process consists of several stages:
- Source Dataverse backup.
- New environment configuration
- Solution migration
- Data migration
Use DataMigrationUtility from SDK for data backup. I used version from 2021 year, because there is no user mapping template in the import process in last version of utility. First of all, you need to export data scheme from source database. Don’t select all entities in the list, because it could take too much time for export and import and will be too complicated to resolve all issues in data migration. My process took 4 hours for export and 24 hours for data import. Don’t forget about sharepointlocations if you have SharePoint integration in the system. SharePoint migration is another big issue and we won’t cover it in this article.
In the second stage, export the data using schema from the previous stage.
All errors you can find in the log files.
It is important to have the same licenses in the target tenant. When it is done, create new environment with the same base currency and language as the source environment. Turn on and configure SharePoint integration if you have it. If you have sandboxes, create their copies too.
Now it is time to migrate solutions. If you have sandboxes first of all you need to migrate unmanaged solutions there and then migrate managed solutions from new sandbox to the new production environment.
Basic solutions import
Since your environment may depend on some third-party solutions, you first need to import them, for example PluginProfiler.Solution or woodford. It is important to find exactly the versions that you have installed in the source environment. After each import of the solution, don’t forget to publish the changes!
Import of custom solutions
IMPORTANT! Each type of environment has its own type of solutions - for the production Managed, for the test Unmanaged. In my case I had error with dependencies from msdyn_VivaSalesCore. To fix it I unzipped solution, removed dependent section and zipped it back.
Disable plugins and workflows
In my case I had problems with accounts addresses processing, so I disabled several plugins.
Use PluginRegistration tool to disable plugins steps.
Disable Microsoft.Dynamics.FieldService account steps:
Create (pre-operation) for account
Update (pre-operation) for account
Check whether you have workflows which you need to disable during import process.
In order to avoid errors when importing backup data, you must first correct some data in the backup archive data.zip, made by the DataMigrationUtility utility.
Removing the parent_contactid attribute. In my case I had problems with parent_contactid when I tried to import data. To fix this issue you need to unzip data.zip file, remove parent_contactid field from data_schema.xml and zip it back to archive.
<field displayname="Parent Contact (Manager)" name="parent_contactid" type="entityreference" lookupType="contact" customfield="true" />
Money data delimiter issue
During the testing, it turned out that some data is incorrectly recognized in terms of delimiters. To fix this problem, a special tool was written to correct the delimiters.
Execution commаnd example
FixCrmXmlFile.exe --zipfilename data.zip
data.zip – data file path. At the end tool will create another archive with fixed delimiters data-fixed-2022-09-13-22-18.zip.
Currency codes fixing
If the currencies in the new environment were not created during the import process, then their code will be different from the currency codes in the original environment. In order for all data to be connected to the correct currencies, it is necessary to see in the data.xml file what currency identifiers were in the old environment. Check for the
<entity name="transactioncurrency" displayname="Currency">
element, write down the old identifiers Check new identifiers in target environments.
Replace old identifies in data.xml file
Change business process flows priority
If you have custom business process flows, you need to change their priority to set them up as default process.
Now you can start DataMigrationUtility.exe to import the data.
Fill in the user mapping file and use it later during data import.
Turning on plugins and workflows
Enable disabled plugins and workflows. Change worfkflow senders and enable them.
SharePoint document locations configuration
Set up entity parent sites in the list of document locations.
Email template migration
I used XrmToolbox to migrate templates. First, we connect to the current CRM system as template sources
Then we connect to the target environment, select all the templates and transfer them.
As you can see, the migration process can be very complicated, even with the tools recommended by Microsoft for this purpose.
comments powered by Disqus