Salesforce Data Migration Checklist: 10 Steps and Rollback
Tim Combridge
September 27, 2026
.png)
Most Salesforce data migrations that go wrong fail on the same few things: no backup of the target org, no way to link child records to their parents, and no plan for undoing a bad load. Use this checklist before you start, then read the numbered sections below for detail on each step.
Account.Industry. Note required fields, picklist values, record types and record owners.Legacy_Id__c, on every object you load and fill it with the source system's ID. It lets you upsert instead of insert, link child records to parents, and re-run a load without duplicates.Product2 and PricebookEntry first, then Account, Contact, Opportunity, OpportunityLineItem, then Task, Event and files.YYYY-MM-DD, 18-digit IDs), and split combined rows into separate objects.CreatedDate values.CreatedDate or LastModifiedDate window), how you'll undo them, and who makes the call.Before kicking off your migration you need to understand exactly what data you are migrating, including its structure, format, relationships, and dependencies. Clearly define why your business needs to perform the Salesforce data import and set a clear scope of work.
This comes first because it sets boundaries and defines the project before you get too deep into the work itself. This clarity helps prevent scope creep, which reduces the risk of timeline and budget overruns. It also helps to set clear success metrics at this point so the business can accurately gauge if the Salesforce data import project was successful.
If both systems are Salesforce, see Salesforce to Salesforce data migration. Moving between Salesforce products has its own scope questions. See CPQ to Revenue Cloud data migration.
Not every Salesforce data import goes to plan. Your business should expect problems and get into the habit of preparing for and avoiding them in advance.
This is why you should create both a Migration Plan (a plan for what you are looking to achieve) and a Rollback Plan (a plan for what you will do if the Migration Plan doesn't roll out as expected). This way, no matter what happens, your business remains in control of the situation. For the rollback side, see how to roll back a failed Salesforce import.
You already have a starting template for your Migration Plan: this checklist. You can use the guidance in this article to structure the Migration Plan for your Salesforce data import project.
Your business's data is among its most important assets. Given that the next steps involve assessing your data and making changes to it, you need to create a backup of your data in its original state.
Backing up your data means you have an original copy of it for use at any time throughout the Salesforce data import process. Whether you perform a bad data cleanse, the format of your data is changed and damages its accuracy, or a de-duplication or merge goes wrong, your data is still safe.
You should not only include the data that is going into Salesforce in your backup but also the data that is currently in Salesforce. The whole point of an import is usually so that your data is connected together, so if there is an issue with the imported data it may spill over into your existing data. If something goes wrong, both your new and existing data sets are still available for clean up or restoration.
Part of the first step in this checklist was to define your Salesforce data import and understand exactly what is going to be included, where it is going, and the format it needs to be in to go there. This step focuses on the detail: you will need to map each field from your source Excel or CSV sheet to the object and field it needs to be stored in once it is imported to Salesforce.
You should carefully consider what the data structure of your new records should be in the destination Salesforce environment. Source systems often don't have the same relational structure as Salesforce and combine objects together. For example, some data sets include Account, Contact, and Activity data together in a single record. You should transform this data (more on that later) to follow Salesforce best practices and make use of the relationships between records in Salesforce. Don't just map and migrate your data exactly as it was in the source platform, or you won't realise any value in migrating it.
Add an External ID field such as Legacy_Id__c to each object and fill it with the source ID. When you load Contact, you can then set Account through the parent's Legacy_Id__c instead of looking up Salesforce IDs. If you do need to match on Salesforce IDs in a spreadsheet, use 18-digit IDs.
Load in dependency order: parents first, then children, then activities and files.
There are numerous options when it comes to Salesforce data import tools. Choose based on the data you are migrating, how much transformation is required, where the data is coming from or going to, whether it is a one-off or recurring data migration, and your budget. You can compare options in best Salesforce migration tools.
Consider not only the current need but also the needs your business may have in the future. Free tools typically don't offer features such as automation and integration. If you do choose a free tool, consider one with paid add-ons you can use later without moving to a completely different tool.
One option is Dataimporter, which you can try for free. It handles one-off or automated Salesforce data imports and direct Salesforce to Salesforce migrations. For CSV and Excel loads, it works as a Salesforce data import tool, and it connects directly to sources such as Google Drive, OneDrive, SharePoint, Dropbox and Google Sheets.
You may not need all of these features, and there may be other options you prefer, but you need to know exactly what your Salesforce data import tool needs to be capable of before starting your migration project.
Your Salesforce data integrity should be protected. You didn't invest all this time, effort, and money to have your data compromised by a poor Salesforce data import. Cleanse your data thoroughly and bring it up to standard before it comes into contact with your Salesforce org.
This cleansing may be standardising phone number formats, address data, or date formats (YYYY-MM-DD). It may be making sure certain fields contain data, or splitting a single record across multiple objects as mentioned above. It could be deduplicating your data, or comparing your new data to your existing Salesforce data and making sure records are being updated, not duplicated, by the new data.
Data transformation means converting data from one format into another to meet specific requirements. Here, it means reshaping the data for your Salesforce data import so it fits properly within the Salesforce data model. Along with cleansing, it is essential for data quality and compatibility with existing Salesforce data and functionality.
A Salesforce data import isn't just about moving data from another system into Salesforce. You need to make sure that once the data has been imported it works with existing functions and automation in the system, and is accessible to users as expected.
Allow enough time for testing before the actual data migration. If you run into issues, you may need a second round of testing before continuing to your main data import. If you skip this step and something goes wrong you may miss a go-live date, or worse, create dirty, incorrect, and corrupt data.
The best way to do this is by creating a test plan and migrating a sample subset of your data into a sandbox for sanity checking. Your test plan should summarise what you've done to date (the scope, how you cleansed and transformed the data, and your data mapping) as well as how you will gauge the success or failure of your Salesforce data import. This typically includes a series of user stories that can be used for testing immediately after the data is migrated.
A sample migration is as simple as it sounds: take a small slice of your data, run your end-to-end migration, then measure the outcome. Test the migrated data against your user stories to make sure everything has gone to plan. Address any issues before the full Salesforce data import into production. If you need realistic test records in the sandbox first, see sandbox seeding.
People in your business will want to be kept up to date with the status of your Salesforce data import. They care about the data itself and how it impacts their business-as-usual operations, but not necessarily the technical side of your migration.
They will want to know when they can begin working with the data, and to be kept in the loop about any significant changes to that timeline. They will also want to know what major changes, if any, there are to their day-to-day work or the functionality of the system.
Be upfront about any setbacks or delays, and explain what you are doing to fix them.
Keep your messaging relevant. Highlight the parts of the Salesforce data import project that matter most to each team and tailor the messaging accordingly.
This step is often overlooked. Record every step taken along the Salesforce data import path, including any configuration changes required to support the new data (such as new objects or fields), any changes to security, and any settings or features that were changed or enabled.
Also document any issues that occurred during the migration, as they may affect future imports or integrations. Once you have found a resolution, you can reapply it if the issue comes up again.
This documentation will be the first place to look for troubleshooting if there are problems with the new data later. If this is a recurring migration, your documentation will act as a playbook for future data imports that follow the same structure.
Where the last point was about documenting the steps taken, this point focuses on the data itself and what happens to it during the migration. Use logging to track the progress of your migration.
Logging is usually built into the migration tool and often exported as CSV files. These logs show the success or failure of each record and point you towards any anomalies.
As you continue to monitor your data you will likely run into some errors, either during your Salesforce data import or during business as usual. Some errors are easy to read, and others are harder to decipher. You can read one of our previous posts to learn more about the most common errors you may run into during a Salesforce data migration.
Here are the Dataimporter features that map to steps in the checklist above.
Test data sampling. Dataimporter has a built-in data sampling tool that lets you load a random number of sample records to test your job before running it on the whole data set. After setting your object and field mapping, tick Take Sample of Data and set your Sample Size.
After the job runs, View Successful shows the random sample that was loaded. In this example, 100 test Leads were in the source file and a random selection was imported.
Migration rollback. The success screen has a Rollback button that deletes the records an insert job created, including sample loads. You confirm on a second screen. Rollback is available for 7 days after the job completes.
Data seeding. The seeding tool creates realistic sandbox data of different types, such as names, sentences and financial values, and can pick from picklist values. You set the number of records and can use Masks to control formatting. It shows a preview of three records before inserting.
Template formulas. Formulas let you build new field values from multiple source columns inside the job, instead of in Excel. They work much like Salesforce and Excel formulas; see the help page for the full list of functions.
Record deduplication. On the Clean page of a job, tick Deduplicate Rows and choose the fields that identify a duplicate.
Scheduling. Recurring loads can run on a schedule. Schedules can be configured for jobs that use an external data source (see integrations).
Third-party integrations. Dataimporter connects to sources such as Google Drive, Google Sheets, OneDrive, SharePoint, Azure SQL and Dropbox without code. The Integrations page has the current list.
What order should I load Salesforce objects in?
Parents before children. A common order is users and reference data (Product2, Pricebook2, PricebookEntry), then Account, Contact, Opportunity, OpportunityLineItem, then Case, Task, Event and files. If two objects point at each other, load one without the lookup, then update it after the other is in.
Do I need a sandbox for a Salesforce data migration?
Yes, for the sample load. A Developer or Developer Pro sandbox (200 MB and 1 GB of data storage) is usually enough for a representative sample. For a full dress rehearsal with production volumes, use a Partial Copy or Full sandbox.
Why use external IDs in a data migration?
An External ID field holds the record's ID from the old system. It lets you upsert, so re-running a load updates records instead of duplicating them, and lets you link child records to parents without first looking up the new Salesforce IDs.
How do I roll back a Salesforce data migration?
For inserted records, delete the records the job created using its success file or external IDs. For updated records, you need their values from before the job, which is why you back up the target org first. Plan this before cutover, not after. See how to roll back a failed Salesforce import.
Every Salesforce data migration is different, so adapt these steps to your project. Regular communication with stakeholders and a flexible approach matter as much as the technical steps.
If you have questions about migrating or integrating your Salesforce data, get in touch, or browse the Help Center.
