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
