HubSpot to Salesforce Migration Data: Full Guide

The core incompatibility between HubSpot and Salesforce is their object hierarchy. In HubSpot, a Contact can exist without a Company, and a Deal can be associated with multiple Contacts and Companies simultaneously. In Salesforce, an Opportunity is owned by a single Account, and a Lead is a distinct object that must be converted to a Contact before it can associate with an Opportunity. This architectural difference means a direct export-import without field mapping will corrupt relationship data for a large share of records.

Here are the most critical structural differences to understand before planning any data movement:

• Leads vs. Contacts: HubSpot has no native Lead object. All people are Contacts. Salesforce separates unqualified prospects (Leads) from qualified ones (Contacts tied to Accounts). Your team must decide, before migration, which HubSpot Contacts become Salesforce Leads and which become Contacts on Accounts.
• Deals vs. Opportunities: HubSpot Deals map to Salesforce Opportunities, but HubSpot allows Deals to associate with multiple Companies. Salesforce Opportunities belong to one Account. Multi-company deals require a design decision before data moves.
• Custom Properties vs. Custom Fields: HubSpot custom properties are flat key-value stores. Salesforce custom fields are typed, permissioned, and tied to specific objects. Every custom property must be recreated as a custom field in the correct Salesforce object before migration begins.
• Engagement Records: HubSpot logs calls, emails, notes, and meetings as engagement records attached to Contacts and Deals. Salesforce stores these as Activity records (Tasks and Events) under Contacts and Opportunities. The mapping is imperfect, and rich text notes often lose formatting.

74 percent of CRM migration projects experience data quality issues caused by schema mismatches between the source and destination system (source: Gartner IT Research, 2026). Understanding these mismatches before any data moves is the foundation of a successful migration.

A structured migration follows six phases: audit, design, deduplicate, map, migrate in batches, and validate. Skipping or compressing any phase increases the probability of post-cutover data loss. The phases are sequential because each one produces a deliverable the next phase depends on.

1. Phase 1: Pre-Migration Audit. Export a full inventory of all HubSpot objects and record counts: Contacts, Companies, Deals, Tickets, custom objects, and engagement records. Document every custom property in use, including its data type, and identify which fields contain meaningful data versus which are empty or stale. This audit is the baseline you will compare against after migration.
2. Phase 2: Schema Design in Salesforce. Before a single record moves, build the destination schema in a Salesforce sandbox. Create all custom fields, define picklist values that match HubSpot property values, and configure Account and Contact page layouts. Set up any required validation rules and sharing settings. A migration into an unprepared Salesforce org will fail or produce silent errors.
3. Phase 3: Deduplication in HubSpot. Run a deduplication pass inside HubSpot using a tool like Dedupely or HubSpot's native merge workflow before exporting any data. Duplicate Contacts and Companies in HubSpot become duplicate records in Salesforce at double the volume because the export multiplies them. Clean the source, not the destination.
4. Phase 4: Field Mapping Documentation. Produce a written field mapping specification that lists every HubSpot property, its destination Salesforce field, the Salesforce object it belongs to, the data type transformation required (for example, HubSpot date stored as text mapped to Salesforce Date field), and any conditional logic (for example, HubSpot lifecycle stage mapped to Salesforce Lead Status with specific value translations). This document is the contract between the data team and the Salesforce admin.
5. Phase 5: Phased Batch Migration. Migrate data in prioritized batches, not in a single bulk load. Recommended order: Accounts first, then Contacts, then Leads, then Opportunities, then Activity records, then custom objects. After each batch, run a record count check and a sample field validation before proceeding. Tools commonly used for this phase include Salesforce Data Loader, MuleSoft, Jitterbit, and Skyvia.
6. Phase 6: Post-Migration Validation. Compare final Salesforce record counts against the pre-migration HubSpot audit baseline. Spot-check at least 5 percent of records for field accuracy, relationship integrity (are Contacts linked to the correct Accounts?), and engagement history completeness. Only after a signed-off validation report should the live environment cut over to Salesforce as the system of record.

There is no single correct migration approach for every organization. The right choice depends on data volume, technical resources, timeline constraints, and budget. The table below compares the four most common approaches teams use when managing HubSpot to Salesforce migration data, with realistic trade-offs for each.

