Salesforce to HubSpot migration: recover your data without losing
Changing CRM is often decided for good reasons: an interface that teams adopt more easily, marketing tools gathered in one place, lighter administration. The migration itself is almost always presented as an export and import task. That’s where projects become complicated.
A Salesforce database carries years of entries, fields added over time to meet needs, and implicit rules that no one has written down. Moving it as-is is like installing the same duplicates, gaps, and contradictions into HubSpot, with a new tool to display them. This article starts from the data: what doesn’t pass through as-is, what needs to be prepared, and the switch plan that allows starting from a reliable base.
A migration is about data, not the tool
HubSpot and Salesforce do not store information in the same way. Objects are similar, but their rules differ, and it’s these differences that cause data loss.
The most common case concerns people. Salesforce distinguishes leads, which are not yet qualified, from contacts, linked to an account. HubSpot combines both into a single object. A person present both as an unconverted lead and as a contact becomes two records at the destination, unless the matching rule was set beforehand.
What doesn’t pass through as-is
- Custom fields. Each field added in Salesforce must be recreated as a property in HubSpot, with the correct type and the same possible values. A choice list that differs from one tool to another is enough to cause the migration of all affected records to fail.
- Owners. Records are linked to Salesforce users. If the same people do not exist in HubSpot at the time of migration, records arrive without owners, and no one follows them anymore.
- History. Activities, emails, and closed opportunities often make up the bulk. Recreating everything weighs down the project; not migrating anything deprives teams of each client’s context.
- Links with other tools. An ERP, billing, or support tool that reads Salesforce will stop receiving data on the day of the switch. These flows must be identified and reconnected, not discovered afterwards.
None of these points is a software problem. They are data decisions that must be made before migration rather than during.
Prepare the database before moving anything
Preparation accounts for the largest part of the useful work. It involves three tasks, to be carried out in this order.
Deduplicate before migration
Correcting duplicates in Salesforce before export is much cheaper than fixing them in HubSpot afterward. Once re-imported, each duplicate comes with its activities, transactions, and emails, which will need to be linked to the correct record one by one.
Deduplication begins with choosing a stable matching key. For companies, an official identifier like the SIREN is more reliable than the company name, which varies with input. For individuals, the professional email address is a good starting point, to be combined with the name and company.
A migrated database will never be cleaner than the original database.
Decide on the authoritative data
During migration, and often afterward, multiple tools hold the same information. Billing can remain in the ERP, while the sales relationship moves to HubSpot. For each key data — company name, billing address, owner, customer status — it is necessary to specify which system is authoritative and who is responsible.
This rule fits on one page. Without it, each connector applies its own logic, and discrepancies reappear from the first synchronizations.
Sort fields
A database spanning several years almost always contains empty fields, duplicates, or fields no one knows the purpose of. Migration is the best time to clean up, field by field.
The five-step switch plan
Once the database is prepared, the migration itself follows a short sequence. Each step produces a verifiable deliverable before moving to the next.
- Frame List the objects, fields, users, and flows involved, then set the depth of history to be included.
- Clean Deduplicate, complete mandatory data, and apply field sorting in Salesforce.
- Match Write the correspondence between each object and each field of the two tools, including choice list values.
- Test Perform a full copy in a test environment, then compare counts and randomly selected records.
- Switch and verify Freeze entries, re-import data, reconnect flows, then verify with teams before opening HubSpot.
The testing phase is the one most tempted to be shortened. Yet it is the only phase that reveals discrepancies before the sales teams: a truncated field, an incomplete choice list, missing owners.
Choose the switch mode
There is no absolute best switch mode. The choice depends on the size of the database, the number of involved teams, and the tools dependent on Salesforce.
Whatever the chosen mode, a rollback must remain possible until the final check: a complete and dated export of Salesforce, kept as long as the new database has not been validated.
Check the database after the switch
A successful migration is verified with numbers, not with a printout. Three checks are enough to do this rigorously.
- The counts. The number of contacts, companies, and transactions must match what the matching anticipated, including explained discrepancies.
- The samples. A few dozen records, randomly selected, are compared field by field between the two tools.
- The reports. The dashboards monitored by management must give the same results before and after, over the same period.
These checks take little time. They mainly prevent the most costly scenario: discovering a discrepancy several weeks later, when the new entries have mixed it with the imported data.
What turnK brings to a migration
turnK intervenes on the part that decides the result: the data. We audit the Salesforce database, clean it, write the matching and the rule of the data that takes precedence, then check the database after the switch. The tools remain yours; what changes is the reliability of what they contain.
It is the work carried out for Mirakl : CRM cleaning and synchronization between HubSpot and Salesforce, so that both tools share the same data.
The initial diagnosis in the beginning of the article gives you a first level of risk. To go further, discover our offer CRM and customer data, or read how to correct duplicates without recreating them.
the most common questions
It mainly depends on the state of the database, more than its volume: duplicates, custom fields, historical data to keep, and links with other tools. Data preparation accounts for the largest part of the work.
Yes, including activities and closed opportunities, but transferring everything weighs down the project. It is often more effective to set a historical depth and archive the rest in a dated export.
HubSpot combines leads and contacts into a single object. A person present both as a lead and as a contact risks becoming two records, unless the matching rule is set before the transfer.
With three checks: counts per object, field-by-field comparison of a sample of records, and management reports, which must give the same results before and after the switch.




