How to Migrate Sales Data from One Salesforce Instance to Another

Step 0: Make Sure You Actually Want a Single Salesforce Instance

Before you go down this path, remember that it’s not the only option.

Many organizations choose to have multiple instances of Salesforce for different parts of the business. Keeping things separate can potentially yield more flexibility and help to enforce clearer interface boundaries between business units or corporate sub-divisions. The secret weapon for making this work is “Salesforce to Salesforce”, a first-party tool which allows you to synchronize data between Salesforce instances.

So before you move on, think this through. What’s the better approach for your organization: One big Salesforce instance or multiple little ones? If “one big Salesforce instance” is the answer, then read on.

Step 1: Determine the Scope of Your Migration

How much data will you be migrating exactly? This is the first and most important question to ask. And once you have an answer, make sure you have buy-in from all of your key stakeholders. You don’t want to get to the eleventh hour and discover that you’ve left out something critical.

It’s best to think of this along three axes.

Axis 1 — Which objects?

The more objects you attempt to migrate, the more complex the project will be. Each additional object will require you to ensure referential integrity across the entire migration set while also potentially de-duping with existing records in the system.

Remember that record ids are non-editable in Salesforce, so post-migration all of the record ids will be different. This means that every lookup field on every object will need to be re-mapped.

Mandatory Sales Objects: Leads, Accounts, Contacts, Opportunities, Activities (Only those linked to migrated records)
Recommended Sales Objects: Products, Pricebooks, Pricebook Entries, Opportunity Products, Opportunity Contact Roles
Potential Marketing Objects: Campaigns, Campaign Members
Potential Other Objects: Quotes + Child Objects, Orders + Child Objects, AppExchange Package Custom Objects, Org-Specific Custom Objects

Axis 2 — Which fields?

Every object in Salesforce has a set of Standard Fields and supports the creation of up to 500 custom fields (or more in some cases). Every field you choose to migrate will need to be created in the new system and, if it’s a lookup field, will need to be re-mapped to maintain referential integrity.

In some cases you may want to map custom fields from the source system to existing custom fields in the target system. If those fields are picklists you will want to decide whether to update the target picklist values or to map the source values to the existing target values.

Once you’ve got a list of the field migration strategy for each object, you will want to get buy-in from stakeholders before continuing forward.

Axis 3 — Which records?

Finally, for each object you’ll need to understand how many of the records you’ll be migrating. It’s always easiest to migrate all records since filtering the records requires more work to ensure referential integrity across the whole set. But sometimes you’ll need to filter based on record types or other fields.

Step 2: Double-Check AppExchange Packages

This is a step many folks forget to do. Before you get too far into your project, ask your stakeholders whether there are any mission-critical AppExchange packages in the source system which are missing from the target system. If so you may need to update your project plan to include the procuring and installation of the apps and the migration of any app-specific settings and data.

Step 3: Map & Match the Sales Workflows

In most Salesforce instances, things start as Lead records then convert into Account, Contact & Opportunity records upon sales qualification. But the devil is in the details. You’ll need to get into the weeds of the Sales workflows in both the source & target systems to figure out how everything will be mapped.

Here are some key questions to address:

What are the source Lead/Opportunity Processes (collections of Lead Status/Opportunity Stage values)? Do you want to standardize these by changing them to match the target Lead/Opportunity Processes or keep them separate?
What are the source Lead/Opportunity Record Types and how will those map to the target Lead/Opportunity Record Types?
When do Leads convert into Opportunities in both systems? (If the thresholds are different you may need to “rewind” or “fast forward” some Leads/Opportunities during migration.)
Are there any critical automated processes which fire at certain parts of the sales workflow which will need to be ported during the migration?
Are there any custom/standard fields which are required at certain stages in the sales workflow?

Step 4: Determine Your Unique Identifiers for Companies & People

One of the key areas that can cause user frustration post-migration is duplicate data (particularly for Accounts, Contacts & Leads). Data quality tools like RingLead and Cloudingo can help you automatically fix dupes post-migration, but if you don’t have those tools you’ll need to handle de-duping yourself. And even if you do have a data quality tool, you’ll still need to take some time to inspect your settings and make sure they will work for your incoming data set.

There is no single strategy that works for all orgs, but here’s what I usually recommend as a starting point:

Accounts: Web domains are the easiest thing to use to as a unique company identifier. Be careful if trying to use company names! Company names are tricky to turn into readily matchable hashes and they are not actually unique in most company’s data sets. For reference, I’ve written another article here which explores how to use web domains as unique company identifiers.
Contacts: Email addresses are the obvious and most common choice as a unique identifier for people, but be sure to ignore capitalization when de-duping. There are those rare companies which have case-sensitive email addresses, but most differences are simply due to user input behavior.
Leads: Same as Contacts, emails are best. But remember that for lead records, it is often considered acceptable to have multiple leads with the same email as long as there is no more that one “active” lead per email. And, depending on your org structure, you may want to support up to one “active” lead per email per Lead Record Type.

Step 5: Map Record Ownership & User Lookups

