Salesforce data migration is one of the most challenging projects, and will differ depending on the size, format, and accuracy of the source data. Data migration is the process of transferring data from one system to another, however, the work required before the actual transfer is the most complex part.
Professionals have spent time thinking about what makes data migration successful. There are three general phases that you should follow: preparation, migration, and quality assurance (UAT).
Phase 1: Preparation
Let’s put emphasis on preparation – the most critical phase.
David Masri’s book, Developing Data Migrations and Integrations with Salesforce: Patterns and Best Practices, calls out six attributes to good data migration – the ‘why’ behind the best practices. Failure to meet any of the other five attributes can be mitigated by preparation, but nothing can mitigate a bad plan – or worse, no plan.
So, what does good planning look like?
Your migration plan should look like a traditional project plan, with timelines, dependencies, and milestones.
Your project manager (PM) is your friend and ally – work with them to build the plan. You are the Salesforce specialist, and they will take care of tracking your progress as the migration commences.
When the time comes to start coding the migration of a particular object:
- The Salesforce build is complete for that object.
- You have received the data from your stakeholders.
- It has been deployed to your target environment.
- You have enough time to analyze and code all the transformations.
For quality assurance (QA) and user acceptance testing (UAT), and production migration runs, ensure the dates land on days that you can dedicate the time needed for the jobs to run.
Questions to ask yourself and discuss with the wider project team:
- When will the data to be migrated be delivered (by the legacy system owners)?
- What format will the data be delivered in?
- Who is the source data subject matter expert (SME)?
- Are there any data security concerns or guidelines for handling the data?
- What middleware or ETL tool will you use for your migration?
- How much time is required for data analysis?
- How clean is the data? Is a data cleanup wise, and if so, who is responsible, when will it be done, and in what system?
- When will the data mapping document be completed, and who is responsible for creating it?
- When will you review the data mapping document with your stakeholders?
- What Salesforce environment will be used for quality assurance (QA), User acceptance testing (UAT), and the migration to production? If the target Salesforce org is currently being built out, when will the various objects be available so that you can load data to them?
- When will you perform the first complete end-to-end run of the migration?
- Who will be performing QA / UAT? How many rounds for each?
- When do you go live?
- How much time do you have for the production cut over? (This could result in downtime for users where they’re not able to use the legacy system or Salesforce.)
Identify the data to migrate and the source of truth of that data.
The processes you have built in Salesforce will influence selection. When analyzing the data you need to migrate to Salesforce, you may also realize that you need to build additional objects and processes. Data migration, therefore, can become a ‘chicken-and-egg’ situation.
The source of truth is typically the backend – where customer transactions are stored. However, not all business data is backend. For example, communication during the sales process could happen on calls, over emails, etc.
Focus on identifying which data is gathered by which team, and what’s relevant to store in Salesforce:
- Sales: As mentioned, communication during the sales process could happen on calls, over emails, etc.
- Service: Where are service agents processing service cases? If sales and service teams don’t work on the same system, you will need to match accounts to service cases.
- Marketing: Notorious for using multiple data sources, marketing teams will need attention. How are pre-qualified leads captured – do they enter into Salesforce as leads, and at which stage of the prospect lifecycle? Do they use customer data too (e.g. for upsell and renewal campaigns)? Are there considerations for how consent is indicated?
- Finance: How does invoicing and revenue recognition work?
It’s likely that you are going to have multiple data sources (i.e. different sources of truth for different data categories). Outline which data to migrate and where to extract it from:
Ensure all records of each source system have a unique Identifier (ID).
If any of the data categories in one source system are related to another data point in another system, the ID of the related data point is required. For example, if you are planning to migrate backend customer data and also import past contract information from the previous CRM, every contract record is required to have a customer ID (from the backend).
- Get metadata samples from the source system/s to see how data is structured – every field and table needs to be included in this sample.
- Map tables, fields, and values in the source system/s to Salesforce objects, fields, and values.
The more different your Salesforce data model data structures in the source systems, the more complex the data mapping process will be.
When will the data mapping document be completed, and who is responsible for creating it? When will you review the data mapping document with your stakeholders? These are all important questions to ask.
If IDs are not in place, you will need to perform data cleansing.
Remove duplicates and outdated accounts from the dataset. Help from users will be required here as they should be able to fill in missing IDs and indicate which data they want to keep. Establish who is responsible, when will it be done, and in what system.
Phase 2: Migration
The method you choose to transfer data from the source system/s to your Salesforce org will depend on:
- The project team members you are working with (e.g. developer, admin).
- The volume of records you need to import into Salesforce.
- The complexity of the source data, and how different the source data model and the Salesforce data model are.
Phase 3: Quality Assurance (UAT)
What Salesforce environment will be used for quality assurance (QA), user acceptance testing (UAT), and the migration to production?
Once data has been migrated to Salesforce, you will need to ensure that all data has been transferred correctly, i.e. in the right format, and that relationships are reflected accurately in Salesforce.
Remember, for QA, UAT, and production migration runs, ensure the dates land on days that you can dedicate the time needed for the jobs to run. UAT testers are often performing UAT in addition to their day job. You can’t expect them to spend four hours a day testing, every day, for two weeks. Understand their schedule and ensure that they understand the commitment required.
Ask users to test for intent during UAT, in this context, we mean the business goals. It’s common for code (including data migrations) to meet the technical specified requirements, but completely miss the ball with regard to business intent.
If the tests are not successful, find out which phase caused the errors. If errors were a result of the preparation phase, you will need to iterate the whole process. Unfortunately, defects are a time-consuming process. Once logged, they are likely to require a meeting to confirm the issue is real, and what should be done about it. Therefore, you should plan for users to have enough time to thoroughly test the data.
As mentioned at the start, Salesforce data migration is one of the most challenging projects you will face, and it will differ depending on the size, format, and accuracy of the source data.
This guide has given you an overview of Salesforce data migration phases – what good planning looks like, essential questions to ask, and the risks involved that makes your project manager a valuable ally.
For in-depth advice, David Masri’s book, Developing Data Migrations and Integrations with Salesforce: Patterns and Best Practices, is a good place to head. Masri calls out six attributes to good data migration – the ‘why’ behind the best practices. Failure to meet any of the other five attributes can be mitigated by preparation, but nothing can mitigate a bad plan – or worse, no plan at all.