Data migration is when data is moved from one place to another. In many projects, the data is moved from a legacy system to a current and updated system.
There are three main parts of a data migration process, and they are:
Figure 1: Source Link
- Understanding the data
- Understanding the data source
- Understanding the data destination
For Dynamics 365, it is very important that we understand the source and destination very well, especially if the source is coming from different countries and different source systems. Every business user wants their data to be migrated in the same way as it is in the legacy system, for ease of use, training, and understanding of the new technology. In this blog, we will share the “Do and Don’ts” for an enterprise level data migration project.
First, we must identify the correct technology to migrate the data. Most use technologies such as Kingsway Soft and SSIS instead of free tools such as Talend, Mulesoft – for which there is less support.
For such open source technologies:
Figure 2: Source Link
- Source and Target should be well defined. We must identify different sources and possible duplicates for various systems that might use different technologies but have the same data.
- There will be instances when the same data should go into different entities with different statuses.
Figure 3: Source Dilbert Cartoon, Google
- For lookup values, we must create a master list and map all the possible source values in that list. Providing multiple files for each system will lead to confusion and re-work.
- All countries and data owners must provide the master data and agree to use the data globally.
- Identify the entities which allow active and inactive records migration in single step. For example:
- We can migrate inactive accounts and associate child records to the inactive accounts.
- We must migrate all activities as active records. We cannot create a canceled appointment in single step. We might have to create a scheduled appointment and then add an additional step for updating the appointments. We can call this a two-step process.
- For a two-step process, we must also migrate the child records, if any, before updating the statecode for the parent.
- Statecode and Statuscode must be included for all entities for migration, even if there is only one active status for the entity.
- Statecode and Statuscode are hierarchical. Hence, it must be used together.
- If we use only statecode, default statuscode is applied by Dynamics 365, which might not be correct according to the data.
- If we use only statuscode, Dynamics 365 might throw an error. For example: if we assign statuscode as active and inactive and not include statecode, Dynamics 365 assigns an active statecode by default. In such cases, inactive statuscode will throw an error because of a hierarchical relationship.
- The main purpose of the project is laying a 360o picture to understand the needs of the business. Creating a migration script without understanding the needs of the project will create incorrect data migration.
- Involving the key stakeholders in each step and engaging them effectively is equally important to understanding the data, system, and mapping lookup values.
- Integration between technologies and teams is necessary to understand the duplicates in the data and source systems.
With this, if we can introduce a concept for requirement inspection, we might encounter several issues during the initial phase of the project. We might be able to identify the missing pieces in the data migration during the requirement phase and save cost for the project in later stages.
For more guides to Dynamics 365, check out our blog
Happy Dynamics 365’ing!