In Salesforce, every record has an “Owner” user which controls visibility, permissions and often drives critical workflows like performance management and commissions. For some objects the Owner will be critical to maintain accurately (Opportunities & Leads for instance), while for other objects it can be safely ignored during migration.

It’s important to identify up-front which objects have Owners which need to be maintained and which do not. You’ll also want to identify any important User Lookup fields across your entire migration data set.

Once you have a list of all the Owner & User Lookup fields which need to be maintained you’ll want to export a full list of the source system values for those fields. This will give you a full list of source User records which either need to be migrated to the target system or which will need to be mapped to a fallback User.

Step 6: Choose a Migration Toolbox

After completing the above steps you should have a good basic plan for how you’re going to map the source data to the target system. The next step is figuring out which toolbox you’ll be doing to actually perform the migration.

This wouldn’t be Salesforce if there weren’t a veritable cornucopia of options. Exploring them all would be its own article, but here’s a high-level overview:

Salesforce Data Loader / Import Wizard / Developer Workbench: These three options are fairly interchangeable and are all free. They represent the most traditional, legacy approach. Utilizing these tools will involve exporting the source data to spreadsheets, then doing a carefully sequenced series of imports into the target system, capturing the record ids after each one and using vlookups to maintain referential integrity for each and every lookup field.
Salesforce CLI Tree Export/Import: Another free option, this is a bit of an upgrade from the traditional spreadsheet based tools. Salesforce’s CLI lets you export entire trees of records to JSON files then import them into another instance. The downside is that the tool breaks down a bit with super large data sets. And if you want to export multiple trees or de-dupe, you’ll have to manually edit the JSON files.
Salesforce Data Move Utility (SFDMU): This is my favorite of the free options. It uses the Salesforce CLI under the hood but handles all the heavy lifting for you. It also struggles with super large data sets but there are workarounds if you Google them. Note that this is a CLI tool, but there is a GUI available here.
Paid Tools: There are so many options that I couldn’t possible summarize them here. Google “Salesforce data migration tools” and you’ll find a plethora of ads and top 10 lists. Be wary that many of the tools out there are basically just paid versions of the free tools above which offer limited additional functionality, particularly for a large scale migration work. Focus on tools specifically designed for prod-to-prod migration for Salesforce specifically.

Step 7: Do a Migration Dry Run

It’s always best to test out your process before you begin your final go live plan. The first step is to do a dry run where you use your chosen toolbox to export all — or a limited sample — of your source data and actually walk through the steps needed to prep it for import into the target system.

As you do this dry run you may identify some flaws in your migration strategy which require updating your plan and re-aligning with your stakeholders.

Step 8: Test Everything in a Sandbox

Once you get your dry run migration files ready, the next step is to create a sandbox environment in your target Salesforce instance. Ideally this would be a full sandbox, but a partial copy is ok too. Other types of sandboxes will be workable, but the less data you start out with the more work you’ll have to do to create an accurate simulation of the eventual production outcome. And depending on the size of your data set you may hit some limits with certain sandbox types.

The goal is to do a full test of importing the source data into your target sandbox. Then you want to have your stakeholders inspect the sandbox in detail to identify any last minute tweaks to the plan. These can be things like page layouts, permissions, automations, validation rules, broken reports, missing fields or corrupted field values.

Step 9: Plan for the Transition

This is the most complicated part and is different for every org, so I won’t say much here beyond this: Make sure that you have a detailed rollout strategy that has the full buy-in of all of your stakeholders.

Your plan should, at a minimum, include the following:

End-user communications strategy
Detailed migration checklists
A clearly defined transition window, including specific cutoff times where people will be locked out of the source system and go-live times where migration will be complete in the target system
Reports in the target system for tracking migration progress
Post migration checklists for inspecting the data and quickly identifying any errors
Post migration support strategy: Where do users go for help if they encounter errors?

Step 10: Go Live!

This is the big day. Since you will likely be locking folks out of the source system (and potentially the target system as well) you will want to move as quickly as possible. It’s common to do these sorts of things over a weekend, but it is possible to get it done in a single evening if you must.

Ideally you’ll want to have at least two or three people in the core working group helping to share responsibilities and check each others’ work. Then you’ll also want to have a larger group of stakeholders on call and ready to quickly verify the work once it’s complete.

The big thing you want to avoid is going live with mistakes in your migrated data. Things get exponentially more difficult if you discover days or weeks later that you made some critical errors during migration. If this happens you will have to re-do some portion of your migration work with the additional complexity of being careful not to overwrite anything that has been changed or added in the intervening time. Plus you’ll need to communicate every step of your fix-up work to a bunch of frustrated users.

Do it right the first time and you’ll be saving yourself a world of pain.

As I mentioned at the outset, CRM data migrations are always complicated and there are a thousand ways for things to go terribly, terribly wrong. The best plan for problem prevention is always proper preparation.

Hopefully this outline was a helpful starting point.

Do you see anything missing? Want to share how you’re tackling an SFDC data migration project? Message me on LinkedIn and let me know what you think!

In addition to being a co-founder of Quorum1, Hank is a serial entrepreneur and long-time Salesforce consultant. You can learn more about his work on his personal website.