HubSpot Migration: Moving from Salesforce or Pipedrive Without Losing Your Data

A HubSpot migration moves your CRM data — contacts, companies, deals, activity history, and automation logic — from a legacy system like Salesforce or Pipedrive into HubSpot without breaking pipeline reporting or losing history. Done well, it takes four to eight weeks and starts with an audit of the legacy system, not an export. The transfer itself is the easy part; failures happen in mapping decisions, silent breakage of attribution and automation, and skipped validation.

We've handled migrations in both directions and audited plenty done by others, and the pattern is unmistakable: nobody loses data in the dramatic, headline sense. They lose meaning — a Salesforce Lead becomes a contact with no lifecycle context, five years of attribution collapses into one import date, workflows fire into a structure they weren't built for. This guide covers when migrating makes sense, the mapping traps, what silently breaks, and the checklist that prevents the expensive version of learning all this.

When Does Migrating to HubSpot Make Sense?

Migrating to HubSpot makes sense when your legacy CRM's cost or complexity outweighs its use — typically Salesforce orgs paying for far more platform than the 20% of features they actually use, or Pipedrive teams that have outgrown a sales-only tool and need marketing, automation, and reporting in one platform. It does not make sense as a way to escape dirty data or broken process; those migrate with you unless you fix them first.

The honest decision criteria we walk clients through:

Migrate when:

• Your Salesforce admin burden (admin headcount, consultant retainers, config debt) exceeds the value of the customization it maintains. A common profile: a 120-person company carrying heavyweight Salesforce licensing plus a full-time admin to maintain automations HubSpot ships out of the box.
• Marketing lives in a separate tool and the CRM sync is a permanent source of arguments about lead counts.
• Pipedrive (or Zoho, or a spreadsheet) got you to your first million, but you now need lead scoring, attribution, and lifecycle reporting it can't do.
• Adoption has failed: reps update the CRM under duress. HubSpot's usability advantage is real, and it's the most legitimate "soft" reason to switch.

Don't migrate when:

• Your problem is data hygiene or process discipline. A migration faithfully transfers your mess at considerable cost — fix the process first (our CRM best practices guide covers the baseline).
• You depend on deep Salesforce-native customization (complex CPQ, industry clouds, stacks of managed packages) HubSpot genuinely can't replicate. Verify replacements exist before you commit.
• You're mid-quarter with the pipeline on fire. Migrations need a stable window.

A useful litmus test: if you can't state the payoff in a sentence that mentions money or hours ("we cut six figures in licensing and admin" / "reps save five hours a week"), you're not ready to scope it.

Book a free HubSpot audit. No onboarding calls, no meetings — click our invitation link to grant partner access to your portal, and we'll send you a full list of improvements within days.

Start With a Pre-Migration Audit of Your Legacy CRM

Every successful HubSpot migration starts with an audit of the legacy system: an inventory of objects, fields, automation, integrations, and reports, plus a ruthless decision about what deserves to move at all. Migrating everything is the default choice of teams that haven't looked at their data — typically 30–50% of legacy fields are empty, duplicated, or unused, and dragging them across guarantees a cluttered portal from day one.

What the audit must produce:

• Object and record inventory. Counts by object (leads, contacts, accounts, opportunities, custom objects), record age distribution, and duplicate estimates. Decide your archive line — records untouched in 3+ years often belong in a cold-storage export, not your new portal.
• Field census. Every field per object with fill rate. In a recent Salesforce audit for a 200-person client we found 447 contact fields; 61 were in active use. The other 386 did not migrate, and nobody has asked for one since.
• Automation map. Every workflow, flow, Apex trigger, or Pipedrive automation: what it does, whether it still should, and what replaces it in HubSpot workflows. Automations are rebuilt, never copied — the map is the spec.
• Integration register. Everything reading from or writing to the CRM: marketing tools, billing, support desk, enrichment, Zapier jobs, custom scripts. Each needs a re-point plan and an owner.
• Report inventory. The 10–20 reports leadership actually opens — these are your acceptance criteria. If the pipeline report can't be reproduced post-migration, the migration isn't done.
• Ownership and security model. Teams, territories, and visibility rules — HubSpot's permission model differs enough from Salesforce's to need deliberate translation.

This audit doubles as the scope document for the whole project — it's the same discipline we apply in any CRM implementation, just pointed at the outgoing system.

Data Mapping Pitfalls: Legacy Concepts vs. HubSpot Equivalents

The core mapping problem is that legacy CRMs and HubSpot model the same reality differently — Salesforce splits Leads from Contacts while HubSpot uses one contact object with lifecycle stages, and Pipedrive organizes everything around deals. Every mismatch is a decision, and unmade decisions become data losses that surface months later in broken reports.

The traps we see most, by concept:

