Most Salesforce-to-HubSpot migrations get scoped as a mapping exercise. Someone exports the Salesforce field list, pastes it next to the HubSpot property list, draws lines between the two, and books an import window. That is not a migration; it is a translation of the existing tech debt into a new dialect. The actual work of moving from Salesforce to HubSpot is field-level triage, deciding, one row at a time, whether a field gets a HubSpot home, gets transformed first, or does not survive the cutover. The mapping spreadsheet is the output of that decision. It is not the decision itself.
Why this matters now
Salesforce instances at the Series B stage and beyond carry hundreds of custom fields, and the field count is the smaller part of the problem. The bigger part is that less than half of the structured data on those fields is actively used in any decision, a finding documented in Harvard Business Review's data-strategy work and one that has aged well in the years since. A field-by-field lift to HubSpot ports the unused half along with the useful half, and then the team carries the dead weight forward into the new platform. The migration window is the only moment in the lifecycle of the CRM where deleting a field is cheap. Skip it, and the next person to touch the schema is fighting the inheritance, not building forward.
The triage spreadsheet, not the mapping doc
The artifact that drives a Salesforce-to-HubSpot migration is a spreadsheet with one row per Salesforce field and three decision columns: keep, edit, delete. This is the same keep / edit / delete frame that governs the broader brownfield audit on an inherited instance, but pointed at a narrower target, the field, not the workflow or the report. The instance-level version of the same frame lives in our companion piece on inheriting a HubSpot or Salesforce instance. For each field the row records the Salesforce API name, the field type, the population rate against records modified in the last ninety days, the proposed HubSpot property, the transform, and the named owner who signs the row off.
A typical mid-stage Salesforce instance triages to roughly a third deleted, a quarter edited, and the remainder kept as-is. The numbers are less important than the discipline, every field is a decision, and every decision has a name next to it.
Salesforce field types vs HubSpot property types
The two systems do not share a type system, and the mismatches are where most field-level migration mistakes get made. The categories that actually matter:
Picklists vs. dropdown / radio / checkbox
Salesforce multi-select picklists do not have a clean HubSpot equivalent. HubSpot multi-checkbox properties cover the structural case, but record-type-specific picklist values in Salesforce often expand into separate properties on HubSpot when the values are not actually shared semantics. The migration moment is the moment to consolidate. Picklists with more than twenty values, half of which have not been selected in the last six months, get edited down to the values that show up on real records.
Formula fields
Salesforce formula fields do not migrate. They get unwound into one of three things in HubSpot, a calculation property if the formula is a pure function of other properties on the same record, a workflow that writes to a regular property on a trigger, or a deletion if the underlying logic is no longer needed. The diagnostic is whether the formula reads from fields that are themselves keeps, edits, or deletes. A formula field whose inputs are all going to delete is a delete by transitivity.
Lookup and master-detail relationships
Salesforce lookups translate to HubSpot associations, but the translation is not 1:1. HubSpot association labels carry semantics, "primary signer" vs. "economic buyer" vs. "champion", that Salesforce often encodes as a custom lookup field with a role picklist on the side. The clean migration consolidates the lookup-plus-role pattern into a single labelled association, which is shorter to maintain and less brittle to report against. Master-detail relationships flag a different question, whether the child object should be a HubSpot custom object at all, or whether the records belong on a different standard object with the parent as an association.
Owner, queue, and sharing-rule fields
Salesforce sharing rules and queue ownership often hide visibility logic inside fields that look innocuous on paper. "Account Region," "Deal Pod," and "Owner Role" frequently exist not to report against, but to drive a sharing rule three layers down. Before deleting any of them, trace the sharing-rule blast radius. HubSpot's permission model is shallower and more declarative; some of these fields disappear into team membership and partition rules in the new system, but only after the dependency is mapped.
The historical-data question
Every Salesforce-to-HubSpot migration runs into the question of how much history to bring across. The honest answer is rarely all of it. The default we hold to is the most recent ninety days of activity history, the full lifecycle of any open opportunity regardless of age, and the closed-won record of any deal still on a renewal cycle. Everything else stays in a Salesforce read-only archive that the team can reference but cannot edit. The reason to draw the line tight is that historical activity data is the largest contributor to migration time and the smallest contributor to forward-looking decisions. A team that imports five years of activity tasks from former reps gets a slower HubSpot instance and roughly the same forecast accuracy.
Pattern from the field
A B2B SaaS team in EMEA at the Series B stage came to us mid-migration with a Salesforce instance carrying just over six hundred custom fields across the Account, Contact, and Opportunity objects. The original scope had been a 1:1 field map: every Salesforce field gets a HubSpot property, the import runs, the team retrains. The first triage pass marked roughly thirty-five percent of the fields for deletion outright, most of them custom fields populated on a few hundred records years ago for a campaign nobody on the current team remembered. Another twenty-five percent were edits, picklist consolidations, formula unwinds, lookup-to-association translations, and a handful of date fields that needed to land in HubSpot's stricter time-zone handling. The remaining forty percent kept as-is. The HubSpot portal went live with around two hundred and forty custom properties, a surface area the team could actually maintain, and the first quarter of forecasting on it was the first in two years that did not need a manual data-integrity pass before the call.
Resolution, the triage playbook
For any team about to run a Salesforce-to-HubSpot migration:
- Pull the field inventory before you draw any mapping lines. One row per Salesforce custom field on every standard and custom object. Include API name, field type, population rate on records modified in the last ninety days, and the dependent metadata: workflow rules, validation rules, formula references, sharing rules.
- Run the keep / edit / delete pass. Every row gets a decision and a named owner. Fields with population below ten percent on recent records default to delete unless someone defends them in writing.
- Consolidate picklists before mapping. Edit picklist values down to what shows up on real records, then map the consolidated list to HubSpot. Don't import dead values.
- Unwind formula fields into calculations, workflows, or deletes. No formula field migrates as-is. Every one gets re-implemented, re-routed, or dropped.
- Translate lookups into HubSpot association labels. Lookup-plus-role patterns collapse into labelled associations. Custom objects only earn the trip if the data model genuinely needs them on the HubSpot side.
- Map sharing-rule blast radius before deleting any visibility-bearing field. Owner, region, pod, and role fields that drive Salesforce sharing rules cannot just disappear; they translate into HubSpot teams, partition rules, or role-based permissions, and the translation is documented per field.
- Sign off the spreadsheet before the import runs. The triage spreadsheet is the cutover artifact. The HubSpot import is a function of that spreadsheet, not a parallel exercise. If a field is not signed off, it does not move.
Steps one through seven are eighty percent of the project. The actual import is a Friday afternoon.
Where Checkpoint comes in
Field-level triage is the work that determines whether a Salesforce-to-HubSpot migration ships clean or ships the same instance under a new logo. We run this exercise on every CRM migration we touch, and it is the spine of how we approach HubSpot implementations downstream of a legacy system. If the triage is the project, the operating model that uses the resulting instance is what makes it durable, that is the revenue operations work that follows. If you are scoping a Salesforce-to-HubSpot move and the conversation is starting from a mapping spreadsheet, talk to us before the import window is booked.
Sources
- "What's Your Data Strategy?" Harvard Business Review, May–June 2017. hbr.org
- Lemkin, Jason. "Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, April 2026. saastr.com