Most organisations move to Salesforce for better automation, reporting, ecosystem or scale. The configuration of the new system gets most of the attention. The migration of years of customer data gets far less, and it is where CRM projects most often go wrong.

This playbook explains how to migrate to Salesforce from HubSpot, Zoho CRM or Microsoft Dynamics 365 using a proven approach: planning, object mapping, load order, tools, preserving history, testing and cut-over.

When does migrating to Salesforce make sense?

• Your sales, service and partner processes have outgrown your current CRM’s automation or data model.
• You need enterprise-grade security, sharing and audit controls.
• You want to adopt Salesforce products such as Service Cloud, CPQ, Experience Cloud or Agentforce AI agents.
• Your company has standardised on Salesforce after an acquisition.

If you are still deciding, our overview of Salesforce CRM and its benefits for growing businesses may help.

The seven phases of a CRM migration

1. Discover: inventory objects, fields, volumes, integrations and data owners in the source CRM.
2. Clean: remove duplicates, fix obvious errors and decide what not to migrate.
3. Map: define how each object and field maps to Salesforce, including picklist values and owners.
4. Build: create the Salesforce data model, external IDs and migration scripts or jobs.
5. Trial loads: load into a full or partial copy sandbox at least twice, reconcile and fix.
6. Cut-over: freeze the source system, run the final load and delta, validate and switch users.
7. Hypercare: support users, fix data issues quickly and decommission the old CRM.

How do HubSpot, Zoho and Dynamics objects map to Salesforce?

Every implementation has custom objects, but the core mapping follows a consistent pattern:

Platform-specific points to watch

• HubSpot: a HubSpot contact can represent both a lead and a customer contact. Decide how lifecycle stages map to Salesforce Leads versus Contacts before you design the load. HubSpot associations between objects need explicit mapping to Salesforce lookups.
• Zoho CRM: custom modules and multi-select lookups often need custom objects or junction objects in Salesforce. Blueprint processes must be redesigned as Flows rather than migrated.
• Dynamics 365: business units and security roles do not map directly to Salesforce roles and sharing. Design your Salesforce security model fresh. Option sets become picklists, and connection or relationship entities may need junction objects.

Data cleansing checklist before you migrate

Every hour spent cleaning data in the source system saves several hours of fixing it in Salesforce. Before the first trial load:

• Merge duplicates in companies, contacts and leads using email domains, names and phone numbers.
• Archive stale records, such as leads with no activity for several years, unless you must retain them.
• Standardise values for countries, states, industries, lead sources and deal stages.
• Fix ownership by reassigning records owned by people who have left, or agree how inactive owners will be handled.
• Complete required fields that Salesforce will enforce, such as account names and opportunity close dates.
• Clean email addresses and phone numbers so automation and integrations work from day one.
• Name a data owner for each object who signs off mapping decisions and reconciliation results.

Designing the Salesforce data model for migration

• Create an external ID field on every migrated object holding the source system’s record ID. It lets you upsert, relink related records and trace any Salesforce record back to its origin.
• Standardise picklists before loading, and map old values to new ones in a documented table.
• Decide on record types and sales processes up front, so opportunity stages load correctly.
• Review the Salesforce data model for standard objects you can use before creating custom ones.

The correct load order

Parent records must exist before child records reference them. A reliable sequence:

1. Users (including inactive users that own historic records)
2. Accounts, then parent account relationships in a second pass
3. Contacts
4. Leads
5. Products, price books and price book entries
6. Campaigns and campaign members
7. Opportunities, then opportunity contact roles and opportunity products
8. Cases
9. Custom objects, in dependency order
10. Activities: tasks, events and emails
11. Files and notes

Which migration tools should you use?

Preserving history: dates, owners, emails and files

• Created dates and creators: enable "Set Audit Fields upon Record Creation" for the migration user so historic CreatedDate and CreatedById values can be loaded on insert.
• Inactive owners: the related permission "Update Records with Inactive Owners" lets records keep their original, now inactive, owners.
• Emails: load as EmailMessage when Enhanced Email is enabled and fidelity matters, or as completed Tasks for a simpler history.
• Files: load documents as ContentVersion and link them to records with ContentDocumentLink. Check file storage capacity first.
• Automation during loads: use a bypass custom permission or custom setting so validation rules, Flows and triggers do not fire unnecessarily or send emails to customers during migration.

Testing and reconciliation

Every trial load should end with a reconciliation report signed off by the data owner:

• Record counts per object: source versus Salesforce, with explained differences
• Financial totals such as open pipeline value and closed-won revenue by year
• Spot checks of 20–50 records per object, comparing every mapped field
• Relationship checks: contacts on the right accounts, activities on the right records
• User testing of real scenarios, such as finding a customer and seeing their full history

Good reconciliation is also the foundation of reliable reports and dashboards after go-live.

A safe cut-over plan

1. Announce a data freeze window for the old CRM, ideally over a weekend.
2. Take a full backup export of the source system.
3. Run the final full load, or load changes since the last trial load (the delta).
4. Re-enable automation and integrations in Salesforce.
5. Run the reconciliation checklist and smoke tests with key users.
6. Switch users to Salesforce and set the old CRM to read-only.
7. Provide floor-walker or virtual support for the first two weeks.

A typical migration timeline

Larger migrations with many custom objects, several source systems or years of email history take longer, but the sequence stays the same. Running the migration timeline in parallel with the Salesforce build keeps both on track.

Common migration mistakes

• Migrating everything "just in case", including years of low-value data
• No external IDs, making re-runs and fixes painful
• Loading into production without full trial loads in a sandbox
• Forgetting inactive users, leaving historic records with the wrong owner
• Letting automation send emails to customers during the load
• Leaving data cleansing to the week before go-live

How long and how much?

Migration effort depends on volumes, number of objects, data quality, history requirements and files. It typically accounts for 10–20% of the total implementation budget. See our Salesforce implementation cost guide for how it fits into the overall project, and why Salesforce projects fail for the risks of underestimating it.

Plan your Salesforce migration with Groviya

Groviya has migrated organisations to Salesforce from HubSpot, Zoho, Dynamics 365, spreadsheets and bespoke systems. We handle mapping, cleansing, scripted loads, reconciliation and cut-over as part of a complete Salesforce implementation. Talk to our migration team about your data.