Legacy concept	HubSpot equivalent	The gotcha
Salesforce Leads + Contacts (two objects)	One contact object + lifecycle stages	Merging two objects creates duplicates (same person as Lead and Contact) and loses the distinction unless encoded as lifecycle stage + a "migrated as" property. Dedupe by email before import.
Salesforce Opportunities + record types	Deals + pipelines	Each record type/process usually becomes its own pipeline. Stage probability, forecast categories, and stage history don't map 1:1 — design deal stages fresh, then map old stages into them.
Salesforce custom objects	HubSpot custom objects (availability depends on your HubSpot subscription) or associations/properties	Custom objects aren't included in every HubSpot plan — verify yours supports them before assuming a 1:1 move. If it doesn't, you're remodeling into properties or associations — decide per object whether the structure earns its complexity.
Activity history (calls, emails, notes, tasks)	Timeline engagements	The highest-effort, most underestimated item. Emails logged via Salesforce may lack clean threading; imported activities need correct timestamps and associations or the timeline is chronological soup. Budget real engineering time here.
Salesforce Campaigns + member status	Marketing events / static lists / custom properties	Campaign membership history rarely maps cleanly. Preserve it as list memberships or a multi-checkbox property, or accept its loss explicitly — don't let it vanish by omission.
Pipedrive deal-centric contacts	Contact-centric model	Pipedrive people without deals often have thin data; HubSpot expects contacts to carry lifecycle meaning. Backfill lifecycle stage on import or every report segmented by stage starts wrong.
Owner records / inactive users	HubSpot users	Records owned by deactivated users need a reassignment rule pre-import, or thousands of records land unowned and rot.
Picklists with 10 years of drift	Dropdown properties	Consolidate values before migration ("NY", "New York", "new york" → one value). Mapping garbage to garbage is the most common silent quality failure.

Two universal rules. First, map meaning, not fields: the question is never "where does Lead Status go?" but "how do we represent qualification in HubSpot's model?" Second, every field either has a mapped destination, an archive plan, or a documented decision to drop it. "We forgot about it" is the only unacceptable category.

What Silently Breaks During a HubSpot Migration

The dangerous migration failures are the silent ones: attribution history collapses because every record's "create date" becomes import day, automation logic disappears because workflows can't be exported, and integrations keep writing to the old CRM for weeks before anyone notices. None of these throw an error — they show up as wrong numbers in next quarter's board deck.

Attribution and historical reporting. Original source, first-touch data, and conversion history carry over only if you deliberately preserve them. Import "original source (migrated)" and "original create date" as read-only properties — otherwise every contact looks born on cutover day and your attribution reporting shows a suspicious cliff. Multi-touch attribution effectively restarts at migration; snapshot the old numbers for year-over-year comparison.

Automation logic. Workflows, assignment rules, and field-update triggers do not migrate — they're rebuilt from your audit map. The silent version of this failure: a Salesforce flow that set "SQL date" feeds a rep bonus report; nobody rebuilds it; three months later comp is calculated on a field that stopped updating. Rebuild from the map, then diff behavior on test records.

Integrations. Every connected tool keeps pointing at the old CRM until someone re-points it. During a Pipedrive-to-HubSpot move, a client's forgotten Zapier zap kept creating deals in Pipedrive for five weeks post-cutover — 40+ inbound leads sat in a system nobody was watching. The integration register exists precisely so each connection has a cutover date and an owner.

Email threading and links. Logged emails import as timeline items, but reply-threading, tracked opens, and template analytics don't reconstruct — expect readable history, not a replica of the old inbox view. And every saved legacy-CRM URL in wikis and bookmarks dies at cutover; publish a "find it in HubSpot" crosswalk on day one.

Phased vs. Big-Bang Cutover: Choosing Your Migration Strategy

There are two ways to cut over: big-bang (freeze the old CRM, migrate over a weekend, everyone starts in HubSpot Monday) and phased (teams or data domains move in waves while a sync bridges both systems). Big-bang is faster and leaner for orgs under ~100 CRM users; phased de-risks large orgs at the cost of running two systems and a sync that becomes its own project.

Factor	Big-bang cutover	Phased migration
Timeline	4–8 weeks total, one cutover weekend	2–6 months across waves
Effort and overhead	Lower — one migration event, no bridge sync	Higher — two systems running in parallel, sync tooling, longer engagement
Risk profile	Concentrated: one bad weekend is very bad, but rehearsal defuses it	Distributed: no single failure point, but sync conflicts create slow-burn data drift
Data consistency	Clean: one system of record at all times	Hardest problem: two writable systems need conflict rules or you get dueling updates
Best for	<100 users, single business unit, standard objects	Multi-region/multi-BU orgs, heavy custom objects, businesses that can't tolerate any downtime
Team experience	One training push, brief productivity dip	Early waves generate lessons for later waves; change fatigue is longer
Rollback	Keep legacy read-only for 90 days; revert is painful but possible	Each wave can pause; partial rollback is feasible

Our default recommendation for the mid-market: big-bang, rehearsed. Run the full migration into a test portal first, time it, validate it, list every surprise — then do it for real over a low-activity weekend (never quarter-end). Reserve phased approaches for genuine scale or a hard zero-interruption requirement, and if you go phased, treat the interim sync as production infrastructure with monitoring, not a Zapier afterthought. Either way, keep the legacy CRM read-only for 90 days post-cutover as your reference for disputes and your safety net for anything validation missed.

