3 Tips for Making Smoother Dynamics 365 data migration | Dynamics 365 migration
Dealing with duplicate data:
Many tools like Scribe Insight have functionality that can help you handle duplicate data, but regardless of the available feature in your migration tool, issues will arise when using those tools to dedupe data during Dynamics 365 data migration. In many cases, it is better to utilize the deduping tools available in Microsoft CRM, rather than relying on your Dynamics 365 migration jobs to clean the data. An added bonus is most clients respond well when you use this situation to offer practical training on CRM.
Also Read: HUBSPOT CRM REVIEW
Unless you have clean source data, any de-duping logic you build into your Dynamics 365 data migration jobs will result in one of the following:
You will have duplicates that cannot be addressed by the migration job’s strict de-duping rules that will need to be discussed in CRM post-Dynamics 365 migration.
You will merge records that may be similar but are not really duplicates, based on more lax de-duping rules. Additionally, this situation will likely cause quite a few issues when importing related records.
Example:
You have 2 duplicate account records in your source data, each with multiple activities related to them. If you import them into CRM as one record, it becomes difficult to assign all of the activities to the one remaining account when you migrate the associated activities. The difficulty lies in the fact that typically when de-duping the accounts during the Dynamics 365 data migration before they reach CRM, you lose the key field for the record that was merged. When you attempt to import related documents, the key-value they were associated with does not exist in CRM.
Often it is a quicker process to import the duplicates and then import the activities based on the key fields. With CRM tools like duplicate detection reporting, advanced find, mass editing capabilities, and the merge tool, managing duplicates in CRM will be much easier and more accurate through CRM. Since most duplicate records are not exact duplicates, many records will need to be reviewed, and a human decision will need to be made before they can be merged. This is a great time to train the client and allow them to assign deduping tasks to multiple users. This will enable clients to become familiar with CRM tools while cleaning their data.
While it may seem backward to import the data to CRM and then clean it, often a client’s legacy system lacks the tools Dynamics CRM has. Deduping in this fashion will save a lot of time as well as provide a valuable user training experience in CRM.
Additionally, if you try to dedupe the data with your Dynamics 365 data migration jobs only, you will always have the lowest common denominator for determining what constitutes a duplicate record. You will find duplicate files with misspellings, slightly different addresses, incorrect zip codes, etc. that will fall outside of your criteria and will need to be managed in CRM regardless of your best efforts.
Know your source data:
An essential first step is to review your source data and estimate the number of records in each of your migrations. If a large number of source records exist, it is essential to determine the impact on your migration timeline. Knowing the volume of data may make a big difference in the planning and design of your Dynamics 365 data migration jobs.
Example:
You have 50,000 Account records you want to import into CRM in one evening. After the account records are imported, you have 150,000 related activities to import. You estimate your full account import job will take 6 hours to run through the CRM API. You estimate event activities will take you 12 additional hours to run for a total of 18 hours. This will not leave you much time for validation and leaves very little if any, margin for error.
Solution:
Create a shell migration package that simply creates a new Account record with nothing more than the Account Number field (key field). This allows you to run the Account integration in a fraction of the time, possibly minutes instead of hours, and upon completion will enable you to come back and update the accounts with the full Dynamics 365 migration job at the same time you are migrating activities. Using a tool like Scribe Insight will allow you to run all of your employment at the same time with multiple threading.
Understand structural differences on a functional level:
It’s essential to know the structure of your data sources and how the structure differs from Dynamics CRM before you begin migration/integration planning. It is necessary to understand how the data was used in your cause, not just how it will be used in CRM moving forward. Often you will need to convert the source data structure to fit the structure of CRM. It’s essential to fully realize how the processes inside your source data work because, in most integrations, it’s not as simple as matching the process via CRM customizations.
Often phone numbers, email, notes are stored in relational tables but may appear on the main form in a legacy system as a single field (think CRM address field functionality on a customer record).
In some data sources what looks like a set drop-down list may be editable by the user without any required normalization. Looking through the legacy application, you may see a drop-down with 5 values, but in the source data, you may find you have 500 distinct values that users have entered over the years.
Taking time to learn the system the client is used and having a good functional knowledge of how the source data was entered and maintained can be invaluable for determining potential challenges before the Dynamics 365 migration.
Example:
Your legacy system has phone numbers and emails in relational tables. CRM has fields on Contact records for Business Number, Mobile Number, Fax Number.
Looking at a few sample records, it may appear your legacy system has a phone type of “Business”, “Mobile” and “Fax”. Although it may seem like a comfortable fit, it is essential to review the source data to verify if any Contact records have more than one “Business”, “Mobile” or “Fax” type phone number associated with them. Many legacy systems set up this way allow the same type to be used for multiple names. You will need to determine if this is something that has to be accounted for in CRM or cleaned up in the legacy system before you start the Dynamics 365 data migration.
While there are many factors to consider during Dynamics 365 migration, hopefully, this blog will get you thinking ahead when it comes to planning, de-duping, and migrating your data to CRM.
1 Comments
Good Article, Thank you!
ReplyDelete