In Part 1 of this post, I enumerated all the SFDC field data types and how they map to Dynamics CRM field data types. I also provided the level of complexity for each type of mapping and some hints about how to implement the SFDC concepts/features into Dynamics CRM so a data migration can take place.
In the table below, I will go a little deeper and provide further details about the implementation workaround that will be necessary in order to migrate some of the SFDC field data types:
|SFDC Data Type||Dynamics CRM Implementation Workaround|
|Auto Number||Dynamics CRM auto-numbering feature is only available for some OOB entities (Contracts, Cases, Articles, Quotes, Orders, Invoices, Campaigns, Categories and Knowledge Articles). In case you want to migrate Cases from SFDC to Dynamics CRM, you will not be able map the SFDC auto number field to the Dynamics CRM Case number (auto-number) field one and keep the SFDC value. The platform will not let this happen and will always create its own auto number.
What if you are required to migrate objects which the Dynamics CRM counterpart does not support auto-numbering?
What if you are required keeping the SFDC number?
Well, there are many options here:
1) Create a custom auto-numbering solution leveraging a new sequence/auto-number entity as well as synchronous/real-time workflows.
2) Create a custom auto-numbering solution using transactional plugins.
3) Create a custom solution that leverages Auto-numbering web services
4) Use a 3rd party tool
My fellow CRM colleague Salim Adamon provided here a list of some of the available resources for each of these options.
Once you chose and implemented the Dynamics CRM solution that best fits your needs, you can now proceed with the data migration and bring over your SFDC auto-numbering values for the different entities.
|External Lookup Relationship||There is no equivalent feature in Dynamics CRM. In order to display the external data, you need to implement an Integration with the external system.|
|Geolocation||Geolocation data type in SFDC is a compound field that counts toward the org’s limits as three custom fields: one for latitude, one for longitude, and one for internal use.
You can think of creating two fields of Decimal data type in Dynamics CRM corresponding to the SFDC Longitude and Latitude fields so you can eventually migrate this kind of data.
|Indirect Lookup Relationship||There is no equivalent feature in Dynamics CRM. In order to display the external data, you need to implement an Integration with the external system.|
|Picklist (Multi-select)||There is no equivalent to this feature in Dynamics CRM and you will need to design and implement a custom solution in Dynamics CRM.
Note that the Salesforce Picklist fields displays each value separated by a semicolon.
Let us discuss how you can possibly implement multi-select picklists.
You can design your solution around the concept of N:N Relationships in Dynamics CRM:
1) Using a grid of associated records that represent the picklist values. Note that by configuring security, you need to make sure that users other than admins will not have the right to add/update/remove values in the grid.
2) A custom solution where each picklist value from SFDC will correspond to a Dynamics CRM custom field of type Two Options with the Checkbox format.
You will need to implement some custom code that will maintain the relationships between the parent record and the associated records.
3) A custom solution where you have a custom web resource designed so you can check different values.
You will need to implement some custom code (similar to what I described in the 2nd option) that will maintain the relationships between the parent record and the associated records.
Once you chose and implemented the Dynamics CRM solution that best fits your needs, you can now proceed with the data migration procedure.
|Text (Encrypted)||In this post, I talk about the encryption approach in both Dynamics CRM and SFDC platforms
Now, in order to migrate encrypted SFDC data corresponding to the Dynamics CRM default entity attributes containing sensitive information (e.g. Email, Password), you will need to:
1) Decrypt the data
2) Migrate the data into the Dynamics CRM platform which will take care of encrypting/decrypting that data whenever it’s saved or retrieved.
For other encrypted SFDC fields, you will have to:
1) Decrypt the data
2) Take a decision on either keep the data in clear text or implement a mechanism (through a custom solution) to encryption/decryption of specific data in Dynamics CRM
3) Migrate the data into the target Dynamics CRM organization
|Text Area (Rich)||An SFDC rich text area presents the user with a WYSIWYG editing area. The aim is to reduce the effort for users trying to express their formatting directly as valid HTML markup. Creating rich text fields is not a native capability in Dynamics CRM but there are few free ISV solutions you can leverage to easily and quickly enable it such as TinyMCE or CKEditor.|
This is probably not an exhaustive list of solutions/workarounds. There are tons of other resources that are just few clicks away so remember that Google is your best friend 😉