Salesforce Data Migration: A Step-by-Step Checklist

Data migration is the part of a Salesforce project that people tend to plan last and worry about most. It's easy to see why. Configuration can be changed after go-live. Data that arrives wrong (duplicated, unlinked or missing its history) is expensive to fix once people have started working on top of it.

The good news is that a migration is very predictable when it's run as its own workstream, with its own plan, rehearsals and sign-off. This checklist walks through that plan in order.

1. Decide what you're actually moving

Not everything in the old system deserves a place in Salesforce. Before mapping a single field, agree on:

• Which objects move. Customers, contacts, open deals and active cases usually do. Ten-year-old closed records might not.
• How much history. "All of it" is rarely the right answer. Agree a cut-off, such as open records plus the last two or three years of closed ones, and decide where older history will live (an archive, a report export, or the legacy system in read-only mode).
• What "done" means. Write down how the migrated data will be checked and who signs it off. This becomes your reconciliation plan in step 7.

2. Map every source field to a destination

Build a mapping document, usually a spreadsheet, with one row per source field:

Mapping forces the hard questions early: which values become picklist entries, which fields are no longer needed, and which old codes no one can explain. If a field can't be mapped to a clear purpose, that's a strong sign it shouldn't be migrated.

3. Clean the data before it moves

Cleaning data in a spreadsheet before the load is far cheaper than cleaning it in Salesforce afterwards.

• Remove duplicates in the source, and agree on which record wins when two conflict.
• Standardize values: states, countries, phone formats and picklist values.
• Fill required fields or agree on defaults.
• Fix owners. Every record needs an active owner in Salesforce. Decide what happens to records owned by people who have left.

4. Give every record an external ID

Add an External ID field on each object you load and fill it with the record's ID from the old system. This one step makes everything after it easier:

• Relationships can be rebuilt. A Contact can point to its Account using the old account number instead of a Salesforce ID you don't know yet.
• Loads can be repeated safely. Using upsert with the external ID updates existing records instead of creating duplicates if a load has to be re-run.
• Records can be traced. Anyone can match a Salesforce record back to its source during reconciliation.

5. Load in the right order

Records that others depend on have to exist first. A typical order is:

1. Users (and roles)
2. Accounts
3. Contacts
4. Products and price books
5. Opportunities, then opportunity products
6. Cases and other transactional records
7. Activities, notes and files

Two settings are worth deciding up front:

• Automation during the load. Flows, validation rules and assignment rules will fire on every record you insert. That can send emails to customers or block valid historical data. A common pattern is a "bypass" custom permission that automation checks, assigned only to the user running the migration.
• Original dates. If created dates and owners should match the old system, Salesforce can allow audit fields to be set on insert once the "Set Audit Fields upon Record Creation" permission is enabled. Decide this before the first load, because it can't be applied afterwards.

6. Rehearse in a sandbox, more than once

Run the full migration in a sandbox before production, ideally twice:

• The first run finds mapping errors, missing values and records that fail validation.
• The second run proves the fixes work and tells you how long the real load takes, which you need for cutover planning.

Keep a log of every error and how it was resolved. The production load should hold no surprises.

7. Reconcile before anyone relies on the data

After each load, check the result against the source:

• Record counts per object match (minus anything intentionally excluded).
• Totals match, such as the sum of open opportunity amounts or the number of open cases per status.
• Relationships are intact: contacts sit under the right accounts, opportunities have the right products.
• Spot checks by the people who know the data: ten records each, compared side by side with the old system.

Only when the business owner signs off does the migrated data become "live."

8. Plan the cutover

The last step is the switch itself:

• Freeze changes in the old system at an agreed time, then run the final load.
• Run the delta. If the old system can't be frozen, plan a small second load for records changed during the migration window.
• Re-enable automation and confirm it behaves as expected.
• Keep the old system read-only for an agreed period so people can check history while confidence builds.

Common mistakes to avoid

• Treating migration as a task at the end of the project instead of a workstream from the start.
• Loading everything "just in case" and inheriting years of duplicates.
• Skipping the external ID and rebuilding relationships by hand.
• Leaving automation on during the load and emailing every customer at once.
• Going live without a signed-off reconciliation.

Planning a migration?

Data migration is part of how CRM360 approaches Salesforce projects: mapped, cleansed, rehearsed in a sandbox and reconciled before anyone depends on it. If you're moving to Salesforce or consolidating systems, see how we handle data migration, or request a consultation to talk through your project.