A Salesforce to HubSpot migration is two projects running at once: moving the records, and rebuilding the logic around them. Records move. Automation, permissions, reports, and integrations do not carry over as-is. Teams that treat it as a data export lose pipeline history, break associations, and spend the next quarter explaining why the numbers changed.
This guide covers what moves and what does not, the order to load data in, how to preserve pipeline history, how long CRM migration planning realistically takes, and how to validate that nothing was lost. It is written for B2B SaaS revenue operations leaders who need reporting to stay continuous through the cutover.
The short version: Plan 8 to 12 weeks for a typical B2B SaaS migration. Design the HubSpot data model before you extract anything. Store the Salesforce ID on every record. Load in dependency order. Reconcile counts and dollar totals before cutover. Carry original dates and stage history in dedicated properties instead of trusting HubSpot to reconstruct them.
What moves, and what does not
| Salesforce | HubSpot | Decide before you load |
|---|---|---|
| Account | Company | Domain is HubSpot's unique key. Accounts without one need the Salesforce ID as their identifier. Plan for parent and child hierarchies. |
| Contact | Contact | Email is the default unique key. Contacts without email need the Salesforce ID. |
| Lead | Contact (lifecycle stage Lead) | Do not import a converted lead and its resulting contact as two people. |
| Opportunity | Deal | Map every stage and pipeline first. Closed deals move too. |
| Opportunity contact roles | Deal-to-contact associations | Association labels require Professional or Enterprise. |
| Tasks, events, calls, emails, notes | Tasks, calls, meetings, emails, notes | Import creates new activities and cannot update existing ones, so a bad load means duplicates. |
| Products, quotes, CPQ | Products, line items, quotes | CPQ rarely maps cleanly. Scope it as its own workstream. |
| Custom objects | Custom objects | Enterprise only. Otherwise flatten them into properties on existing objects. |
| Flows, Apex, validation rules, reports | Workflows, property rules, reports | Rebuild from requirements. Do not port line by line. |
The migration in seven steps
- Inventory and cut. Export record counts and field fill rates per object. Fields populated on fewer than 5 percent of records, and records with no activity in three or more years, are candidates for the archive instead of the migration. Less to move means less to validate. If the source instance is messy, clean up what you can first.
- Design the HubSpot model first. Write the properties, pipelines, lifecycle stage definitions, and associations before extracting anything. Copying Salesforce's structure unchanged turns a five-year-old mess into a new five-year-old mess. If your lifecycle definitions are unclear, fix those first.
- Build the field mapping document. One row per field: Salesforce API name, type, target HubSpot property, transformation rule, and validation check. Picklists need a value-by-value map. The field mapping checklist has the full template.
- Add the migration key. Create a unique-value property for the 18-character Salesforce ID on companies, contacts, and deals. HubSpot can use unique-value properties as import identifiers, which makes every load repeatable and every association rebuildable. Never match on names.
- Load in dependency order. Users and owners first, then companies, contacts, deals, associations, products and line items, and activities last. Records pointing to an owner who does not exist yet typically arrive unassigned. Load activities once, after testing a sample, because import cannot update existing activities.
- Reconcile before cutover. Compare record counts per object, open pipeline by stage and owner, closed-won revenue by year, and association counts. Then read 50 to 100 random records side by side. Counts should match except for documented exclusions. Dollar totals should match exactly.
- Run in parallel, then cut over. Run both systems for two to four weeks, freeze Salesforce edits, load the delta, turn off any sync between the two, and archive a final Salesforce export. Confirm the export window your contract allows before you set the date.
How to preserve pipeline history
Pipeline history is the first thing migrations lose, because it lives in system-generated fields that imports do not control. Handle five things deliberately.
- Closed deals move too. Won and lost deals, with amount, owner, source, and lost reason, are the only way to trend win rate and sales cycle across the cutover.
- Original dates get their own properties. Depending on the import method, HubSpot's create date can reflect when a record entered HubSpot instead of when it was created in Salesforce. Test this in a sandbox, then store Salesforce Created Date and Salesforce Close Date in dedicated custom date properties so reporting never depends on it.
- Stage history is carried, not reconstructed. HubSpot's time-in-stage reporting reflects movement that happens inside HubSpot. Pull stage changes from Salesforce's OpportunityHistory and store the milestone dates your reports need (created, qualified, proposal, closed) as custom properties. Keep the full history in the archive.
- Forecast fields need translating. Probability and forecast categories differ between the two systems. Map them explicitly, and snapshot the open pipeline on cutover day as your baseline.
- Quarter boundaries are fragile. A close date that shifts by one day or one time zone can move a deal into the next quarter and change a board number. Check every close date near a quarter end during reconciliation.
How long it takes
Moving records takes days. Everything around the records takes the time.
| Scope | Typical timeline |
|---|---|
| Standard objects, one pipeline, light automation | 4 to 6 weeks |
| Multiple pipelines, 20+ workflows, several integrations, history preserved | 8 to 12 weeks |
| CPQ or quote-to-cash, custom objects, multi-currency, multiple business units | 12 to 20 weeks |
Four things move these ranges: how much automation needs rebuilding, how many integrations connect to the CRM, the data quality you start with, and how fast stakeholders settle mapping decisions. Do not let the Salesforce renewal date set the cutover date. Start at least a quarter before it. A RevOps audit before the project surfaces most of the scope risks while they are still cheap to fix.
Three ideas worth borrowing from outside CRM
Strangler fig, from software modernization. Instead of switching everything over one weekend, move one segment at a time: marketing first, then one sales team or pipeline, then the rest. Each phase proves the mapping on a smaller blast radius.
Chain of custody, from evidence handling. Log every export file: who ran it, when, the row count, and a checksum. When a number disagrees later, you can show whether the loss happened at extraction, transformation, or load.
Go/no-go criteria, from launch operations. Agree on numeric cutover thresholds (counts, dollar totals, error rate) before the project starts, not on cutover night when everyone wants to say yes.
Where migrations quietly lose data
- Converted leads imported as both a lead and a contact, creating duplicate people.
- Contacts with no email, which need the Salesforce ID as an identifier or they cannot be deduplicated cleanly.
- Picklist label and API value mismatches that load as blanks.
- Inactive Salesforce users whose records arrive with no owner.
- Activity imports run twice, doubling every note and call.
- Currency conversion and rounding on multi-currency deals.
Frequently asked questions
- How long does a Salesforce to HubSpot migration take?
- Four to six weeks for standard objects with one pipeline. Eight to twelve for a typical B2B SaaS team with multiple pipelines, workflows, and integrations. Twelve to twenty when CPQ, custom objects, or multiple business units are involved. The records move quickly. The automation rebuild and mapping decisions take the time.
- Can you keep pipeline history when you migrate from Salesforce to HubSpot?
- Yes, with planning. Closed deals, amounts, owners, sources, and lost reasons migrate as records. Original dates and stage-entry dates should be stored in dedicated custom properties, because HubSpot's native time-in-stage reporting reflects movement inside HubSpot.
- What is the best way to avoid data loss in a CRM migration?
- Write the field mapping before extraction, store the Salesforce ID on every record as a unique identifier, load in dependency order, and reconcile record counts and dollar totals against Salesforce before cutover. Keep a full Salesforce export as an archive.
- Do Salesforce workflows and reports migrate to HubSpot?
- No. Records and properties migrate. Flows, Apex, validation rules, reports, and dashboards must be rebuilt in HubSpot from requirements. The rebuild is also your chance to retire logic nobody uses.
- Can Salesforce custom objects move to HubSpot?
- Yes, but custom objects in HubSpot require an Enterprise subscription. On lower tiers, flatten them into properties on existing objects, or decide whether that data belongs in the CRM at all.
- Should you migrate all at once or in phases?
- Phases reduce risk for larger teams: move one segment or pipeline, validate, then continue. A small team with one pipeline can cut over in a single weekend after a parallel run.