In this blog post, here's my to-do items in details as a migration guide ! This blog provides an overview of my white paper "My How-To guide to a successful data migration with Dynamics 365".
Introduction: How to define our migration context ?
Emphasizing the technical aspect of an option, what does it mean regarding the platform Dynamics CRM or Dynamics 365?
A data migration focuses on the movement of data between source (legacy data system and business) and destination (target system). However, pitfalls related to the CRM data context are real and can delay the data migration: data related to security model, data related to shared data, data model related to denormalization, data logs and audit and finally, data volume.
Even with the most thoroughly tested tools and procedures, we need to ask ourselves how to orchestrate a data migration, mainly from database to database and finally, a data model.
Problem: How to orchestrate the data model ?
Here is the opportunity to orchestrate a data migration code related to Dynamics 365. So, we need to have a guide helping us to develop the right, accurate and structured code regarding the data model.
The questions raised by this problem could be challenging: How to group the entity model? What is the sequence of execution? How to prioritize the entities? How to exclude the unnecessary entities to migrate? Our guide could help to organize and structure the data migration and in so doing, we could establish the right requirements to fulfill.
Requirements related to the orchestration
First, we need to create 3 databases: a « source » database (Dynamics 365); a « target » database (Dynamics 365) and finally, a « tool » database we could call « CRM Tool ». Each one has to be prepared (see p.8).
Secondly, we need to defin our strategies and actions related to grouping, prioritizing and excludind entities during the process (see p.8).
Data preparation: What to do before data orchestration ?
In order to accuratly prepare our data, we need to fulfill several steps : start our data preparation, initialize our reccurrent variables, prepare the data related to the CRM security model and finally, end the data preparation (see p.10).
Once our data is prepared, we can start the process of data migration and execute the migration into 8 steps:
Wave 0 - Data Orchestration of the Core Model
The first step could be completed into several sequencies: sequence 1 related to the followings entities ("owner", "currency"), etc. (see p.12-13).
Wave 1 - Data Orchestration of the Product Model
The second step could be completed into one sequence related to the followings entities ("product", "price level", etc.) (see p.15).
Wave 2 - Data Orchestration of the Customer Model
The third step could be completed into several sequencies: sequence related to the followings entities ("contact", "contact address"), etc. (see p.17).
Wave 3 - Data Orchestration of the Core Business Model
The fourth step could be completed into several sequencies: sequence related to the followings entities ("opportunity", "lead", etc.) (see p.19).
Wave 4 - Data Orchestration of the Activity Model
The fourth step could be completed into several sequencies: sequence related to the followings entities ("attachment", etc.) (see p.21).
Wave 5 - Data Orchestration of the System Process Model
Dynamics 365 has an internal process related to a data model: this CRM internal services store data after execution. The fifth step could be completed into one sequence related to the followings entities ("audit", "principal object access", etc.) (see p.23).
Wave 6 - Data Orchestration of other custom/system business data model
Because of the relationships between the entities, logical and mainly physical relationships, we could orchestrate a more or less important number of entities (custom and system). The sixth step could be completed into several sequencies: sequence related to the followings entities ("resource", "account leads", etc.) (see p.25).
Wave 7 - After Data Model Orchestration
The last wave is only related to the administration of the database.
Conclusion
Between each wave, we could integrate a validation process in order to validate the migration of the data. This validation process could be composed of 2 successive sub-processes: one process related to the deployment (letter A) and a second process related to functional tests (letter B).
If the deployment or the functional tests do not succeed, the wave has to be fixed before moving forward. The reasons of the failure could be the followings:
Data or records that have been migrated are the source of the error.
Strategy related to the grouping, the ordering or the prioritizing has to be considered.
If we need more information or details, please do not hesitate to contact the author (Thierry Sinassamy - thierry.sinassamy@dataobjectexception.com). Regards.