Migrating from Salesforce to HubSpot means moving your contacts, companies, deals, cases, custom objects, and the full history behind them into HubSpot — and rebuilding the automation Salesforce can't simply hand over. Done right, your sales team logs in to a system that already knows their accounts. Done wrong, you lose two years of activity history and accidentally email 40,000 people on day one.

This page covers how the migration actually works, what transfers cleanly, what doesn't, how long it takes, and the point where doing it yourself stops being worth the risk.

Most companies leaving Salesforce do it for one of three reasons: the total cost stopped making sense, the admin overhead got too heavy, or marketing and sales were living in two disconnected systems.

Salesforce is the more configurable platform. That configurability is also why mid-market teams often need a dedicated admin (or a consultant on retainer) just to keep it running. HubSpot puts marketing, sales, and service on one record model, so a contact's email opens, deal stage, and support tickets sit on the same timeline without a separate integration holding it together.

The trade-off is real and worth saying plainly: you give up some of Salesforce's deep customization. For a team that built its life around Apex triggers and a complex sharing model, that's a loss. For a team drowning in configuration it never uses, it's the point.

The two platforms model your data differently, and that's the source of almost every migration problem. The biggest gap is the Lead object.

That last row is where teams underestimate the work. Your data can move in a weekend. Your automation logic can't — it has to be rebuilt by hand in HubSpot's workflow engine, and some Salesforce validation rules have no direct equivalent at all.

A clean migration runs in five stages: audit, field mapping, a test migration on a sandbox, the full migration with automation suppressed, then validation.

1. Audit. Inventory every object, custom field, picklist, and active automation in Salesforce. You can't map what you haven't catalogued, and this is where you find the 80 custom fields nobody has used since 2021.
2. Field mapping. Match each Salesforce field to a HubSpot property, and confirm the types match — a Salesforce picklist mapped to a HubSpot free-text field will land your data as messy strings instead of clean dropdown values.
3. Test migration. Run a sample (a few hundred records) into a HubSpot test environment first. This is non-negotiable. It surfaces broken associations and owner-mapping errors before they hit your live data.
4. Full migration. Move everything — with active workflows and email automation paused. (More on why below; this is the single most common way migrations go wrong.)
5. Validation. Confirm record counts match, associations held, owners are correct, and the activity timeline survived.

You can migrate standard objects (contacts, companies, deals, tickets), custom objects, activity history (calls, emails, meetings, notes), file attachments, and field-level data — provided each is mapped correctly and the owner IDs are translated between systems.

What you cannot migrate, and have to rebuild instead:
- Automation logic — Process Builder, Flow, and Apex don't port. They're rebuilt as HubSpot Workflows.
- Reports and dashboards — rebuilt in HubSpot's reporting tool.
- Formula fields — HubSpot's calculated properties cover some, not all.
- Roles, profiles, and sharing rules — HubSpot uses a different permission model (teams and permission sets), so access is reconfigured, not copied.

The data is the easy half. The rebuild is the half that decides whether your team trusts the new system in week one.

A straightforward migration takes two to four weeks. A complex one — custom objects, multiple pipelines, automation to rebuild, or large data volume — runs six to twelve weeks or more.

The variables that actually move the timeline:

Data volume matters less than data complexity. A million clean contacts migrate faster than 30,000 records tangled in custom objects and broken associations.

The four failures that wreck most migrations are: workflows firing during import, broken record associations, owner-mapping errors, and picklist values that don't line up.

- Workflows firing on import. This is the big one. If a HubSpot workflow is active when you import contacts, the import can trigger it — and "welcome" emails go out to thousands of migrated contacts who never opted in to anything. Always suppress active automation before importing.
- Broken associations. Salesforce stores the contact-to-company and deal-to-contact relationships in its own structure. If those aren't explicitly preserved, your deals arrive in HubSpot detached from any contact, and your reps see a pipeline of orphaned records.
- Owner mapping. Salesforce user IDs don't match HubSpot user IDs. Without a translation map, every migrated deal lands unassigned, and nobody's quota reflects reality.
- Picklist mismatches. A Salesforce "Stage" value of "Closed Won" mapped to a HubSpot deal stage that's spelled differently will silently drop into the wrong stage or land blank. Every dropdown needs its values reconciled before the move.

A failed migration usually shows up as missing activity history, duplicate contacts multiplying, deals detached from their companies, or reporting that no longer matches reality — and most of it is recoverable if you still have the source data in Salesforce.

We see the same wreckage repeatedly: a team ran the import themselves, skipped the test migration, and now half the pipeline is unassigned and the activity timeline is gone. The fix depends on what's salvageable. If Salesforce is still live, a clean re-migration with proper mapping is faster than trying to patch the mess. If Salesforce has already been decommissioned, recovery means working from backups and reconstructing associations record by record.

If you're reading this after a migration has gone sideways, the first move is to stop touching the HubSpot portal and confirm your Salesforce data is still intact. We offer migration rescue specifically for this — re-mapping, de-duplicating, and rebuilding the associations a rushed import broke.

‍Book a rescue assessment.

Before you move anything: clean the Salesforce data, document every active automation, and decide whether you're doing a big-bang cutover or a phased migration.

- Clean first. Deduplicate, archive dead records, and fix inconsistent picklist values in Salesforce. Migrating dirty data just gives you dirty data in a new system, and HubSpot charges you to store contacts you should have deleted.
- Document automation. List every Process Builder, Flow, and Apex trigger that does something the business depends on. This list becomes the build spec for your HubSpot Workflows.
- Choose your approach. Big-bang (cut over all at once) suits smaller teams with simpler data. Phased (run both systems in parallel, migrate by team or function) suits larger orgs that can't afford downtime — or that need Salesforce CPQ to stay live while everything else moves. Phased migrations need a sync between the two systems during the transition, which adds cost and complexity.

If you have standard objects, clean data, and no automation worth keeping, HubSpot's native import will probably get you there. The moment you have custom objects, automation to rebuild, CPQ, or more than a couple hundred thousand records, the risk of a self-managed migration outweighs the savings.

The honest version: the data transfer isn't the hard part, and plenty of teams do it alone fine. What goes wrong is everything around it — the suppressed-automation step nobody knew about, the owner mapping, the activity associations, the workflow rebuild. Those mistakes aren't expensive to make; they're expensive to undo, because by the time you notice, the source system is often already gone.

A migration partner earns its fee on the parts that don't show up in a CSV preview: mapping the data model correctly, rebuilding automation so the new system behaves like the old one on day one, and running the test migration that catches the breakages before they're permanent.

We run every migration through the same five stages — audit, mapping, test migration, full migration with automation suppressed, and validation — and we don't decommission anything in Salesforce until you've confirmed the HubSpot side is right.

What we do that an in-house import skips:
- A documented field-and-object map you sign off on before a single record moves.
- A test migration into a HubSpot sandbox, so you see the result before it's live.
- Automation rebuilt in HubSpot, not just data dumped in — your team logs in to working workflows, not an empty shell.
- A validation pass against record counts, associations, and owners before sign-off.