Data Migration to Salesforce

Photo by Carlos Muza on Unsplash

Here are some steps that you will need to perform a medium to high-level Enterprise data migration from a legacy system. This is a simplified version and will try to keep it technology agnostic as it depends on the client, skills, funding and many other factors.

Data and Infrastructure Assessment

This should be the first step for any migration project. Get a handle on what does the client already have in regards to tools, infrastructure, resources and data policies that can be used to your advantage for a successful migration.

Identify the individuals or data stewards for each object or model.

Assess the data itself in collaboration with the client/stakeholders. Some points to look out for as you assess data: Duplicates, incomplete, unstructured or inconsistent, invalid data, or outdated data.

Categorize these into different types of issues. How to solve them and which issues cannot be solved and needs manual hunting.

Some examples: Missing State, Website on Company/Account or Duplicate rows based on Email- These can be corrected using some tools.

Client-specific data that can't be corrected using external tools will need to be manually found and corrected.

Build these out in the plan and assign owners to each cleansing tasks or set expectations for migrated data.

Inventory

Get an Inventory of all the source objects with the number of rows, last created data and any other relevant data points. Go through this list with identified stakeholders to bucket these into categories:

• Migrate — To be migrated to Salesforce
• Archive — Do not Migrate, but needed to be stored in an external DB for reporting
• Delete — Not needed and can be purged completely

Environment Consideration

• Dev: Dev or Partial copy for test loads of subset of data
• Full Separated Sandbox Env: This is especially important for a big scale project with a large volume dataset. This will help set the foundation of data quality, how long it takes to load per object, what errors you can expect, etc as you perform full loads.
• QA: This is where you want to migrate data to perform System Integration Testing(SIT)
• UAT: Another full sandbox for end-user testing. This is closest to prod, ideally, all the data issues would have been resolved when you migrate to UAT
• Production

Migration Filter Criteria

Make recommendations based on the data analysis — ideally, only migrate data that someone will interact in the new environment and the data adds a business value. Less is more here.

• For eg: For leads, migrate only recent leads, or actively engaged leads. Similarly for Opportunity, it probably makes sense to only migrate recent closed lost and not all closed lost, etc. Of course, you want to migrate all Active records, accounts, contacts, cases, etc. Only migrate data that adds some business value or is needed in the system.
• If you only want to migrate data for reporting, rely on other tools like Einstein, Tableau or Qlik, etc which lets you run reports on data not necessarily present in Salesforce

Mapping Objects and Fields

This is more than likely the most time-consuming exercise rather than the actual migration build itself

• First, create a high-level object-level mapping for the to be migrated objects, eg; Lead maps to Lead, Customer maps to Account, etc
• Then create a field-level mapping for each object in a logical manner based on which projects are being built first, etc
• Get sign-off from the business in writing so you have something to track back to. This is super important from an auditing, QA and Project Management perspective.

Build

This is where you actually start your migration process. Depending on the size and complexity of your project, you will follow one of the following approaches:

Source System => Staging DB => (insert a tool like Boomi) => Target SF

Source System => ETL Tool => Target Salesforce

Source System => csv files => Dataloader => Target Salesforce

Data Validation

It is super important to get a sign off on migrated Data from Data Stewards and Business. Just like any other project where you have testing and signoff, Data migration is no different, the only difference is in the process and mechanism of validation itself. If are following along, you already have Migration Filter criteria and mapping documented which will serve as something data stewards can refer back to while validating. Like any other project, expect changes and bugs in this step for few times. Sometimes you will get new mapping requests now that people are actually looking at the data, so always plan ahead for the time.

Note that Data Validation for accuracy of migrated data is different from Integration or Functional testing on migrated data.

Reload as Needed

This is an extension of the Validation step. Any bugs or Mapping issues need to be fixed in files, jobs, etc and reloaded or updated depending upon the scenario. Add new mapping requests as needed, but remember to not over-promise as this is where you need to assess the initial requirement, bugs and enhancement request.

Planning/Coordination

This is something you will be doing throughout the project as you get more information on objects, field mapping and order of execution, not just within Salesforce but also any external systems involved. For eg: there might be an external system that needs Salesforce ID, so they can perform their loads.this needs to be planned and added to the steps of execution so you can repeat these steps in all environments as needed.

Think holistically about all the systems involved and migrations occurring in all systems and how are they interrelated and steps to follow.

As you perform loads in different environments, you will have documented the timing each load took, errors and resolution, and the pre-steps and post-steps performed in all Systems for a successful migration. This will help build the timeline for production migration planning.

Other things to consider:

Is there a blackout period?

Is data being created in the source system as migration is happening?

How do you plan for delta migration?

Does it need to happen over a weekend if you get a system downtime or can it wait until after go-live?

Please share anything that you have experienced in your project. This is just a skeleton list and it is very unique to your projects and scenarios. I hope this helps you point in the right direction as a guideline.