Key takeaways
- Clean data before you move it. Migration is the cheapest moment to drop duplicates and dead records.
- Map fields in a written document and agree it with the people who use the data.
- Load in order: users, accounts, contacts, opportunities, then activities and files.
- Run at least one full test load in a sandbox and reconcile counts and totals before go-live.
Moving into Salesforce is a chance to start clean. It is also the moment when many teams lose trust in their new CRM, because records are missing, owners are wrong or history disappeared.
Our team has worked on migrations into Salesforce for global sales teams. The checklist below is what we follow for smaller companies, whether the source is a spreadsheet, HubSpot, Pipedrive or an old CRM.
Phase 1: plan
- Define what success looks like. For example: all active customers and open deals migrated, two years of closed deals, activity history for the last 12 months.
- Decide what not to migrate. Old leads that never responded, contacts without email addresses, deals closed lost five years ago. Less data means a faster, cleaner migration.
- List the source systems and owners. Who knows each data set and can answer questions about it?
- Freeze the data model. Agree the Salesforce objects, record types, required fields and picklist values before mapping.
Phase 2: clean and map
- Export everything first. Keep a full, untouched backup of the source data.
- Remove duplicates in the source. It is much easier than merging later in Salesforce.
- Standardise values. Countries, industries, stages and owners in consistent formats.
- Write a mapping document. For each source field: the Salesforce object and field, any transformation, and an example.
- Map users and owners. Every record needs an owner in Salesforce. Decide where records owned by people who have left will go.
- Plan IDs. Create an external ID field on each object to store the old system's ID. It makes relationships and reloads much easier.
Phase 3: test
- Load into a sandbox first. Run the full migration at least once in a sandbox.
- Load in order. Users, then accounts, contacts, opportunities, opportunity contact roles, products, then activities, notes and files.
- Switch off automation during loads where it would send emails or create tasks for historical records. Use a custom setting or permission to bypass Flows for the migration user.
- Reconcile. Compare record counts and amount totals between source and Salesforce. Spot-check 20 records per object with a business user.
- Test with users. Ask two or three reps to find their accounts and deals and confirm they look right.
Phase 4: go live
- Pick a cut-over date and stop using the old system for new records from that point.
- Run the final load, using the same scripts and mappings as the test.
- Reconcile again and fix gaps the same day.
- Re-enable automations and check that new records behave correctly.
- Train users on day one, focused on their daily tasks rather than every feature.
Phase 5: after go-live
- Keep the old system read-only for a few months in case someone needs history that wasn't migrated.
- Watch data quality for the first month: duplicates, missing owners, wrong stages.
- Collect feedback in the first two weeks and fix quick wins fast. Early trust is hard to rebuild if it's lost.
Common mistakes to avoid
| Mistake | What happens | How to avoid it |
|---|---|---|
| Migrating everything | Slow loads, cluttered org | Agree what to leave behind |
| No external IDs | Broken relationships, painful reloads | Add an external ID field per object |
| Automation left on | Customers receive emails about old deals | Bypass Flows for the migration user |
| No reconciliation | Missing data found weeks later | Compare counts and totals after each load |
| Training on everything | Users overwhelmed | Train on daily tasks first |
A well-run migration is mostly preparation. If you'd like a mapping document, test loads and reconciliation done for you, the migration service covers the full process.
Frequently asked questions
How long does a CRM migration to Salesforce take?
For a small company with one source system and up to a few hundred thousand records, three to six weeks is typical, including mapping, test loads and training. Complex histories, many systems or custom objects take longer.
Which tool should we use to import data?
The Data Import Wizard handles up to 50,000 records per import for common objects and is easy to use. Data Loader handles larger volumes and all objects. For repeated or complex migrations, an ETL tool may be worth it.