Measure Twice – Cut Once

Salesforce Data Migration

I was recently asked, “How long should a simple data migration take from a legacy CRM system to Salesforce?” The answer is that there is no magic number that quantifies how long a data migration will take between systems (simple or complex). Not the ideal answer but it got me thinking. Even though a defined timetable for data migration is hard to nail down, there are some things that can be done to help ensure a successful data migration.

Let’s start with a few assumptions surrounding what we are dealing with when considering the question that prompted this post:

1. Simple CRM System – In my experience a ‘simple’ CRM system consists of; Users, Accounts, Contacts, Opportunities, Tasks / Events /History
2. The source CRM system leverages a relational database (SQL Server for example). If the backend database is not relational it is assumed that a third-party tool will be used to extract the source data. Depending on the source system and extraction tool used you may be able to stage the extracted data in a relational fashion upon data extract.
3. The Salesforce API is available for inserting / updating / deleting data into Salesforce.
4. The Salesforce org being migrated to is a newly implemented org

Now that the assumptions are put in place let’s move on to the framework of how a data migration effort should be approached:

HAVE THE BUSINESS PROCESS / NEEDS DEFINED BEFORE DATA WORK COMMENCES

Remember, data and supporting technology are meant to serve the business and not the other way around. Business alignment will directly impact data and how it is staged for migration. How? Here are some examples:

• Data Security: Which Salesforce users will own the records to be migrated? That decision affects how the role hierarchy is configured (maps the right owner to the right record).
• Reporting: What reports are expected to be generated from Salesforce? This answer dictates the data elements essential for migration.
• Data Quality: Do data elements need to be transformed to meet reporting and record level requirements? Another important element to consider surrounding data quality is will the resulting migration create duplicate data…garbage in – garbage out.

With business requirements in place we now can start to dive into how to proceed in migrating data.

DATA MIGRATION TOOLS

There are a few tools that I consistently use in data migration projects. One is a relational database that is used in building the model that stages the data according to the business requirements. SQL Server or Access does the trick here. The second tool is a conduit that can link the staged data to Salesforce. Salesforce Data Loader as well as Jitterbit Data Loader fills the gap here.

ITERATIVE MIGRATION APPROACH

Similar to developing custom functionality in Salesforce, follow an iterative approach when developing and proving the data migration model and its results. Note, make sure to form a team of end users to help test and validate the migration iterations. For a simple data migration, I usually perform two test data migration iterations. The iteration framework looks something like this:

Build data model in a relational database ‘middle ware’ reflecting requirements-> stage data -> migrate data (test) -> review results with project stakeholders -> modify data model based on feedback -> purge migrated data -> migrate data (test) -> review results with project stakeholders -> assuming all is well purge migrated data -> migrate data (production)

This approach drastically decreases any ‘data surprises’ being the data has been reviewed in Salesforce (at least twice) well before the production migration.

A FEW BEST PRACTICES TO CONSIDER

• Always include a LegacyID on each migrated record. A LegacyID is simply a text field that reflects the records legacy database unique id. The LegacyID provides ‘reverse data integrity’ between Salesforce.com and the legacy CRM system which makes post-production data updates possible.
• Ensure side effect functionality is disabled in Salesforce.com OR said functionality is fully understood if enabled when migrating data. Examples of functionality that can cause side effects when migrating data into Salesforce.com are:

Workflow: Workflows set to fire on record creation tied to field updates or email messaging can prove to be troublesome

Triggers: Similar to workflows, triggers tied to the object being migrated set to fire on record insert could cause issues

Validation Rules: If validation rules tied to the object being migrated are active and the data migrated do not meet the criteria the record insert will fail…that can be a pain

• Have Salesforce enable the ability to update audit fields. This affords the ability to set the migrated records Create Date field to be the date that the record was originally created in the legacy system. More often than not the business will want the original record create dates reflected in the target system.
• Provide data mapping documentation. Always document your data mappings / transformations / logic / expected record counts resulting from migration.

Again, there is no magic number that sums up how long an entire data migration process will entail.Variables such as the number of users being migrated, the cleanliness of the source data, and the effort needed to transform the source data to meet business processes will all impact the time needed to migrate data. To help ensure a successful and smooth data migration take the aforementioned variables into consideration and apply them to a data migration framework tied with best practices so that you get the production migration right the first time.

Written by Kevin Johnson, Lead Architect/Sr. CRM Advisor

With more than twenty years of experience Kevin is highly skilled in enterprise software implementations, system integrations, identification of business requirements, team leadership, and project management. As a Lead Architect and Sr. CRM Advisor at Demand Chain, Kevin is responsible for all aspects of new and existing client engagements including: pre-sales engineering, strategy creation, requirement gathering, process engineering, system design and integration, testing, data migration, training and go-live support.

by