HubSpot to Salesforce
HubSpot to Salesforce with the object graph intact — every association resolved to a real parent, and a per-record account of what landed.
- Moving from
- HubSpot
- Moving to
- Salesforce
- What you get
- A per-record account of what landed, and what did not
- Agreed up front
- 5 known exclusions, before any work starts
How we get the data out of HubSpot
Getting the data out of HubSpot is rarely the hard part. Reconciling two systems that model relationships differently is where the work actually is.
What we need from you before we start
- Read access to every record type in scope, granted by a HubSpot administrator
- A Salesforce account that can write every field we are mapping — Salesforce silently leaves fields empty when the account lacks permission, without raising any error
- One new field on each Salesforce object to hold its original HubSpot identifier — a small setup change your administrator makes
- A list of the validation rules, duplicate rules and automation active in your Salesforce, so we can agree what stays on during the load
What comes across
The extraction is straightforward and the load is not. HubSpot’s association model does not map cleanly onto Salesforce relationships, Salesforce silently drops fields the integration user cannot write, and validation rules written years after the data was created will reject records that were perfectly valid in HubSpot. Most of the engagement is spent on that reconciliation, which is exactly the part a script skips.
Comes across
- Companies, contacts, deals and the relationships between them
- Record ownership, so sharing and forecasting keep working
- Custom properties, mapped one by one to their destination equivalents
- Activity history, within what Salesforce can represent
- The original HubSpot identifiers, kept for traceability
Doesn’t come across
- HubSpot associations and Salesforce relationships are not the same model. Association labels and many-to-many associations have no direct Salesforce equivalent and need an explicit mapping decision per object pair, agreed before load.
- HubSpot engagements — emails, calls, meetings, notes — map onto Salesforce Tasks and Events with real fidelity loss. What survives is decided at scoping, not discovered afterwards.
- Property history and lifecycle-stage timestamps rarely survive without purpose-built custom fields on the Salesforce side.
- HubSpot custom objects are an Enterprise-tier feature. Where your tier lacks them, the equivalent data usually lives in properties that need remodeling rather than mapping.
- Salesforce Field-Level Security, validation rules and duplicate rules can each cause records or individual fields to be rejected or silently emptied. We inventory all three before loading and verify by reading records back.
Every one of these is identified during scoping and agreed with you before the migration runs. The field-by-field detail sits in your scoping document, where it can be discussed rather than skimmed.
Questions people ask about this migration
Moving from HubSpot?
Send us a rough record count and we’ll come back with a scope, a timeline, and the exclusions we’d expect — before you commit to anything.