One of the most important parts of a migration is getting the current data to the new system as efficiently as possible. To do that, preparation is key — the more you do, the more likely you will be successful in this endeavor. Below are some tips to help prepare for your
How much data do you need to migrate?
The first thing to determine is what entities are most important and how many records in each need to be transferred. Do you have an extensive list of entities with a large number of records that need to be transferred? Or is it mostly just the basics with small number of records?
Data governance is key. Data costs money to maintain and holding on to low-value historical data can negatively impact your business.
What tools should you use to migrate data to Dynamics 365?
If you are just bringing over the basics, the Dynamics 365 for Customer Engagement (D365 CE) data import wizard will likely do the trick. If you have more complex data with a large number of records, then a third-party software package such as Scribe or Kingswaysoft would be better suited for the job. LogicApps or Flow may also be suitable tools for your needs. If you are just going from an on-prem environment to a cloud environment, then a purpose-built migration tool such as Cobalt may be the best choice.
How clean is the data?
Migrating to a new system is a great opportunity to evaluate the cleanliness of your data. Are there a lot of duplicates? Is the information outdated? Is there obsolete data?
If you have duplicates, determine what makes for a duplicate in each entity and note any associated entities affected. Also, note how many duplicates you have. If the number is small, the duplicates can be handled by the built-in Dynamics 365 merge functionality. If there are many duplicates, a third party tool may be best.
If you find the data could use a cleanup, you need to determine if it would be better to do this while the data is still in the old system or wait until it is in the new system.
How will security work?
Now is the time to determine how security is going to work in the new system. If everything is going to be owned by a single team, document the name of that team. Yet, it is more likely that you will require a security matrix. This would provide mapping between how the data is owned in the old system and how the data will be owned in the new system.
Another thing to consider is how to handle ex-employees and their ownership of records. You can address this one of two ways. The first option is to map all previous employees to a generic user in the new system. This method is simple, but the downfall is that you will lose old information. To limit the loss of this data, create a text field to hold the previous employee’s name in the new system.
Another way to handle ex-employees' records is to create all previous employees in the new system and then disable them once the migration is complete. This will preserve the information, but has licensing implications and it can be time-consuming to create the ex-employees.
What fields will be transferred?
At this time, you should create your migration documentation, data mappings, etc.
There are two field types that deserve special consideration when you are documenting your data migration to Dynamics 365. These are pick-lists and look-ups.
Migrating picklist fields in Dynamics 365
To transfer your picklist fields, first determine if all values are the same between the old system and the new system. If they are not, create a translation table to show the value in the old system and what value it should map to in the new system.
Migrating lookups in Dynamics 365
The same thing should be done for lookups. Look-ups pose special challenges because the referenced record has to exist in order to create the link for the record being imported. This can play an important role in the order in which you import records.
Utilizing the SourceCRM fields in Dynamics 365
You should also create preservation fields for your Dynamics 365 data migration. These preservation fields are usually called SourceCRM and <Abbreviation of Source System Name> ID. These fields will allow for you to know where the data came from long after the migration is complete and provide a link for the record to its source field. Preservation fields also allow the person migrating the data to easily create associations with the legacy records.