Salesforce to HubSpotMigration: A B2B Checklist andthe Mistakes to Avoid

A Salesforce to HubSpot migration takes most B2B teams somewhere between a few weeks and a few months, and the part that decides whether it works is not the data transfer. It is the decisions made before it: which records are worth moving, how your sales process maps to HubSpot’s objects, and who owns the portal on day one. Get those right and the import is a technical task. Get them wrong and you pay to move years of clutter into a new system.

I run HubSpot implementations for B2B companies, and the pattern is consistent: teams leave Salesforce because the system became expensive to maintain, not because it lacked features. This is the checklist I would use, with the mistakes I see most often.

Is migrating from Salesforce to HubSpot worth it for a B2B company?

It is worth it in a specific set of situations. The strongest signals are a small or mid-size sales team, a Salesforce org that depends on one overloaded admin or an outside consultant for every change, marketing and sales working in separate tools with a brittle sync between them, and licence plus add-on costs that no longer match what the team actually uses.

It is the wrong move when your process genuinely depends on heavy custom objects, complex territory or quoting logic, or deep Salesforce-only integrations. Some of that can be rebuilt in HubSpot, depending on your tier, but it changes the scope from a migration to a redesign. Say that out loud before you sign anything. If you are not sure which side you are on, my comparison of fractional, in-house and agency HubSpot ownership is a useful way to think about who will run the new portal.

What should you decide before moving any data?

Four decisions, in this order. First, scope: which objects and how much history. Most teams do not need ten years of closed-lost deals in HubSpot; a defined window plus anything tied to open work is usually enough, and the rest can live in an archive export. Second, definitions: what counts as a lead, a qualified opportunity and a customer. If sales and marketing disagree, migrating will encode the disagreement. My note on lifecycle stages and exit criteria covers how to settle this.

Third, ownership: one named person on your side who approves the mapping and signs off the test import. Fourth, a freeze date: after the final extract, nobody edits Salesforce records that matter, or you will be reconciling two systems for weeks.

How do Salesforce objects map to HubSpot?

The mapping is where migrations quietly go wrong, because the two systems are modelled differently. Salesforce separates Leads and Contacts; HubSpot uses a single Contact record with a lifecycle stage. Use this as a starting point and confirm each line against your own org and HubSpot tier.

Add one property to every migrated record that stores its original Salesforce ID. It costs nothing, and it is what lets you reconcile counts, fix mismatches and re-run a partial import later without guessing.

What is the step-by-step migration plan?

1. Audit. Export record counts by object, list active users, flows, integrations and reports actually used in the last six months. Anything unused is a candidate to drop.
2. Clean. Merge duplicates, fix owners, standardise picklist values and remove records with no email, no activity and no deal. A scripted data-hygiene routine saves days here.
3. Map. Write the object and field mapping on paper, including stage-by-stage deal mapping and the property that will store the Salesforce ID.
4. Build the target. Create properties, pipelines, teams and permissions in HubSpot before the import. Use the first-30-days plan as the order of operations.
5. Test import. Move a representative sample, usually a few hundred records across every object, and have the owner check them against Salesforce.
6. Final import and cutover. Freeze Salesforce, run the full extract, import in dependency order (companies, contacts, deals, then activities), then reconcile counts using the stored IDs. Schedule the cutover for a weekend so US reps, East Coast to West Coast, open Monday on the new system, and keep support coverage across US hours for the first week.
7. Rebuild automation and integrations. Recreate lead routing, notifications and the integrations you decided to keep, and switch off the old ones deliberately.
8. Train and support. Give reps a one-page workflow and be available for the first two weeks, when most adoption problems surface.

Which mistakes break a Salesforce to HubSpot migration?

The same few appear again and again. Migrating everything because it is easy to export, which buries reps in irrelevant history. Skipping the stage-by-stage deal mapping, so pipeline reports look wrong on day one and trust in the new system drops. Importing Leads and Contacts without deduplication. Forgetting that email, meeting and attachment history may need a separate approach. Running both systems in parallel for too long, so reps update the wrong one. And leaving the new portal without an owner, which is how HubSpot ends up as cluttered as the system it replaced.

There is also a consent angle for any team with contacts in the EU or UK. Carry over the consent and subscription status of each contact, not just the email address, and check how your marketing permissions map. If that data is incomplete, treat those contacts as not marketable until you have confirmed it.

How long does it take and what drives the cost?

Timeline and cost scale with a handful of variables, not with record count alone: the number of objects in use, how much custom logic must be rebuilt, the state of the data, how many integrations you keep, and how quickly your team can approve mappings. A clean org with standard objects can be moved in a few weeks. A heavily customised org with many integrations is a multi-month project and should be scoped and quoted as one. Be wary of any fixed price offered without looking at your org first.

Frequently asked questions