Salesforce Data Migration Guide for Admins

Data Migration into Salesforce can be a minefield. Whether you are migrating from another system or spreadsheets, there is a set of guidelines you could follow to ensure success. 

In this guide, we will look at this from the perspective of an admin tasked with migrating data from one system to another. In this example, we will be migrating into a brand new org and so won’t be doing any updates of existing records.

Key Terms

In this guide, I’ll lean into some terms that you may have not come across before if this is your first Data Migration.

• Source System is the system where the data is being exported/migrated from.
• Target System is the system where the data is being migrated to, in this example it’s Salesforce.
• Source Data is the data that is being migrated from the Source System.

Clean Your Data 

First up you need to connect with your Source Data. Ideally, you’d have the support of a Business Owner to help with any questions about the format, structure, or completeness of the data. 

At this point, you’ll likely be working off a snapshot of the data to work out what needs to be done before it can be migrated. You should ensure each record is unique to avoid duplicates and has an External ID from the Source System so you can match related records when it comes to migration. 

During this stage, you may choose to migrate only active records to reduce the amount of effort involved. Keep a record of decisions so you can keep track. 

Plan Your Data Load

This is when you start to map the data from the Source System to Salesforce Objects. 

Once you’ve identified the objects involved, review the setup to make sure you don’t bump into any issues on the way. 

Use a tool such as Field Dump to create a Data Import Template or a Data Mapping Table. This will highlight any required fields, field types, lengths, and picklist values for you to consider when mapping your Source Data. Be sure to use API Names when inserting against Picklist fields and beware of restricted picklists! 

Don’t forget to take note of any Lookup filters that exist that may make record relationships invalid.

Check for validation rules that your Source Data may not adhere to. Consider if you can clean up the source data to comply or if you can relax the validation rules for these records. You could turn off validations or bypass them, but that’s a bit of a false economy as the first time a user or automation interacts with an invalid record they would get an error once they are back on. The same would apply here in Flow Custom Errors if you decide to leave these active.

Consider if you want automation and apex to run during the migration. If you have an email triggered on a new record, you’d probably want to turn this off during the migration.

Although Fields are required at Page Layout or Lightning Page level, be sure to populate them for the best User Experience. These won’t be enforced during your data migration (unless using the UI) but ensures that when a user first interacts with a record, they don’t have to populate any missing required fields.  

Transform Your Data 

Next up it’s time to transform your data. Your Source System may not have the same data structure as Salesforce so you’d need to adjust the data for it to be in a valid structure.

For example, you may have used Prospects as a Lead Status in your old system but are now moving to Prospecting instead. You can do this using an ETL Tool, Scripts, or manually in Excel. Either way, it’s best to have a record of transformations so you can keep track. 

At this stage, you’ll be close to having a final set of data and will need to plan what you are going to import in which order. It’s always best to start with Users as they may need to be assigned ownership of records across multiple objects. After this, consider loading Accounts and then Contacts so they can be associated with the correct Account. 

At this stage, you’ll still likely be using a snapshot of your current data. Using this snapshot check for possible Data Skew where >10,000 records look up to the same record, >10,000 records look up to the same account, or >10,000 records in the same object with the same owner.

Do a Dry Run

Based on your data volumes, you’ll either want to use a Developer, Developer Pro, Partial Copy, or Full Copy Sandbox to do a test run of a Data Load. 

The Sandbox Licence will determine how much Data and File Storage is available. Data Storage relates to how many records you can have, whereas File Storage relates to the maximum number of attachments/files the system can store. 

*This is based on each record being 2KB/0.002MB, there are some exceptions to this including Person Accounts. The full list of exceptions can be found here.

Prepare the system by turning off any unnecessary automations or apex triggers before you start the migration. Ensure you adjust Deliverability so that automated emails don’t trigger during the migration.  

The time has come for you to pull a fresh data snapshot from your current system(s). Using this data perform any cleaning, validity checks against required fields, etc., and transformations. Once your data and system are ready, import or migrate the data using your chosen tool. 

Post the migration into the sandbox, and review the data to make sure it’s as expected. You can use Salesforce Reports to help you with this as well as List Views, Record Pages, and SOQL Queries. Post migration once you’ve confirmed the expected results start to plan the migration to the Production system. 

Summary

Data Migration can be complicated with many different layers to ensure its success. With this guide, it needn’t be as tricky going forward with a repeatable process to use going forward. Best of luck! 

Resources

• Migrate data from one organization to another
• Best practices when you migrate data
• How to import data into Salesforce – series
• Import related records with an external ID in Data Loader