Beringer is striving to create real value in our customers' CRM systems. We enjoy developing creative solutions for Microsoft Dynamics CRM systems. We regularly are tasked with producing Migrations and Integrations to Microsoft Dynamics CRM from other applications as a data source. Yet, recently I was challenged to migrate data from one CRM Online system to another. Typically for CRM Online, a copy of the Database can be recreated through the CRM Online Portal using the Copy feature. Our client however only required a filtered subset of data to be migrated. This calls for a custom migration between the two CRM systems. In creating that migration, I wanted to share some of the design choices I made.
Creating the Migration Field Mapping
Since I was working with two CRM systems, the field mapping became a one-to-one match between source and destination fields. Our migration tool of choice at Beringer is Scribe Online, which makes field mapping a breeze with an Auto Link feature.
For more information, click here to read another great Beringer Blog on using Scribe Online for data migrations:
Creating the Entity References
I was also able to use an important feature of the Dynamics CRM API to reuse GUIDs between the two systems. The GUID in CRM is the unique identifier for a record. It is used on an entity to identify itself, as well as references to other entities via lookups and relationships.
For example, I can feed the GUID in the Account Id field on the source Account to the Account Id field on the Destination record I am about to create. This assigns the same Source GUID to the newly created Account in the Destination system.
This will ensure that when I create other records referencing this account, I know exactly which record with which to create a relationship. For instance, when I create the Contacts in my next step, I can reference the related Account using the same GUID from the Source system
This saves me from having to do a lookup for the Account GUID in the Destination system since the Account Id is already attached to the Contact in the Source system. This reuse of information saves me a service call to the CRM API, which saves the Migration job time on each record. That time can really add up when you are importing hundreds of thousands of records to CRM.
To save even more time, the CRM API also offers Bulk Request support. Luckily Scribe has also made this available, so I can create multiple entities with just one call to the CRM API. CRM handles the rest
In short, I was able to exploit a native piece of the Microsoft Dynamics CRM API to reuse Unique Identifier information from the Source System and reduce the amount of operations that had to be done during the Migration. I was also able to perform these operations in Bulk rather than making a new service call for each operation. These features of the Microsoft Dynamics CRM API made for an efficient way to push data from one CRM system to another, and Scribe Online made the integration incredibly easy to build.
For more information on Scribe Online and the Microsoft Dynamics CRM SDK, please see the links below:
Thanks for reading!
Beringer is always here to provide expert knowledge in topics like these and has deep experience integrating data. Can we help migrate you to Microsoft Dynamics CRM? Please reach out to us today.