Chapter 01
Why teams move from Salesforce to HubSpot, and when not to
Most Salesforce to HubSpot migrations are not really about the software. They are about a team that has outgrown a system it never fully adopted. Admin work piles up, reports take a specialist to build, and the tools that were supposed to align sales and marketing quietly drifted into two separate worlds. HubSpot wins these evaluations when a company wants one connected platform that its own people can actually operate, without a full-time administrator for every change.
The honest version: HubSpot is the right move when you value speed of adoption, a unified view across marketing, sales, and service, and lower total cost of ownership. It is the wrong move if you have deep, business-critical customizations that only Salesforce supports, or a large team that has truly mastered Salesforce and would lose more in retraining than it gains. A good partner tells you which camp you are in before a single record moves. Migrating for the wrong reason is the most expensive mistake in this entire process.
This playbook is the sequence INSIDEA uses as an Elite HubSpot Partner with HubSpot's CRM Data Migration accreditation. It assumes you have decided to move and want to do it without losing history, breaking reporting, or stalling the team.
Here is the whole migration at a glance, before we go phase by phase.
Salesforce to HubSpot · staged migration
No history lost
Chapter 02
What actually has to move: the object inventory
A migration is not a copy. Salesforce and HubSpot model the world differently, so the first real task is deciding what each Salesforce object becomes on the other side. The biggest conceptual shift is the Lead. Salesforce treats leads as a separate object; HubSpot does not. In HubSpot, a lead is simply a contact at an early lifecycle stage. That single difference reshapes how you think about routing, reporting, and conversion.
| In Salesforce | Becomes in HubSpot | Watch for |
|---|
| Lead and Contact | Contact (with lifecycle stage) | No separate Lead object; lead conversion logic must be rebuilt as lifecycle stages |
| Account | Company | Association and hierarchy rules differ |
| Opportunity | Deal | Stages and probabilities remap to your HubSpot pipeline |
| Opportunity product / line item | Line item on a deal | History does not backfill automatically, see chapter five |
| Case | Ticket | Service Hub pipelines and SLAs |
| Campaign | Campaign, lists, and source data | Attribution model is different |
| Task, Event, Activity | Calls, meetings, tasks, emails | Timeline and ownership must be preserved |
| Custom object | Custom object | Requires the right HubSpot tier and schema design |
| User | User and record owner | Owner mapping drives routing and reporting |
Write this inventory down for your own instance, object by object, before anything else. Every downstream decision, from field mapping to the order records are imported, depends on it.
Chapter 03
Before you touch a record: the pre-migration audit
The quality of a migration is decided before the first import, in the audit. Salesforce instances accumulate years of duplicates, dead records, unused fields, and undocumented automations. Move all of it and you have simply paid to relocate your mess, then built reports on top of duplicates and stale data. The audit is where you decide what deserves to make the trip.
The four questions the audit answers
- What is worth keeping? Segment records by recency and value. Active accounts and open pipeline move first. Dormant records from years ago are candidates to archive, not migrate.
- Where are the duplicates? Deduplicate in Salesforce, or plan a merge strategy, before import. A clean source is cheaper than a clean-up after.
- Which fields are actually used? Most Salesforce orgs have far more fields than anyone reports on. Migrate the ones that carry meaning; leave the graveyard behind.
- What automations depend on this data? Workflows, validation rules, and integrations that fire on Salesforce records need HubSpot equivalents, or a deliberate decision to retire them.
This is also the moment to agree on definitions. What counts as a lead, a marketing qualified lead, an open opportunity, and closed won should mean the same thing to everyone before those meanings get hard-coded into a new system. Configuration before strategy is the classic migration failure. Strategy first.
Chapter 04
Mapping Salesforce to HubSpot: objects, fields, and associations
With the inventory and audit done, mapping is where the migration becomes concrete. For every object you are keeping, each Salesforce field maps to a HubSpot property: a standard property where one exists, a custom property where it does not. Field types matter. Salesforce picklists become HubSpot dropdown or radio properties with matching options, dates map to date properties, and formula fields usually need rethinking, because HubSpot calculates differently.
Associations are the part most DIY migrations underestimate. A record is only useful if it keeps its relationships: the contact tied to the right company, the deal tied to the right contacts, the activities tied to the right owner and timeline. If associations break during import, you do not lose data so much as lose the story the data tells. Preserving association keys through the import is a deliberate design step, not something that happens by default.
For teams running both systems during the transition, the HubSpot Salesforce integration keeps records in sync once they exist in both. It is a sync layer, not a migration tool, which is why the sequence in the next chapter matters so much.
Chapter 05
The migration sequence that protects your history
Order is everything. Records have dependencies: a deal needs its company and contacts to exist first, or the associations have nothing to attach to. The sequence that protects history looks like this.
| Phase | What happens | Typical time |
|---|
| 1. Audit and mapping | Inventory objects, map fields, agree definitions, plan deduplication | 1 to 2 weeks |
| 2. Build and configure | Properties, pipelines, lifecycle stages, and workflows built in HubSpot | 1 to 3 weeks |
| 3. Historical import | Bulk import in dependency order: companies, then contacts, then deals and line items, then activities | 1 to 2 weeks |
| 4. Sync and parallel run | Turn on the Salesforce integration for ongoing sync, validate record counts and associations | 1 to 2 weeks |
| 5. Cutover and adoption | Switch the source of truth, train the team, decommission Salesforce | 1 week and up |
Two facts from HubSpot shape this sequence. First, HubSpot's standard CSV import handles up to 10,000 records per object per file, so larger objects are split or moved through the API. Second, the native Salesforce integration keeps records in sync but does not backfill history, so historical data is bulk-imported first and the sync is switched on afterward to carry ongoing changes. Reverse that order and you get gaps.
Line items deserve a specific callout. The native integration does not retroactively attach historical products to existing deals, so if past deal value and product mix matter to your reporting, line-item history is handled as a dedicated import step with its own mapping, not left to the sync.
Where the native integration stops, and API work begins
The native Salesforce integration is a sync tool, not a migration engine, and knowing where it stops is what separates a clean move from a stalled one. Low-volume moves with clean data can lean on it. Anything with real history, custom objects, large volumes, or complex mapping needs the HubSpot API and custom work, which is where our Custom Integration accreditation earns its keep.
What the native integration handles
- Ongoing two-way sync of standard objects once they already exist in both systems
- Contacts, companies, deals, and activities kept current, re-checked about every 15 minutes
- Field-level mapping for the properties you choose to sync
- Inclusion rules so only the records you want cross over
What needs the API or a custom build
- Historical data at volume, past the standard import cap of 10,000 records per object
- Historical line items and past deal value, which the sync does not backfill
- Custom objects and non-standard relationships
- Attachments, notes, and call activity at scale
- Complex field transformations and preserving associations across large record counts
Chapter 06
Cutover: running both systems without chaos
The riskiest day is the one where the source of truth changes hands. Done well, cutover is a planned, boring event. Done badly, it is the week two systems disagree and the team loses trust in both. The safeguard is a parallel run: for a defined window, historical data lives in HubSpot, the integration keeps both systems current, and you validate that counts, associations, and key reports match before you commit.
Set exit criteria in advance. Record counts reconcile within an agreed tolerance, a sample of high-value accounts and deals is verified by hand, owners and pipelines are correct, and the reports leadership actually uses return the same numbers they did in Salesforce. Only when those criteria are met do you name HubSpot the system of record and stop writing to Salesforce. A cutover without written exit criteria is a guess.
Chapter 07
The first 30 days after cutover
Migration does not end at cutover; that is where adoption begins. A technically perfect migration still fails if the team keeps working the way they did in Salesforce, or worse, quietly keeps a spreadsheet on the side. The first 30 days are about making HubSpot the obvious place to work.
- Rebuild the reports leadership relies on first, and confirm the numbers match the pre-migration baseline. Trust in the data is won or lost here.
- Train by role, not by feature. Reps need their daily workflow; managers need pipeline and forecast; marketing needs lifecycle and attribution.
- Watch adoption signals: logins, records updated, deals moving stages. Silence is a warning, not a success.
- Keep a fast feedback loop open for the first month so small friction points get fixed before they become reasons to disengage.
Adoption as an afterthought is the quiet killer of CRM projects. Build the change plan into the migration from day one, not after go-live.
Chapter 08
Where DIY migrations break, and how we prevent it
The failure patterns are consistent enough to name. Almost every troubled Salesforce to HubSpot migration traces back to one of these.
!
Configuration before strategy
Building inside the tool before agreeing what a lead, a stage, and closed won actually mean. The fix is definitions first.
!
Dirty data carried over
Migrating everything so nothing is lost, then reporting on duplicates and dead records. The fix is the audit and a deliberate keep-or-archive call.
!
Broken associations
Records arrive but lose their relationships, so the history is present but useless. The fix is designing association keys into the import.
!
Wrong sequence
Turning on the sync before importing history, or importing deals before their companies exist. The fix is dependency-ordered phases.
!
Adoption as an afterthought
A perfect build no one uses. The fix is a role-based change plan that starts before cutover, not after.
!
Automating a broken process
If a person cannot run the process by hand, a workflow will only run it faster and wronger. Fix the process first.
None of these are exotic. They are the predictable result of treating a migration as a data-transfer task rather than an operating-model change. Treat it as the latter and most of the risk disappears.
Chapter 09
How INSIDEA runs a Salesforce to HubSpot migration
INSIDEA is an Elite HubSpot Partner, rated 4.99 out of 5 across 450+ verified reviews, and we hold HubSpot's CRM Data Migration accreditation, one of five accreditations we carry. We have run this move for companies from early stage to enterprise, and the method above is the one we use, not a generic checklist.
What that looks like in practice: we start with the audit and the definitions, not the tool. We map every object and field before we build, design the import to preserve associations and history, run a validated parallel period rather than a big-bang switch, and treat adoption as part of the project rather than a handoff at the end. Because we build across CRM, RevOps, growth marketing, and AI, the HubSpot you land on is set up to grow, not just to receive your old data.
If you want this run as a system rather than a side project, see how we approach HubSpot implementation, or book a strategy call and we will scope your migration against the sequence above.
Chapter 10
Questions people ask
How long does a Salesforce to HubSpot migration take?
Most mid-market migrations run six to twelve weeks end to end, but the driver is the state of your Salesforce data and the number of connected systems, not the number of HubSpot Hubs. A clean single-instance move can finish near the short end; an org with years of duplicates, custom objects, and undocumented integrations runs longer, because reconciling the old system consumes the calendar. The audit in chapter three is what lets you forecast this honestly.
Will we lose our Salesforce history?
Not if the migration is sequenced correctly. Historical records are bulk-imported into HubSpot first, in dependency order, with associations and timelines preserved. The common way history gets lost is turning on the native Salesforce sync before importing history, because the sync keeps records current but does not backfill the past. Line items on historical deals are handled as a dedicated import step, since the sync does not attach them retroactively.
Can we run Salesforce and HubSpot at the same time during the switch?
Yes, and for most teams you should. A parallel run is the safest cutover: historical data lives in HubSpot, the native integration keeps both systems in sync during the transition, and you validate record counts, associations, and key reports before naming HubSpot the system of record. You only stop writing to Salesforce once written exit criteria are met.
What happens to custom objects and line items?
Custom objects migrate to HubSpot custom objects, provided your HubSpot tier supports them and the schema is designed deliberately rather than copied one to one. Line items map to line items on deals, but their history does not backfill through the native sync, so past product and deal value are imported as a specific step with their own mapping. Both are common places DIY migrations lose data quietly.
Do we have to rebuild our reports?
Most reports are rebuilt in HubSpot, because HubSpot models leads, attribution, and calculated fields differently from Salesforce. This is a feature of the move, not a bug: it is the moment to fix reports that were confusing or wrong in Salesforce. The rule we follow is to rebuild the reports leadership actually uses first and confirm the numbers reconcile with the pre-migration baseline before cutover.
Should we migrate off Salesforce ourselves or use a partner?
A small, clean instance with few integrations can be moved in-house using HubSpot's import tools and switch resources. The case for a partner grows with data volume, custom objects, connected systems, and how much your reporting depends on history. An accredited partner earns its fee by preventing the expensive failures, broken associations, dirty data, wrong sequencing, that are hard to see until after go-live.
How INSIDEA works
