A Salesforce to HubSpot migration is not a matter of exporting one CRM and importing another.
Salesforce may contain leads, contacts, accounts, opportunities, cases, activities, campaigns, products, quotes, users, custom objects, lookup relationships, validation rules, flows, and years of historical decisions built into the data model.
HubSpot can support a connected customer platform, but it represents some of those concepts differently. The migration succeeds only when the business meaning, record relationships, ownership, history, and go-forward processes survive the translation.
This guide explains what can move, what needs to be transformed, what must be rebuilt, and how to migrate Salesforce to HubSpot without leaving your team with clean-looking but disconnected data.
Salesforce is highly configurable and can support complex enterprise requirements. That flexibility is valuable, but it can also create an environment that requires significant administration, specialist development, and ongoing governance.
Businesses commonly consider HubSpot when they want:
Migration should still be tied to a specific capability or operating goal. A complicated Salesforce org does not become simple merely because its records move. Unnecessary fields, conflicting processes, duplicate automations, and poor ownership rules should be resolved before they are recreated in HubSpot.
Use the migration as an opportunity to simplify, but do not simplify by deleting context the business still needs.
Salesforce and HubSpot can represent the same customer journey, but the object models and platform behavior are not identical.
|
Salesforce |
HubSpot |
Migration consideration |
|---|---|---|
|
Lead |
Usually Contact |
Decide how lead status and conversion state become lifecycle stage, lead status, or another property. |
|
Contact |
Contact |
Maps conceptually, but account relationships, owners, duplicate rules, and activity history need validation. |
|
Account |
Company |
Preserve account hierarchy or define a supported alternative where needed. |
|
Opportunity |
Deal |
Recreate pipelines and map every stage, type, amount, currency, and owner. |
|
Task and Event |
Task, call, meeting, email, or activity |
Activity types, timestamps, owners, and parent associations need deliberate mapping. |
|
Case |
Ticket |
Status, priority, pipeline, SLA context, conversation history, and ownership may require transformation. |
|
Campaign and Campaign Member |
HubSpot campaigns, lists, marketing events, or custom properties |
Salesforce campaign membership does not always have a single equivalent. Define the reporting requirement first. |
|
Custom object |
Custom object or redesigned standard-object model |
Availability depends on the HubSpot subscription and target architecture. |
|
Lookup or master-detail relationship |
HubSpot association |
Cardinality and labels must be recreated, not assumed. |
The largest design decision is often the Salesforce Lead object. HubSpot uses one contact record across the lifecycle, while Salesforce commonly separates unconverted leads from contacts associated with accounts.
Before migration, decide how each Salesforce lead category maps to HubSpot. Do not flatten every person into the same lifecycle stage, because that will distort routing, funnel reporting, and automation from day one.
Most customer and revenue data can be migrated when the source is accessible and the target model is prepared. Typical scope includes:
The correct question is not only “Can this record move?” It is “Can the record land with the same meaning and the relationships the business depends on?”
Some Salesforce concepts require translation because HubSpot implements them differently.
Salesforce leads may become HubSpot contacts, but lead status, conversion state, source, and historical qualification context need explicit properties and lifecycle rules.
Parent-child accounts, junction objects, multiple contact roles, and custom lookup structures may require redesigned associations or custom objects in HubSpot.
Salesforce campaigns can represent events, lists, outbound programs, or broad membership structures. HubSpot campaigns are designed primarily to group marketing assets and measure performance. Campaign members may need lists, marketing events, custom objects, or dedicated properties depending on how the data is used.
Salesforce picklists, multi-select picklists, formulas, dates, currencies, and validation-enforced values do not always map one-to-one to HubSpot property types. Define a transformation and fallback for every incompatible value.
Created dates, last-modified dates, field history, opportunity-stage history, and conversion events may not recreate themselves as native HubSpot history. Preserve the required source timestamps and events in supported activity types or custom properties.
Salesforce profiles, roles, permission sets, sharing rules, and record-level access do not simply import into HubSpot. Users, teams, seats, and permissions need to be designed for the target platform.
Data migration and operating-model migration are separate but connected workstreams.
The following normally need to be rebuilt or redesigned:
Rebuilding does not mean copying every Salesforce process exactly. Some complexity may exist only because Salesforce required a particular implementation. Recreate the business outcome in HubSpot using the simplest supported design that preserves control, reporting, and user experience.
List every object, field, relationship, record type, pipeline, stage, owner, automation, report, integration, and permission dependency. Capture source record counts by object and meaningful business segment.
Create a legacy Salesforce ID property on each HubSpot object. These IDs act as the stable join between source and destination and support associations, repeatable updates, validation, and post-cutover investigation.
Start with the target architecture:
Only after the object model is agreed should individual fields be mapped.
For each field, record the source type, target type, transformation, required-value rule, dropdown crosswalk, default, and in-scope status.
Give special attention to:
Exclude obsolete fields, test records, dead integrations, duplicated automation, stale leads, and historical information that has no legal, operational, or reporting value.
Document every exclusion and obtain business sign-off. “Not migrated” should be a decision, not a surprise discovered after cutover.
Identify duplicates, incomplete relationships, inactive owners, unused fields, obsolete record types, invalid picklist values, and data that should be archived. Resolve known merges and ownership problems in the source while the business context is still available.
Export the required Salesforce data and retain a metadata reference for objects, fields, relationships, automation, layouts, reports, and integrations. If HubSpot already contains records, export a pre-migration snapshot of the target as well.
Create users, teams, permissions, objects, custom properties, pipelines, deal stages, ticket stages, association labels, lists, and required target structures.
Build replacement automation in an inactive or safely controlled state. Pause existing HubSpot workflows that could trigger when migrated records are created or updated.
Finalize object mapping, field mapping, value crosswalks, owner mapping, legacy-ID properties, and relationship rules. Define how leads, campaigns, account hierarchies, opportunity contact roles, custom junction objects, and historical activities will be handled.
HubSpot's native import tools can suit smaller migrations with carefully prepared files and supported objects. API-based migration provides more control over transformations, associations, repeat runs, and large datasets. A purpose-built migration platform reduces manual engineering when the Salesforce org contains custom objects, complex associations, historical activity, ongoing changes, or extensive validation requirements.
The native HubSpot-Salesforce integration is designed for ongoing synchronization between live systems. Do not assume it will perform a complete one-time historical migration or rebuild your target model automatically.
Test hundreds of records across every important object, not only clean contacts. Include custom fields, multiple opportunity contacts, account hierarchies, inactive owners, tasks, events, cases, consent values, and records that should fail.
Validate the result and correct the mapping before scaling.
A common sequence is:
The exact order must follow your relationship dependencies.
Reconcile counts and failed records, then inspect fields, owners, stages, timestamps, consent, and associations. Compare high-value customers, open opportunities, active cases, and recent activity histories in both systems.
Capture leads, contacts, accounts, opportunities, cases, activities, ownership changes, and relationship updates created after the initial extraction. Run the final delta during the cutover window and confirm the target is current.
Redirect forms and integrations, enable the required HubSpot automation in a controlled order, and make HubSpot the new system of record. Give teams the views, pipelines, reports, email connections, and training they need to work on day one.
Keep Salesforce available as a read-only reference through a defined stabilization period.
Flattening every lead and contact into one undifferentiated contact population breaks lifecycle reporting and routing. Define the target lifecycle model before loading records.
Account hierarchies, opportunity contact roles, junction objects, and custom lookups can lose secondary relationships if the migration preserves only the primary parent.
Tasks, events, emails, calls, notes, timestamps, owners, and parent references need more work than standard records. Define the required history depth before estimating the migration.
Salesforce flows and Apex logic do not become HubSpot workflows automatically. Rebuild the business outcome and test it against migrated data.
Large migrations must respect the current limits of Salesforce, HubSpot, and every connected application. Use bulk endpoints, batching, retries, backoff, and a monitored delta strategy instead of a single uncontrolled job.
Email and domain matching alone may not reflect Salesforce duplicate rules. Clean duplicates in the source, preserve Salesforce IDs, and define how records without a reliable key will be handled.
Imported records can trigger HubSpot workflows, lead routing, notifications, and customer emails. Pause or suppress automation until the relevant enrollment rules have been tested.
Dashboards may return different results because lifecycle, stage, source, or campaign definitions changed. Rebuild and reconcile critical reports before users rely on them.
A Salesforce migration becomes difficult when the source contains years of custom objects, relationships, activities, ownership, and process logic. That is where manual exports and generic imports begin to lose context.
SuprSwitch by Suprdense is designed to move Salesforce data into HubSpot while preserving the structure around each record. It supports guided object and property mapping, activities, users, ownership, associations, validation, retries, and delta migration.
Use SuprSwitch when your Salesforce-to-HubSpot migration needs more than a flat transfer - especially when custom objects, complex relationships, historical activity, or ongoing source changes are in scope.
Leads, contacts, accounts, opportunities, cases, activities, notes, products, selected campaign information, standard and custom fields, users, ownership, supported custom objects, and associations can be migrated. The exact scope depends on the source configuration, target HubSpot subscription, and migration method.
Salesforce leads and contacts generally become HubSpot contacts, accounts become companies, and opportunities become deals. Lead status, lifecycle stage, pipelines, owners, and relationship rules must be mapped explicitly so the records retain their business meaning.
Salesforce flows, Apex triggers, validation rules, assignment rules, permissions, layouts, reports, dashboards, and many integration configurations need to be rebuilt or redesigned in HubSpot. They do not move automatically with CRM records.
Tasks, events, calls, emails, and notes should be extracted with their Salesforce IDs, timestamps, owners, activity types, and parent references. They can then be recreated as supported HubSpot activities and associated with the correct contacts, companies, deals, or tickets.
A small, clean migration using standard objects may take a few days. A complex migration involving custom objects, historical activities, multiple integrations, relationship reconstruction, testing, and delta synchronization can take several weeks. Data-model complexity and preparation quality usually have more impact than record count alone.