Key takeaways
- Most migration problems are data problems, not tool problems. Clean and deduplicate before you load.
- Load in dependency order and keep the legacy system’s IDs in an external ID field on every object.
- Use the Data Import Wizard for small, simple loads and Data Loader or the Bulk API for larger or more complex ones.
- Rehearse the full migration in a sandbox at least once before the production cutover.
Moving into Salesforce, whether from spreadsheets, another CRM or an older Salesforce org, is one of the riskiest parts of any implementation. A clean migration means users trust the system from day one. A messy one creates duplicates, orphaned records and months of clean-up. This checklist is the process we follow on client projects.
1. Define the scope
Decide what is moving and what is not. Not every record deserves a place in the new system. Agree on cut-off dates for historical activity, which objects are in scope, and whether closed or inactive records should be archived elsewhere instead of migrated.
2. Inventory your sources
List every source system, export format and owner. Note record counts per object. Volumes drive tool choice and timelines, and a surprise extra million activity records is better discovered now than during cutover.
3. Design the target data model first
Mapping only works once the Salesforce data model is settled: objects, record types, required fields, picklist values and relationships. Migrating into a model that is still changing causes repeated reloads.
4. Build a field-level mapping document
For every target field, record the source field, transformation rules, default values and picklist mappings. This document becomes the contract between business owners and the migration team, and it is invaluable when someone later asks where a value came from.
5. Cleanse and deduplicate the source data
- Standardize formats for phone numbers, states, countries and dates.
- Merge duplicate companies and contacts before loading, not after.
- Fix or flag records missing values that will be required in Salesforce.
- Retire obsolete picklist values and map them to current ones.
6. Add external ID fields
Create an external ID field on each target object to hold the legacy system’s record ID. External IDs let you upsert records safely, relate child records to parents without looking up Salesforce IDs, and rerun loads without creating duplicates.
7. Choose the right tool
| Tool | Best for | Notes |
|---|---|---|
| Data Import Wizard | Simple loads of up to 50,000 records at a time | Browser-based, supports common standard objects and custom objects, built-in duplicate matching for some objects |
| Data Loader | Larger loads, up to 5 million records | Desktop and command-line tool, supports all objects, insert, update, upsert, delete and export |
| Bulk API 2.0 | Very large or automated loads | Used by Data Loader and ETL tools, processes records asynchronously in batches |
| ETL or middleware | Complex transformations and repeated syncs | Useful when migration logic is heavy or the source system stays live during transition |
8. Load in dependency order
Parents must exist before children. A typical order is users, then accounts, contacts, opportunities and their line items, cases, and finally activities, notes and files. Map record owners to active Salesforce users, and decide what happens to records owned by people who have left.
9. Handle automation and validation during loads
Flows, triggers, validation rules and duplicate rules exist to protect data entry by people. During a migration they can slow loads, send unwanted emails or reject legitimate historical data. Plan how each one behaves during the load, for example with a bypass setting checked by your automation, rather than deactivating everything and hoping to remember what to switch back on.
10. Preserve history where it matters
Audit fields such as Created Date and Created By can be set on insert if the Set Audit Fields upon Record Creation permission is enabled, which keeps reporting on historical data meaningful. Decide early whether you need this, because it must be applied during the initial insert.
11. Rehearse in a sandbox and validate
Run the full migration in a sandbox with production-like data. Validate record counts per object, spot-check records against the source, run key reports with business users, and time the load so you know how long the production cutover will take.
12. Plan the cutover and the day after
- Freeze changes in the old system, take a final export and run the delta load.
- Keep the old system read-only for an agreed period in case of questions.
- Have the migration team available on the first days of go-live to fix issues quickly.
- Archive the mapping document, scripts and load logs for future reference.
Moving from one Salesforce org to another? Pay extra attention to record IDs, owner mapping, files and email history, which do not transfer cleanly between orgs without planning.
Frequently asked questions
How long does a Salesforce data migration take?
Small migrations from spreadsheets can take days. Migrations from complex systems with years of history, many objects and heavy cleansing typically take several weeks, mostly spent on mapping, cleansing and testing rather than loading.
Should we clean data before or after migrating?
Before. Cleaning in the source or in a staging area is cheaper and avoids loading duplicates that users then start working on.
Can we migrate attachments and emails?
Yes, but plan for it separately. Files, attachments and email history add volume, storage and relationship complexity.
