How to Migrate from Salesforce to HubSpot Without Losing Data
Practical playbook for migrating contacts, deals, and historical activity from Salesforce to HubSpot, including custom property mapping and pre-launch QA.
By Chase Weiser
The first Salesforce-to-HubSpot migration I ran took 11 days. The second one took 3. The difference was not the tooling. The difference was a 40-page audit I ran before anyone touched the migration wizard, and a hard rule that we would not import a single record into production until the test batch passed every check on a written QA list.
If you are planning this migration and you are nervous about losing data, you should be. About 60% of the migrations I have seen in audits arrived broken. The good news is that most of the breakage is preventable, and the patterns are predictable.
Start with a pre-migration audit, not the wizard
Before you connect anything, run an inventory of your current Salesforce instance. You are looking for four things.
The first is field count and usage. Pull a list of every custom field on Account, Contact, Lead, and Opportunity. For each one, query how many records actually have a value. About 30 to 50% of custom fields in any mature Salesforce org are dead, populated once and abandoned. Migrating dead fields wastes property slots in HubSpot and clutters every contact record. Mark these for deletion before migration, not after.
The second is automation inventory. Export every Process Builder, Flow, Workflow Rule, Apex Trigger, and Validation Rule. You will rebuild the active ones in HubSpot, but you need to know what they do before you can decide whether to keep them. Half of them probably exist because someone left in 2022 and nobody knew how to turn them off.
The third is integration map. List every tool currently connected to Salesforce: marketing platform, billing, support, document signing, dialer, anything. Each integration needs a separate plan. Some have native HubSpot apps. Some need a Zapier or n8n bridge. A few will need to be rewritten.
The fourth is user and role audit. Map every Salesforce user to a planned HubSpot user, with intended seat type (Sales Hub Pro, Service Hub Starter, etc.) and role permissions. Owner mapping is where the most painful errors hide, and you do not want to discover them at go-live.
Property mapping is where migrations break
The HubSpot Migration Tool will auto-map standard fields. Where you will spend most of your time is the custom side, and three field types in particular cause trouble.
Picklist fields look easy and are not. A Salesforce picklist with 47 values, half of which are typos and inactive variants of the same option, will import into HubSpot as a dropdown with 47 values. The fix is to clean the picklist in Salesforce first: pick a target list of valid values, write a SOQL update to consolidate variants, and inactivate the rest. Then map. If you skip this step you will be doing it manually in HubSpot a month later, and you will lose the value history when you merge options.
Formula fields do not migrate as live formulas. They migrate as a one-time snapshot of the calculated value, which then sits frozen forever. If the field needs to keep updating, you have to rebuild it as a HubSpot calculated property (available on Operations Hub Pro and above) or a workflow that recomputes on a property-change trigger. For deal-level fields like “days in current stage” or “weighted amount,” this is non-negotiable. For lead-level scoring fields, consider rebuilding them in HubSpot’s lead scoring engine instead.
Lookup relationships between custom objects are the third trap. Salesforce supports any-to-any relationships freely. HubSpot’s standard objects (Contact, Company, Deal, Ticket) have hardcoded associations, and custom objects on Enterprise tier let you define new ones, but with limits on cardinality. If your Salesforce data model has a 4-way custom-object web, plan to flatten part of it before you import.
Run a 50-record test migration
The single most useful step in this entire process is the test migration. Pick 50 records: 20 contacts, 15 companies, 10 deals at various stages, 5 with closed-won status. Migrate just these records into a HubSpot sandbox or a fresh Free portal.
Then walk every record manually, comparing it to the source. The full QA list runs to about 30 checks. The five that catch the most issues:
- Does the Contact’s Owner match the Salesforce Account Owner, not the contact creator?
- Did the Deal Amount survive currency conversion if you are multi-currency?
- Are Activity timestamps in the right timezone, or did they all jump to UTC and now show meetings at 3 AM?
- Did the Lifecycle Stage map correctly, or are all your customers showing as “Lead”?
- Did multi-select picklists preserve all selected values, or only the first?
Fix every issue you find at the 50-record stage. Each one will multiply by your record count when you run the full migration.
Historical activity is the hard part
The HubSpot Migration Tool handles records well. It handles historical activity (calls, emails, meetings, notes, tasks) inconsistently. Emails logged via Salesforce-Outlook integration usually come over. Calls logged through a third-party dialer usually do not. Notes attached to records typically migrate. Notes attached to Tasks sometimes vanish.
For a migration where activity history matters, the official tool alone is rarely enough. The pattern that works is a hybrid: use the HubSpot Migration Tool for records and the activities it handles cleanly, then backfill the rest from a Salesforce data export using a dedicated CRM-migration tool or a custom workflow that pushes activities into the HubSpot Engagements API. We do this on every migration where the client wants to keep more than 12 months of activity. It typically adds 2 to 4 days but saves you from the worst possible outcome, which is sales reps opening HubSpot on day one and finding their accounts empty.
Post-migration QA, before you cut over
You are not done when the records are in HubSpot. You are done when these are all true:
Every active user can log in, sees their assigned records, and can edit them. Every automation has been rebuilt and tested in the sandbox. Every integration has been reconnected and a test event has flowed through. Lifecycle stages, deal stages, and lead status all show the correct distributions. Reports built in Salesforce have HubSpot equivalents that produce matching numbers within 2%.
That last one is the test that most migrations fail. If your Salesforce pipeline report says $1.2M and your HubSpot pipeline report says $940K, you have a problem, and the answer is almost always either a stage mapping issue or a missing record set. Find it before launch, not after.
Common pitfalls I see in audits
Three patterns show up over and over in migrations that went wrong. Lost activity history is the most common, usually because the team relied on the migration tool alone. Broken automations are the second, usually because nobody rebuilt the Salesforce Validation Rules as HubSpot required-field workflows. Role permission gaps are the third: HubSpot’s permission model is not 1:1 with Salesforce profiles, and reps end up either over-privileged or locked out.
If you are planning this migration and you want a second pair of eyes on the audit, that is the kind of work I do. The full HubSpot consulting service includes pre-migration audits, mapping, and post-launch QA. You can read more on the HubSpot consulting page, or if you have already started and something is broken, the contact form is the fastest way to get me to look at it.
The migrations that go well are the ones where the team treated the audit as the project and the import as a 6-hour event at the end. Plan it that way and you will keep your data.
