Associations silently flattened
Contacts arrive, companies arrive, deals arrive — and the relationships between them do not. Every record is technically present and the CRM is functionally useless until someone rebuilds the graph by hand.
Salesforce · HubSpot Migration
Moving CRM is not an export. It is a rebuild with a deadline attached.
Records are the easy part. What breaks a migration is everything that is not a record — associations, activity history, campaign attribution, ownership, and the automations that assumed a field would still be there. We migrate in dependency order and reconcile at every gate.
12,000+
35%
~10%
5
Trusted by 500+ organizations — including B2B SaaS and technology companies running marketing in HubSpot and revenue in Salesforce with Twopir Consulting.
Migration & Data Engineering
- Salesforce Partner
- HubSpot Partner
- Sales Cloud
- Marketing Hub
- Operations Hub
- RevOps
- Marketing Ops
- Sales Ops
The data arrived. Almost everything around it did not.
Migrations rarely fail on record counts — those reconcile. They fail on the things nobody put on the plan. These are the six that cause the most damage, and all six are avoidable.
Activity history left behind
Emails, calls, meetings and notes are treated as optional because they are hard. Six weeks later a rep opens an account with no record of a two-year relationship and stops trusting the system permanently.
Attribution history destroyed
Campaign membership and original source do not survive the move, so every historical cohort analysis and every marketing ROI comparison restarts from zero on go-live day.
Dirty data migrated faithfully
Duplicates, dead records and abandoned custom fields carried across intact — the new platform inherits every problem of the old one, plus the cost of the move.
Ownership arriving unassigned
Owner fields that do not map cleanly leave records unassigned or pointing at a system user. Territory logic, reporting and forecasting all break at once.
Automations pointing at fields that no longer exist
Workflows, validation rules and integrations were built against the old schema. Nobody inventoried them, so they fail after cutover — often silently.
What Migration Means Here
Two different projects that people call by the same name
Migration between Salesforce and HubSpot means moving records, relationships, history and process from one platform to the other as the system of record. It is not the same as integrating the two — an integration leaves both platforms in place and keeps them in step; a migration retires one of them. If both systems are staying, you want the Salesforce HubSpot integration instead, and the work is different.
Salesforce to HubSpot is usually driven by consolidation: a company running marketing in HubSpot decides the CRM overhead of Salesforce is not earning its cost, and moves sales onto HubSpot's CRM. The hard part is process, not data — Salesforce orgs accumulate custom objects, validation rules and Apex that encode years of decisions, and much of that has no direct counterpart.
HubSpot to Salesforce is usually driven by growth: complex territory models, multi-entity structures, CPQ, or compliance requirements that Salesforce serves better. Here the hard part is that Salesforce's object model is stricter, and data that HubSpot tolerated will be rejected on arrival by validation rules and required fields.
Where a migration is a consolidation rather than a replacement — one platform absorbing work the other used to do — the custom object mapping limits and the supported object set are worth confirming against HubSpot's custom object sync documentation before any scope is agreed, because they bound what is even possible.
In both directions the sequence is identical and non-negotiable. Audit and cleanse at source, because migrating dirty data pays to move problems. Architect the target properly, because import-shaped schemas are permanent. Pilot on a real sample — roughly ten percent of production data — before any full load. Migrate parents before children so associations have something to attach to. Then reconcile counts, owners and relationships at every gate, not only at the end.
Twopir Consulting has run this work in both directions as a Salesforce Partner and a HubSpot Partner, for growing and mid-market companies and for enterprise organisations. If a migration is on your roadmap, the target architecture decisions are worth settling before any data moves — and our integration services page covers the case where both platforms are staying.
What migrates cleanly, what needs work, and what does not come with you
The honest version of this table is what separates a migration plan from a migration surprise. Nothing here is unusual — it is simply rarely stated before the project starts.
| What | Difficulty | What actually has to happen |
|---|---|---|
| Contacts, companies, deals | Straightforward | Field mapping and type conversion. The volume is large but the work is well understood. Load parents before children so associations resolve. |
| Associations between objects | Needs care | Relationships are rebuilt from source IDs, which means preserving those IDs through the load. This is the most common thing to discover missing after the fact. |
| Activity history — emails, calls, meetings, notes | Needs care | High volume and awkward mapping. Frequently descoped under time pressure, and the decision should be explicit rather than accidental. Reps notice immediately. |
| Campaign membership and original source | Needs care | Preserving attribution history requires deliberate design before any records move. Retrofitting it afterwards is usually impossible. |
| Custom objects | Depends | Salesforce custom objects may map to HubSpot custom objects on Enterprise, within a limit. Deep, heavily related models often need redesign rather than transfer. |
| Workflows, validation rules, Apex, flows | Rebuilt, not moved | Automation does not migrate in either direction. It is inventoried, evaluated for whether it is still needed, and rebuilt natively in the target. |
| Reports and dashboards | Rebuilt, not moved | Rebuilt against the target schema. Worth treating as an opportunity to retire the ones nobody has opened in a year. |
| Field history and audit trail | Usually not portable | Generally stays with the source. Where retention or compliance requires it, the answer is an archive export, not a migration path. |
The four workstreams every real migration needs
A migration that only plans the data load is planning about a third of the project. These four run in parallel, with dependencies between them.
Source audit and cleansing
Establishing what you actually have before deciding what deserves to move. Consistently the highest-return phase, and the one most often compressed.
- Full object, field and automation inventory
- Duplicate detection and merge before extraction
- Unused field and stale record identification
- Picklist and format standardisation at source
- Archive strategy for records that should not migrate
Target architecture
Designing the destination properly. A schema shaped by what the import file happened to contain is a schema you live with for years.
- Object and property model designed to requirements
- Pipeline and stage architecture
- Lifecycle and status model
- Ownership, territory and permission structure
- Association and hierarchy design
Staged data migration
The load itself, in dependency order, with reconciliation at each stage rather than one reconciliation at the end.
- Pilot load on roughly 10% of production data
- Parent objects before child objects, every time
- Source ID preservation so associations rebuild
- Activity history and attribution continuity
- Record count, owner and association reconciliation per stage
Cutover and stabilisation
The part with the deadline. Planned so that the answer to "can we roll back?" is yes until the moment it deliberately becomes no.
- Cutover runbook with named owners and timings
- Delta load for records changed during the freeze
- Automation and integration re-pointing
- Rollback plan retained through the stabilisation window
- Post-cutover reconciliation and hypercare
Five gates. Nothing passes one until it reconciles.
The gate model exists because migration pressure is always schedule pressure, and the steps people skip under pressure are the ones that cause the damage.
Audit & Cleanse
Inventory every object, field, automation and integration at source. Deduplicate, archive and standardise before extraction — moving dirty data means paying to relocate problems.
Architect the Target
Design the destination schema, pipelines, lifecycle model and ownership structure to your requirements, not to the shape of the export file.
Pilot Migration
Load roughly ten percent of real production data and validate it properly — field values, formats, associations, ownership. Assumptions fail here, cheaply, instead of at cutover.
Staged Load
Full migration in dependency order, parents before children, with source IDs preserved so relationships rebuild. Counts, owners and associations reconcile at each stage.
Cutover & Hypercare
A runbook with named owners, a delta load for anything changed during the freeze, automations re-pointed, and a rollback path retained through stabilisation.
Reconciliation at record level, not at row-count level
The data work on this engagement began the way every migration should: by establishing how much of the source was actually trustworthy.
Delivery Note
The diagnostic surfaced three problems we did not even know we had. By the time we saw the field mapping spec, it was obvious why the previous sync had been silently corrupting data for months. What impressed us most was that every decision was documented — we were not handed a black box. We owned the system at handover.
Twopir Project Lead Delivery reflection · B2B SaaS / cloud infrastructure · North America · 2025 Data Reconciliation
Cloud SaaS Company — ~200 Employees, US
A field-by-field reconciliation across 12,000+ records that quantified 35% divergence before any data work was scoped.
12,000+Records reconciled field by field
35%Contacts diverged at audit
97%Field match after remediation
We have migrated in both directions, which is why we argue about scope early
The uncomfortable conversations in a migration — history, attribution, what gets left behind — are cheap in week one and expensive in week ten.
We scope history and attribution explicitly
Whether activity history and campaign attribution migrate is decided in writing at the start. Descoping them is a legitimate choice; discovering it after cutover is not.
We pilot on real data
A sample of roughly ten percent of production data, validated properly. Assumptions about formats, associations and ownership fail there rather than at go-live.
We migrate in dependency order
Parents before children, with source IDs preserved so associations rebuild rather than flatten. This is the single most common cause of a technically complete, unusable CRM.
We inventory automation before we move data
Every workflow, validation rule, flow and integration pointing at the source schema is listed and evaluated. Automation is rebuilt, never assumed to travel.
We keep the rollback path open
Until stabilisation completes, reverting remains possible. A migration with no way back from day one is a bet, not a plan.
Migration questions, answered before you commit
A straightforward migration of contacts, companies and deals with a clean source and no custom objects is typically four to six weeks including audit, pilot and cutover. Adding activity history, campaign attribution preservation, custom objects and automation rebuilds commonly extends it to ten to sixteen weeks. The largest single variable is not volume — it is how much undocumented automation exists in the source system, which is why the audit gate comes first.
It can, and it is one of the more demanding parts of the project because of volume and mapping complexity. It is also the first thing descoped when a timeline tightens. Our position is that the decision must be explicit and made at the start, because reps notice missing history within days of go-live and their trust in the new system does not recover easily. If it is being descoped, that should be a business decision with an archive plan attached, not a discovery.
Only if attribution preservation is not designed before records move. Campaign membership and original source have to be mapped deliberately into the target model, and that design has to exist before the load rather than after it. Retrofitting attribution once records are in the target is usually impossible, which makes this one of the few genuinely irreversible decisions in a migration.
No, in either direction. Salesforce flows, validation rules and Apex have no HubSpot counterpart, and HubSpot workflows have no Salesforce counterpart. Automation is inventoried at source, evaluated for whether it is still needed — a meaningful proportion usually is not — and then rebuilt natively in the target. Budgeting for a like-for-like rebuild of everything that exists is the most common way migration estimates go wrong.
Before, without exception. Migrating duplicates and dead records means paying to move problems into a system where they are harder to fix, and it inflates the volume the migration has to handle. Deduplication, archiving of stale records and picklist standardisation all happen at source, during the audit gate, before anything is extracted.
For a period, yes, and it is often sensible — a parallel run lets teams validate the target against the source with real work rather than test scripts. It requires a clear rule about which system is authoritative during the window, and a delta load at the end to carry across anything changed in the source during the freeze. What does not work is an open-ended parallel run with no cutover date, which produces two half-maintained systems.
That is a recoverable position and a reasonable share of the migration work we do. We reconcile the target against the source to establish exactly what is missing or misassociated, then remediate in dependency order — usually associations first, since they are what makes the rest usable. The recovery is more constrained than doing it correctly the first time, but it is rarely a rebuild.
Next Step
Scope the migration properly before the timeline scopes it for you
The decisions that matter — history, attribution, what gets left behind — are cheap to make now and expensive to discover later. Start with the audit.
Salesforce Partner · HubSpot Partner · Serving US, Canada, UK, UAE, Australia & New Zealand
