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:
- Unique identifier in CRM
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
- Created On date
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
- Calculated fields
Avoid mapping calculated fields to avoid data mismatch during migration. CRM will automatically calculate them on data load of other fields used in calculation
- Users
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
- Opportunities
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
- Activities
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
- Activity parties
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
- Connections
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.