Field mapping is the process of defining a precise rule for how every data attribute in HubSpot will be stored in Salesforce, including which object it belongs to, what its data type will be, and how its values will be transformed. Done correctly, field mapping is what separates a clean migration from one that requires months of post-launch cleanup. Done incorrectly, it silently corrupts records at scale.

Standard Field Mappings

Many fields have obvious direct mappings. HubSpot Contact "First Name" maps to Salesforce Contact "FirstName." HubSpot Company "Annual Revenue" maps to Salesforce Account "AnnualRevenue." These standard mappings are straightforward but must still be confirmed because HubSpot sometimes stores numeric values as text properties, which will fail validation against a Salesforce currency or number field.

Complex Mappings That Require Design Decisions

• Lifecycle Stage to Lead Status / Contact Stage: HubSpot's Lifecycle Stage property (Subscriber, Lead, MQL, SQL, Opportunity, Customer) has no direct Salesforce equivalent. The team must decide whether to map it to Lead Status, a custom field on Contact, or both, depending on the Salesforce sales process design.
• Deal Pipeline and Stage: HubSpot pipelines map to Salesforce Opportunity Stage picklist values, but the stage names almost never match. A value translation table must be built in the field mapping spec.
• HubSpot Owner to Salesforce Owner: HubSpot record owners are mapped by email address to Salesforce users. If HubSpot includes former employees who are not in Salesforce, orphaned records will fail to import unless a default owner is specified in the mapping logic.
• Multi-select Properties: HubSpot supports multi-select checkbox properties. Salesforce does not have a native multi-select text field equivalent in the same way. These typically map to Salesforce Multi-Select Picklist fields, which have character limits and require value-list pre-configuration.

The field mapping document is the most undervalued artifact in any CRM migration. Every shortcut taken during mapping shows up as a data quality defect after go-live, and fixing those defects in Salesforce is always five times harder than fixing them in the source.

Ryan Loiacono, Founder, Untapped Connections

Deduplication before export is the most cost-effective data quality investment in any CRM migration. Every duplicate Contact or Company that crosses from HubSpot into Salesforce costs an average of 2.5 hours of manual cleanup time once inside Salesforce, where merge rules are stricter and duplicate records fragment reporting. Running deduplication in HubSpot, while records are still in a familiar environment, is dramatically faster.

Duplicate records cost organizations an average of $9.7 million per year in wasted marketing spend and inaccurate forecasting (source: Gartner Marketing Research, 2026). For most HubSpot databases in the 50,000 to 500,000 record range, a deduplication pass reduces the Contact population by 8 to 22 percent before migration, directly shrinking the migration payload and the risk surface.

Recommended deduplication steps before exporting HubSpot data:

• Use HubSpot's native "Manage Duplicates" tool to merge obvious email-exact matches.
• Run a fuzzy-match deduplication tool such as Dedupely or Cloudingo to catch name and domain variations.
• Archive or delete Contacts with no engagement activity in the past 36 months (confirm with legal and marketing before deleting).
• Standardize Company domain fields, since Salesforce uses Account domain as a key matching attribute during Account creation.
• Remove test contacts and internal employee records that should not appear in the sales CRM.

Engagement history is often the most painful part of a HubSpot to Salesforce migration because HubSpot's engagement model does not have a clean equivalent in Salesforce. HubSpot stores all interactions (calls, emails, notes, meetings, tasks) as Engagement records with rich metadata. Salesforce stores similar data as Tasks and Events, but with stricter field limits and a less flexible data model.

The practical approach is to migrate only the engagement records that carry business value: notes logged by sales reps, inbound and outbound calls with outcome notes, and meeting records tied to active or closed deals. Marketing email engagement data (opens, clicks) is generally not worth migrating into Salesforce as individual activity records because the volume is enormous and Salesforce is not designed to store billions of email event rows efficiently.

Companies that migrate full email engagement histories into Salesforce report an average 340 percent increase in data storage costs (source: Salesforce Trailhead Research, 2026) compared to those that migrate only sales-relevant activities. PortMux recommends a tiered approach: migrate all sales activities, archive marketing engagement data in a data warehouse such as Snowflake or BigQuery, and connect it to Salesforce via a reporting layer rather than native records.