The HubSpot Migration Checklist

A reliable migration follows the same sequence every time: audit, design, test-migrate, validate, cut over, verify. The checklist below is the condensed version of the runbook we use on client migrations — skipping steps doesn't make it faster, it makes it twice as long with worse morale.

1. Run the legacy audit (objects, fields, automations, integrations, reports) and get sign-off on what migrates, what archives, and what dies.
2. Design the target portal first: properties, lifecycle stages, pipelines, teams, permissions. Never mirror the legacy structure by default — this is the once-a-decade chance to fix it (our implementation guide covers portal design in depth).
3. Write the field-mapping document — every source field → destination property, transformation rule, and picklist consolidation. This document is the migration; everything else is execution.
4. Clean data at the source: dedupe by email/domain, normalize picklists, reassign records from inactive owners, purge dead records.
5. Choose tooling: HubSpot's native Salesforce integration and import tools for standard cases; a migration platform or custom API scripts for activity history and complex objects.
6. Export and snapshot everything — full backups of all objects including attachments, stored outside both systems.
7. Run a full test migration into a sandbox/test portal. Time it, validate it, log every anomaly, and fix the mapping — not the symptom.
8. Rebuild automations and re-point integrations in the new portal, disabled, ready to switch on at cutover.
9. Execute cutover: freeze legacy writes, run the final delta migration, spot-check, enable automations and integrations, flip forms and routing, announce.
10. Validate against acceptance criteria — record counts within tolerance, leadership reports reproduced and matching, timelines spot-checked (next section).
11. Train and support: role-based training in week one, office hours through week four, a visible "find it in HubSpot" crosswalk. Adoption is part of the migration, not an epilogue.
12. Hold legacy read-only for 90 days, then archive final exports and terminate the contract.

Post-Migration Validation: Prove It Worked

Post-migration validation means proving, with numbers, that what left the old system arrived intact in HubSpot — record counts per object, pipeline totals to the dollar, and reproduced leadership reports — plus spot-checking real records end to end. Declare success when the acceptance criteria pass, not when the import progress bar hits 100%.

The validation set we require before signing off:

• Count reconciliation. Contacts, companies, deals, and activities: legacy count vs. HubSpot count, with every gap explained (dedupes, archives) rather than shrugged at.
• Pipeline value reconciliation. Sum of open deal amounts by stage in both systems. If the legacy total and the HubSpot total disagree, find the missing deals before reps do.
• The 25-record deep check. Pick 25 real records across segments — oldest, newest, biggest deal, weirdest edge case — and compare field by field against the legacy snapshot, timeline included.
• Report reproduction. Rebuild the leadership report set and confirm the numbers match the final legacy run.
• Automation dry runs. Push test records through every rebuilt workflow: routing, notifications, stage automation, scoring.
• Integration round-trips. For each re-pointed integration, create a test record at the source and confirm it lands in HubSpot — and only in HubSpot.
• The 30-day watch. Weekly checks on unowned records, workflow errors, and form-to-CRM flow. Silent breakage surfaces in the first month if you're looking, and in the first board meeting if you're not.

Then, four to six weeks in, audit the new portal itself — an early HubSpot audit catches post-migration drift while it's still cheap to correct.

Book a free HubSpot audit. No onboarding calls, no meetings — click our invitation link to grant partner access to your portal, and we'll send you a full list of improvements within days.

FAQ

How long does a HubSpot migration take?

For a mid-market company with standard objects, four to eight weeks: one to two weeks of audit and mapping, two to three weeks of build and test migration, a cutover weekend, then validation and training. Phased enterprise migrations run two to six months.

Will I lose my historical data migrating from Salesforce to HubSpot?

Not if you plan for it. Records, fields, and activity history all migrate. What's at risk is derived history — attribution touchpoints, email threading, stage-duration data — which must be preserved deliberately as snapshot properties and static reports, or accepted as a documented loss.

Should I clean my data before or after migrating to HubSpot?

Before, always. Dedupe, normalize picklists, and purge dead records in the legacy system, where you still have context on what the data means. Cleaning afterward costs roughly double.

Can I run Salesforce and HubSpot in parallel during migration?

Yes — HubSpot's native Salesforce integration supports a sync bridge, and phased migrations depend on it. But define one system of record per object with clear conflict rules, and keep the parallel period short: two writable CRMs without governance drift apart within weeks.

What drives the cost of a HubSpot migration?

Tooling is the small part — HubSpot's built-in import tools and native Salesforce integration cover standard cases, and third-party migration platforms are a minor line item. The real investment is expertise, and it scales with complexity: a straightforward Pipedrive move sits at the low end, a heavily customized Salesforce org at the high end, driven mostly by automation rebuilds and activity-history handling. Scope the automation map first — it's the best predictor of total effort.