Quick answer: Core CRM records — contacts, accounts, opportunities, notes, and record ownership — generally transfer from Salesforce to HubSpot cleanly because both platforms share similar data models. What doesn't transfer automatically is the logic layer: Flows and automation must be rebuilt as HubSpot workflows, reports and dashboards must be recreated, custom objects need remodeling, and integrations need reconnection. A successful migration budgets most of its effort for rebuilding logic and validating data, not for moving records.
This guide is for teams that have already made the decision to move. Whether Salesforce or HubSpot is the better platform for a given business genuinely depends on that business — we implement both, and this post takes no position on the choice itself. Once the decision is made, though, the questions become practical: what maps to what, what breaks, and in what order should the work happen?
The good news: the two platforms describe the same underlying reality. HubSpot's own Salesforce integration imports leads, contacts, accounts, and opportunities, per HubSpot's knowledge base, and the standard mapping is well established:
| Salesforce object | HubSpot object | Mapping notes |
|---|---|---|
| Leads + Contacts | Contacts | HubSpot has one person object; lead vs. contact distinction is typically handled with lifecycle stage and lead status |
| Accounts | Companies | Close analog; account hierarchies need review |
| Opportunities | Deals | Stages map to pipeline stages; multiple record types often become multiple pipelines |
| Cases | Tickets | Requires Service Hub for full support workflows |
| Tasks + Events | Activities (tasks, meetings, calls) | Engagement history maps by type |
| Campaigns | No direct equivalent | Often remodeled as lists, campaign properties, or HubSpot marketing campaigns |
| Custom objects | Custom objects | Requires appropriate HubSpot tier; needs deliberate remodeling, not copy-paste |
The single biggest conceptual shift is the lead/contact merge. Salesforce separates unqualified leads from converted contacts as different objects; HubSpot uses one contact object with lifecycle stage doing the work of the conversion boundary. Decide before migrating how historical lead-conversion states will be represented, or your funnel history arrives scrambled.
With sound preparation, these move with little drama:
"Cleanly" still assumes preparation: HubSpot deduplicates contacts by email address, so records without email addresses, or duplicates that Salesforce tolerated, need a strategy before import — not after.
Plan for the following to consume the majority of the project:
Five phases, in order, with no skipping:
Migrating a messy org produces a messy portal with better branding. Before any records move, run a formal quality gate:
A useful rule of thumb from migration work with mid-market firms, including a regional financial-services firm moving after an acquisition: every hour spent cleaning before migration saves several hours of untangling after it.
It depends on org complexity far more than record count. A straightforward org — standard objects, modest automation, few integrations — can often migrate in a handful of weeks. Orgs with heavy customization, custom objects, and multiple integrations commonly run several months, with automation rebuilds and integration re-plumbing driving the timeline rather than the data load itself.
Yes — plenty of organizations run both deliberately, for example HubSpot for marketing with Salesforce as the sales system of record, connected through HubSpot's native Salesforce integration. That's a coexistence architecture rather than a migration, and it comes with its own sync-design decisions. If you're unsure which path fits, resolve that question before starting migration work, not midway through.
Point-in-time history is the hardest thing to carry across. Migrated records arrive with their current state, but stage-transition timestamps that power funnel reports don't rebuild themselves. Common mitigations: import key historical dates into dedicated custom properties, snapshot critical Salesforce reports as archived exports, and accept that rich trend reporting restarts at cutover.
They must be rebuilt as HubSpot workflows — there is no conversion utility that reliably translates one platform's automation into the other's. Treat this as a redesign opportunity: document what each automation is for, drop the ones with no owner or purpose, and rebuild the rest natively so they use HubSpot's model well rather than imitating Salesforce's.
Capable ops teams self-migrate simple orgs regularly. The honest test is the audit: if it surfaces custom objects, multi-system integrations, compliance requirements, or automation nobody fully understands, external experience pays for itself in avoided rework. Even self-migrating teams often bring in help for just the assessment and mapping phases.
Vantage Point implements and supports both Salesforce and HubSpot, which means our migration guidance isn't shaded by a preference for either platform. Our system integration and data migration team runs the full sequence — audit, mapping, staged migration, parallel-run validation, and cutover — with senior consultants only; no junior handoffs. The experts you meet are the experts who deliver. If you're still sizing the effort, start with a migration assessment: it produces the object inventory, risk list, and realistic timeline before any records move.