Salesforce data migration is the one-time move of records from a legacy CRM, spreadsheets or another org into Salesforce. A sound strategy fixes the scope, maps every field, loads objects in dependency order using External IDs, picks the right tool for the volume, rehearses in a sandbox and validates counts and samples before go-live. Most failures come from skipped mapping and cleansing, not from the load tools.
This guide was first published in 2020 as "Top Trending Salesforce Data Migration Strategies to Follow". It has been rewritten for 2026 with Salesforce's current tools and limits and a step-by-step plan, and it now also covers the tools from our older post on integration tools for data migration.
What is a Salesforce data migration strategy?
A Salesforce data migration strategy is the written plan for what moves, how it maps, in what order, with which tool and how you prove it worked. A migration strategy answers five questions before any record moves: what data comes across, how it maps to Salesforce objects and fields, in what order it loads, which tool loads it, and how you prove it arrived correctly. Salesforce Help's data migration best practices frame it in three phases: plan, execute and validate.
Migration is not integration. A migration moves data once, at cutover. Integration keeps two systems in sync for as long as both run. If the legacy system stays live after go-live, you need both, and Salesforce's data integration decision guide recommends integration tools such as MuleSoft or Change Data Capture for ongoing sync rather than Data Loader.
Migration approaches: big bang, phased or parallel
Big bang moves everything in one cutover, phased moves data in waves, and parallel runs both systems until Salesforce is trusted.
| Approach | How it works | Use it when | Main risk |
|---|---|---|---|
| Big bang | All data moves in one cutover window; the old system goes read-only | Volumes fit a weekend and teams can switch together | Little time to recover if the load fails |
| Phased | Data moves by region, business unit or object in waves | Large orgs or teams going live at different times | Records split across two systems for a while |
| Parallel run | Both systems run, with a sync, until Salesforce is trusted | Critical processes where a fallback is mandatory | Cost and effort of keeping two systems in step |
Whichever you pick, plan a delta load: the records created or changed between your last full load and cutover.
Step-by-step Salesforce data migration plan
Scope, map, prepare, cleanse, rehearse, load in order, validate and cut over, with a named business owner signing off each object.
- Inventory the scope. List the objects and fields in scope and decide what not to bring, such as closed records older than a set date. Help's guide says to start with a clear inventory of objects and fields (Salesforce Help).
- Name the data owners. Give each object a business owner who decides what is in scope, approves the mapping and signs off the validation. Without one, nobody can say whether the migrated data is right.
- Map fields. Build a mapping sheet: source field, target object and field, data type, transformation rule and owner. Export a Data Loader template per target object to see required fields and relationships.
- Prepare Salesforce. Create custom fields, picklist values and record types first, plus a legacy-ID field on each object marked as an External ID. Trailhead lists these configuration changes as a step before importing (Trailhead).
- Cleanse. Remove duplicates, fix formats and apply naming rules in the source or a staging area. Cleaning after the load is far harder.
- Test small, then rehearse. Load one record, check it, then a small file, as both Trailhead and Help recommend. Then run a full rehearsal in a Full or Partial Copy sandbox and time it.
- Load in dependency order. Parents before children, using External IDs to link them.
- Validate. Compare record counts between source and Salesforce with reports, check a sample of records by hand, and review the error logs for anything that failed (Salesforce Help). Also check relationships: every contact should have its account, every opportunity product its opportunity, with no orphan records. Build these checks as Salesforce reports so the data owner can run them.
- Cut over and switch automation back on. Run the delta load, re-enable automation, recalculate sharing, and freeze the old system. Agree in advance what would make you roll back, and keep the legacy system read-only, not switched off, until sign-off.
In what order should you load objects?
Load parents before children: users and reference data, then accounts, contacts, opportunities and cases, then their children and activities. Help's guide is blunt: always migrate objects in dependency order. A typical Sales and Service order:
| Wave | Objects | Why |
|---|---|---|
| 1 | Users, roles, queues, products, price books | Owners and reference data other records point to |
| 2 | Accounts (parents before child accounts) | The top of most relationships |
| 3 | Contacts, leads | Look up to accounts and owners |
| 4 | Opportunities, cases, contracts | Look up to accounts and contacts |
| 5 | Opportunity products, contact roles, case comments | Children of wave 4 |
| 6 | Tasks, events, notes and files | Can relate to almost any record, so they load last |
With a legacy-ID External ID on every object, each child file can reference its parent by the legacy ID, so you never need to look up new Salesforce IDs between waves.
Salesforce data migration tools compared
Use the Data Import Wizard for small loads, Data Loader for most migrations, Bulk API 2.0 or the CLI for scripted loads, and an ETL platform for complex or ongoing work.
| Tool | Volume | Best for |
|---|---|---|
| Data Import Wizard | Up to 50,000 records at a time | Small loads of common objects from the Setup menu |
| Data Loader | Trailhead gives up to 150 million records; SOAP API by default, Bulk API for speed | Most migrations; can run from the command line for repeatable loads |
| Bulk API 2.0 and the Salesforce CLI | Recommended for any operation over 2,000 records | Scripted, automated loads run by developers |
| ETL or integration platforms, such as MuleSoft | Large and complex | Heavy transformation, many sources, or a migration followed by ongoing sync |
Limits from Trailhead's import unit and the large data volumes guide. Salesforce's pages don't all quote the same Data Loader ceiling: as of November 2026 Trailhead says up to 150 million records, while some Salesforce Help pages still say 5 million, so check the current limit for your org before planning a very large load. Our Data Loader guide walks through installing and running it, and Workbench is handy for quick queries during validation.
Best practices for large data volumes
Salesforce's large data volumes guide gives several rules that matter once you load hundreds of thousands of records:
- Use the fastest operation. Insert is fastest, then update, then upsert. Where you can, split an upsert into separate inserts and updates.
- Pause automation. Disable or bypass Apex triggers, flows and validation rules during the load, and process records afterwards, for example with batch Apex. Trailhead adds that records failing validation rules are not imported.
- Defer sharing. The defer sharing calculation permission postpones sharing work until all data is loaded; recalculate sharing afterwards.
- Use Bulk API 2.0 for any operation over 2,000 records.
- Load clean data. The guide warns that errors in a batch force that batch into slower single-row processing, so fix data before loading, not during.
- Send only changes. On updates and delta loads, send only the fields that actually changed.
Our guide to the Salesforce order of execution explains which automation runs on every saved record, which is what you are switching off.
Common migration mistakes
The costly mistakes are moving too much, losing the link to the source, wrong formats, missing owners and skipping the rehearsal.
- Migrating everything. Old, unused data inflates storage and slows the load. Agree an archive rule.
- No legacy IDs. Without them you can't safely re-run a load or trace a record back to the source.
- Wrong formats. Trailhead notes that multi-select picklist values are separated by semicolons, checkboxes use 1 and 0, dates must match your locale, and formula fields can't be imported.
- Forgetting owners. Records loaded without the right owner land with the integration user and break sharing and reports.
- Validation rules blocking the load. Records that fail validation rules are skipped, so pause them or fix the data first.
- No rehearsal. The first full load should never be the production one.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce migration team plans and runs migrations, including HubSpot to Salesforce, Zoho to Salesforce and Dynamics 365 to Salesforce, and our org consolidation service merges Salesforce orgs. Talk to us about your migration.
Frequently asked questions
What is Salesforce data migration?
It is the one-time move of records, such as accounts, contacts, opportunities, cases and files, from a legacy system, spreadsheets or another Salesforce org into Salesforce. It differs from integration, which keeps systems in sync on an ongoing basis.
Which tool should I use to migrate data into Salesforce?
Use the Data Import Wizard for up to 50,000 records of common objects, Data Loader for larger volumes (Trailhead gives up to 150 million records, using the Bulk API), and Bulk API 2.0, the Salesforce CLI or an ETL or integration platform for automated, repeatable or very large loads.
In what order should objects be migrated?
In dependency order: users and reference data first, then parent records such as accounts, then child records such as contacts and opportunities, then their children such as opportunity products, cases, activities and files. A child can only link to a parent that already exists.
Why use External IDs in a migration?
Storing each record's legacy ID in a custom field marked as an External ID lets you upsert, link child records to parents without looking up new Salesforce IDs, re-run loads without creating duplicates, and trace every record back to the source.
How long does a Salesforce data migration take?
It depends on data volume, quality and how many systems are involved. Most of the time goes into mapping, cleansing and test loads rather than the final load. Plan at least one full rehearsal in a Full or Partial Copy sandbox to measure the real load time before cutover.