Key takeaways
- Most migration problems come from source data quality, not from the loading tools.
- Decide what to migrate before mapping fields. Not every historical record deserves a place in Salesforce.
- Use the Data Import Wizard for small, simple loads and Data Loader or an ETL tool for larger or repeatable ones.
- Run at least one full trial load in a sandbox and agree validation checks with the business.
Why data migration deserves its own plan
Users judge a new CRM on the first day by whether their customers, deals and history look right. If they find duplicates, missing contacts or broken ownership, trust drops quickly and old spreadsheets come back. A planned migration avoids that.
This checklist covers moving data into Salesforce from spreadsheets, an older CRM, an ERP or another Salesforce org.
1. Scope what to migrate
- List every source system and the objects it holds: accounts, contacts, leads, opportunities, cases, activities, products, files.
- Agree a cut-off for history. Many teams migrate open records plus two or three years of closed records and archive the rest.
- Identify data that must not be migrated, such as personal data you no longer have a reason to keep. In the UAE, check which data protection regime applies to your entity before you copy personal data into a new system.
- Note dependencies. Accounts must load before contacts, and contacts before opportunities and cases.
2. Profile and clean the source data
- Find duplicates in companies and contacts, including spelling variants of the same company name in English and transliterated Arabic.
- Standardise formats for phone numbers (for example +971), emails, countries, emirates and currencies.
- Fill or flag missing mandatory values.
- Agree a “golden record” rule for duplicates: which source wins for each field.
- Remove test data, inactive users’ junk records and obsolete picklist values.
Cleaning in the source or in a staging area is usually faster than fixing records after they reach Salesforce.
3. Map fields and values
- Create a mapping document for each object: source field, target field, transformation rule, default value.
- Map picklist values explicitly, such as old sales stages to new ones.
- Plan record ownership. Map old users to new Salesforce users, and decide where records of departed staff should go.
- Add an external ID field to each object to hold the source system ID. This makes relationships, reloads and reconciliation much easier.
4. Choose the right tool
| Tool | Best for | Notes |
|---|---|---|
| Data Import Wizard | Simple loads of fewer than 50,000 records into supported objects | Browser-based, built-in duplicate matching for some objects |
| Data Loader | Loads of up to 5 million records, unsupported objects, repeatable loads | Desktop or command-line tool; supports upsert with external IDs |
| ETL or integration tools | Complex transformations, multiple sources, ongoing sync | Examples include MuleSoft and third-party ETL tools |
Salesforce’s own documentation recommends Data Loader for larger, scheduled or complex loads, and suggests involving a partner or specialist tools beyond 5 million records.
5. Prepare the target org
- Temporarily review validation rules, duplicate rules and automation that could block or slow the load, and document every change you make.
- Check storage limits for data and files.
- Create users, roles and record types before loading records that depend on them.
- Decide whether audit fields such as original created dates need to be preserved, and enable that setting if so.
6. Run trial loads in a sandbox
Do at least one full trial load into a sandbox with production-like settings. Record load times, error counts and fixes. Repeat until the load runs cleanly. This also tells you how long the production cutover will take.
7. Validate with the business
- Compare record counts per object between source and target.
- Check totals, such as pipeline value by stage or open cases by team.
- Ask key users to spot-check accounts they know well.
- Confirm that relationships, owners and attachments are correct.
8. Plan the cutover
- Agree a freeze period when the old system is read-only.
- Run a final delta load for records changed since the trial load.
- Re-enable validation rules and automation, and test them.
- Keep the old system available read-only for a defined period for reference.
Org-to-org migrations
Merging several Salesforce orgs adds schema conflicts, duplicate users and overlapping automation. In our org consolidation case study, three orgs were mapped to one standard data model, with deduplication rules applied before and during migration.
Get support for your migration
Data migration is usually part of a wider rollout. See our Salesforce implementation services, or read our step-by-step implementation guide for how migration fits into the overall plan.
Frequently asked questions
How long does a Salesforce data migration take?
Simple spreadsheet migrations can take days. Migrations from several systems with cleansing, mapping and trial loads usually take several weeks and run in parallel with the build.
Should we migrate all historical data?
Not necessarily. Many companies migrate open records and a few years of history, and archive older data elsewhere. Consider reporting needs, storage cost and data protection obligations.
What is an external ID and why use one?
An external ID is a field that stores the record’s ID from the source system. It lets you link related records, reload data safely with upserts, and reconcile records after migration.
Can we migrate data from another CRM like HubSpot or Zoho?
Yes. Export the data, clean and map it, and load it with Data Loader or an ETL tool. The approach is the same; the mapping differs.
Moving data into Salesforce?
We can help you plan, clean, map and load your data so users trust the system from day one.
Related articles
Sources