Migrating into Salesforce !

Data Migration (into Salesforce)

It’s been sometime I got any topic to blog about... finally, today made firm mind to write my understanding and opinion around data migration (from Legacy CRM into Salesforce), hope you find it informative and adoptable.

Data migration projects are generally effort intensive & demands meticulous planning and control, there needs to be SME from both legacy CRM and Salesforce side who understand not only the functionality but have thorough understanding of data model of each systems.

Where and how to start?

1. Aligned Data migration timeline with that of E2E overall project plan.

2. Understand when the existing legacy CRM licenses are going to expire

3. Discuss with the stakeholders around when they want the migrated Salesforce data to be available for user testing

4. Discuss and decided data volumes, dates when the legacy CRM can be freeze, the attachments volumes to be loaded, etc.

Ideally, starting with a data migration plan and Strategy is recommended.

Strategy should go to good amount of details such as 

Exact scope of data migration, Volumes, Dates of imp milestones, Tools being used, Out-of-scope, The migration approach, Environments that will be used for migration, whether it’s big-bang migration or not,  How many rounds of testing will be performed, RACI matrix, Assumptions, dependencies, testing approach, etc.

From Salesforce perspective, the proven and stable migration approach would be as depicted below:

Legacy CRM   -->    Staging Area (with two data model)    --> Salesforce

Staging area can typically have two data model created (one which reflects the entities and relationships as per Legacy CRM) and (another which reflects the entities and relationships of Salesforce CRM)

Use the Staging area to apply Cleansing, De-Duplication, Enrichment, transformation and other business and archival rules and load the records into Staging area (SFDC data model).  This way, the final CSV file which is generated from Staging area (SFDC data model) will be nearly identical or perfectly ready for Salesforce team to upload using any data loader tools

On legacy CRM - One can use Sql loader or other tool based on the type of database (Oracle, MS, and IBM)

On SFDC CRM - if data volume is low - one can use Data Import wizard, Apex Data loader, Jitter bit, dataloader.io, Informatica data wizard, and many more.

Below is a SFDC suggested order of migrating the entities:

0. Users

1.  Accounts

2.  Campaigns

3.  Contacts

4.Opportunities

5.  Cases

6.  Solutions

7.  Price books

8.  Products

9.  Leads

10.Contracts

However the Order of above entities might change from one project to another depending on the existing relationship in legacy CRM but overall the order is as given above.

Some more tips:

§  As you move in additional data into your Salesforce instance, keep a watch on the space you are consuming. In case you are reaching your permitted space limits, it is time to call your Salesforce representative to purchase additional space

§  It is important to plan out the data migration. The users should be informed well in advance about the cut-off date, and possible issues that may happen. Also it is always a good idea to have a few pilot users available to test over the weekend in which a major data migration is planned.

§  It is also import to do sanity testing directly in Salesforce. Login as different types of users, and view a few records of different objects. Compare these same records manually with the original system. Although many tools are available, there is no replacement to manual verification when testing data migration

§  From a developer perspective it is important to plan/provide sufficient time for testing the results of data migration before you roll out the instance to users. Just because the data loader has executed without any errors does not mean that the migration is complete. Use the Developer console to perform basic queries like – total number of accounts of a certain record type, number of accounts without any contacts, number of accounts owned by user XYZ etc.

§  You need to evaluate if all the workflows and triggers of the impacted objects should be disabled before uploading data. Often there are active workflows that send emails to customers when certain stage is reached

§  It is easier to remove duplicates from a spreadsheet than merging them in Salesforce.

§  Use the Excel Connector or Apex Data Loader and V-lookup to compare new records against existing records before importing. 

§  Lookup Relationship-– > By Changing settings to “Clear the value of the field”

§  Master-Detail Relationship –> Sort Salesforce or External ID by ASC or DESC order to prevent record locking

§  Map the External Id for future traceability

§  For reports and dashboards to work on Salesforce just the way they did on legacy CRM, it’s a good idea to enable the Audit fields in Salesforce where CREATED BY and CREATED DATE system fields can be edited via data loader during migration, this way the Created by user on Salesforce for the records will be exactly same as the one in your legacy CRM.  This will help in your OWD, Sharing rules to work seamlessly even after migration.

THANK YOU -- TJ