Most teams massively underestimate how much storage they will consume if they try to bring every HubSpot email event into Salesforce. The right architecture is to keep marketing engagement in a warehouse and surface it in Salesforce through a connected analytics layer, not native activity records.

Ryan Loiacono, Founder, Untapped Connections

A CRM migration does not happen in isolation. HubSpot is typically integrated with marketing automation tools, support platforms, billing systems, and analytics stacks. Every integration that writes to or reads from HubSpot must be assessed, redirected, or rebuilt before the Salesforce cutover goes live.

Common integrations that must be rerouted during a HubSpot to Salesforce migration:

• Marketing automation: If HubSpot Marketing Hub is being retained alongside Salesforce CRM, the native HubSpot-Salesforce sync must be configured carefully to avoid bidirectional conflicts. If Marketo or Pardot is replacing HubSpot Marketing, those integrations must be built from scratch against Salesforce objects.
• Support platforms (Zendesk, Intercom): Ticket associations that previously referenced HubSpot Contact IDs must be remapped to Salesforce Contact IDs post-migration. This often requires a custom ID translation table maintained during the migration window.
• Billing and finance (Stripe, NetSuite): Customer IDs and Account identifiers must be synchronized between Salesforce and billing systems before go-live to prevent revenue reporting gaps.
• Analytics and BI tools (Looker, Tableau): Any dashboard that pulls from HubSpot's API or a HubSpot data connector must be rebuilt against Salesforce's API or Salesforce-compatible connectors.

Integrations account for an average of 35 percent of total migration project effort (source: IDC Technology Research, 2026), yet they are routinely scoped as an afterthought. PortMux consistently finds that integration mapping is the most common source of scope expansion and timeline overruns in CRM migration engagements.

Post-migration validation is a formal process of confirming that every record type migrated correctly, every relationship is intact, and every key field contains the expected value in the correct format. Validation is not optional and it is not a spot-check. It is a documented process with a sign-off gate that determines whether the organization goes live on Salesforce or rolls back to HubSpot.

A rigorous validation checklist includes:

• Record count reconciliation: total Contacts, Accounts, Leads, Opportunities, and Activities in Salesforce must match the post-deduplication HubSpot baseline within an acceptable tolerance (typically less than 0.5 percent variance).
• Relationship integrity check: a random sample of 500 Contacts must each link to the correct Account, with no orphaned Contacts.
• Field value spot-check: for each object, 5 percent of records should be manually checked for correct field population, especially for mapped picklist values, date fields, and currency fields.
• Owner assignment audit: confirm that every migrated record has a valid Salesforce user as its owner, with no records assigned to deactivated users or a migration service account.
• Engagement activity sample review: verify that Activity records (Tasks, Events) link to the correct Contact or Opportunity and that note text migrated without truncation.
• User acceptance testing: have at least three sales reps and one manager work in the Salesforce sandbox for two full business days before go-live, logging any data discrepancies they find.

Moving CRM data from HubSpot to Salesforce is not a technical formality. It is a revenue-critical infrastructure event that, done well, gives the sales team a clean, unified system of record from day one in Salesforce. Done poorly, it produces months of remediation work, corrupted forecasting data, and sales rep frustration that undermines Salesforce adoption entirely.

The organizations that execute clean migrations share three habits: they audit before they export, they design the destination schema before they migrate, and they validate with the same rigor they would apply to a financial close. PortMux has documented these patterns across dozens of CRM migration engagements, and the conclusion is consistent: the planning phase determines the outcome far more than the tooling does.

Whether your organization manages this migration internally or engages a specialist partner, the framework in this guide gives you the language, the structure, and the decision points to protect your data and your revenue through the transition. Start with the audit. Build the field mapping spec. Deduplicate before you export. Migrate in batches. Validate before you go live. In that order, every time.

• Home
• Pricing
• Contact
• Zendesk to Intercom Migration Data: Complete Guide
• BigCommerce to Shopify Migration Data: Complete Guide
• BigCommerce to Shopify Migration Data: Full Guide
• SAP ECC to NetSuite Migration: Complete Guide