This blog is an effort to note down the mistakes made and lessons learned after couple of data migrations completed successfully for our clients.
If you are moving from CRM on premise or any platform to CRM Online, you will need to migrate your data.
First, determine which entities are being used and needs to be migrated. The order of migration is important as field(s) of an entity can be related to other entity and used on the entity(s) form.
Some of the points to consider while migration:
To uniquely identify a record in CRM, use the guid of the record Mapping GUID of the source to target helps in identifying records in source & target
- Unique identifier in CRM
Created date of source record can be mapped to overridecreatedon field in target It can only be inserted once, cannot be modified on update of records
- Created On date
Avoid mapping calculated fields to avoid data mismatch during migration. CRM will automatically calculate them on data load of other fields used in calculation
- Calculated fields
There are chances that users in your system who have been deactivated own records, such as activities. For assigning a record to any user, the user must be active So if you have a former employee and you want to import activities and assign them to that user, you will need to temporarily have his user record active in the new system. This means creating records for users who are no longer in the organization You can create users without sending an invitation to that address Assign records to the user and then disable that user record
When importing opportunities, the actualclosedate will be set to today’s date even if you try to load another date to that field. The recommendation is after you update the status of the closed opportunities to Closed, run an update for opportunities updating the actualclosedate to the correct date
Individual activity entities like email, appointment, phone call or task should be migrated individually Initially, keep the status of all activities ‘Open’. Once you update all fields and parties of the activities, close them at the end of the migration since once closed those activities cannot be updated If the owner of the account/contact/lead associated with the activities is updated, it may change the owner of activities. To avoid this, either disable parental to cascading relationship (CRM setting) or do not map the owner of the parent on update Always try to run activities in batches as there can be lots of data if your system is too old
Consider partytypecode and activitytypecode in field properties. If ispartydeleted = -1 that means party associated with the activity is deleted. Hence cannot be migrated If one of the recipients is not in CRM as a contact, account, or user, it will create an activity party not linked to any partyid in CRM. These records cannot be imported Set up your activityparty dts source query to inner join activitypointer to filter out any activityparties linked to an activity that was deleted from the system This will cut the list down and save much time
- Activity parties
Connection roles & Association should be present Select record types ‘All’ (not a specific record type) to avoid mismatch. Connection creates its own connection so there are 2 connection records created while migration. To avoid duplicates, Handle in CRM to delete the duplicates based on connection 1-role 1 & connection 2-role 2 combination
OR Design a package to delete the duplicate records if it is already created once
Keeping these best practices in mind, you can quickly migrate your data in CRM Online.