Every Salesforce-to-HubSpot migration runs into the same wall eventually. The two platforms organize customer data differently, so a straight export-and-upload approach breaks relationships, duplicates records, and drops fields nobody thinks to check until weeks later. Salesforce has Leads as a separate object from Contacts. HubSpot doesn’t. Salesforce uses Opportunities; HubSpot uses Deals with a different default pipeline structure. Neither system is wrong here. The gap just means the migration has to be planned as a data project, with its own sequence and validation steps, rather than treated like a simple file transfer.

This guide walks through that project end to end, from the pre-migration audit through the first few weeks of monitoring after go-live. It assumes you’ve already weighed whether Salesforce’s cost still justifies itself and landed on HubSpot. What follows is the execution plan.

Audit what’s actually in Salesforce before you export anything

Start by inventorying the org, not the data. List every standard and custom object in use, every custom field on Contacts, Accounts, and Opportunities, and every automation (workflow rules, process builder flows, Apex triggers) that touches those objects. Note which reports and dashboards the sales team actually opens versus which ones have been dormant for a year. A lot of Salesforce orgs accumulate fields and objects that stopped mattering long before anyone decided to leave.

This audit also needs to capture record ownership and sharing rules. HubSpot has its own concept of record owners, and every Salesforce user who owns records needs a corresponding HubSpot user before import, or ownership data has nowhere to land.

Decide what actually needs to move

Some records simply don’t earn a spot in the new system. Closed-lost opportunities from four years ago, contacts with bounced emails, duplicate accounts created during a failed import back in 2019, none of that has to survive the move in its current form. A useful way to sort the data is into three buckets. Active records that sales and marketing touch daily belong in HubSpot from day one. Historical records worth keeping for reporting or compliance can come along too, just flagged as archival. Everything else, the genuine dead weight, can be backed up as a CSV and left out of HubSpot entirely.

Retention requirements matter here too. If your industry has record-keeping obligations, confirm what has to be retrievable and for how long before deciding anything is disposable.

Clean the data before it goes anywhere

Migration has a way of exposing every inconsistency that’s been quietly living in Salesforce. Duplicate contacts under slightly different email addresses, phone numbers in five different formats, lifecycle or deal stages that mean different things depending on which rep entered them, all of it surfaces at once. Clean this in Salesforce before export, not after import. Deduplicate contacts and accounts, standardize phone and address formatting, fill in required fields that HubSpot will need for automation later, and align stage values so a “Negotiation” opportunity in Salesforce doesn’t land in three different HubSpot deal stages depending on how it was originally labeled.

Build the Salesforce-to-HubSpot data map

This is the part that determines whether the migration is smooth or painful. Salesforce objects and HubSpot objects overlap conceptually but aren’t identical, and treating them as interchangeable is where most migrations go wrong.

Salesforce	HubSpot	Migration Consideration
Lead	Contact	HubSpot has no separate lead object. Salesforce Leads become Contacts, typically distinguished by lifecycle stage rather than a separate record type.
Account	Company	Match on domain name where possible. Accounts without a clean website domain need a different unique identifier or manual review.
Contact	Contact	Field-by-field property mapping. HubSpot only allows mapping between compatible types, so a Salesforce picklist won’t map directly to a HubSpot free-text field without conversion.
Opportunity	Deal	Pipeline and stage names rarely match one-to-one. Build the new HubSpot pipeline first, then map each Salesforce stage to its closest HubSpot equivalent.
Custom Field	Custom Property	Field type compatibility must be checked individually. A Salesforce formula field, for instance, has no direct HubSpot equivalent and may need to become a static value at time of migration.
Activities (Tasks, Calls, Events)	Engagements	HubSpot’s import tool can create new activity records but generally can’t update existing ones through import, so activity history typically arrives as new engagements tied to the record.
Notes	Notes	Notes migrate through a multi-file import with association mapping, not a simple single-file upload.
Attachments / Files	Files	Standard Salesforce record exports don’t include the underlying file content. Files and classic attachments usually require a separate export pass.

Direct mappings (Contact-to-Contact, Account-to-Company) are the easiest part. Mappings that require transformation (Opportunity stages, custom fields) need a decision document before anyone touches the import tool, and HubSpot’s own guidance on mapping Salesforce fields is worth reading in full before building that document.

Export the data properly

Salesforce offers a few different export paths, and they’re not interchangeable. The built-in Data Export Service produces a full backup of standard and custom objects as CSV files and can include documents and attachments, though large orgs can see this process take a day or more to generate. Data Loader handles bulk exports with more filtering control through SOQL queries but doesn’t pull file content by default, which means attachments and Salesforce Files (the ContentVersion object) usually need their own export step, with the file body arriving as base64-encoded data that has to be decoded to rebuild the original file.

Whichever tool you use, back up the raw export before doing any cleanup, and check row counts against what’s actually in Salesforce before moving on.

Configure HubSpot before a single record lands

Set up custom properties, pipelines, and deal stages to match the data map, not the other way around. Create HubSpot users for every Salesforce owner that needs to carry over. If your rollout includes workflows or automations that will act on incoming records, leave them off during import. A workflow that fires on “contact created” will happily send a welcome email to five thousand records the moment they land, which is rarely the intended outcome of a migration.

Run a real test migration first

Import a small, representative sample, somewhere between fifty and a few hundred records covering contacts, companies, deals, and a mix of custom field values. Check whether associations held, stage mappings landed correctly, owners assigned properly, and nothing silently dropped. This is also the moment to confirm which HubSpot subscription tier you’re on, since features like association labels and custom object sync require Professional or Enterprise plans.

Execute the production migration

Sequence matters. Import companies before the contacts that need to associate with them, and import contacts before the deals that reference them, so HubSpot has something to attach records to as they arrive. Watch the import log in real time rather than starting several large imports and walking away.

Validate what actually landed

Compare record counts between Salesforce and HubSpot for each object. Spot-check field values against the source data, confirm associations between contacts, companies, and deals are intact, and check for duplicate records created during import. Pay particular attention to deal stages and ownership, since those two fields drive reporting and are the ones sales teams notice first if something’s off.

Reconnect the operational layer

Moving the records is only the first half of the job. A working CRM also needs its integrations, automations, and reporting rebuilt or reconnected against the new HubSpot data structure, and it’s worth knowing how deep HubSpot’s app ecosystem actually runs before deciding what to rebuild versus replace. Turn workflows back on deliberately, one at a time, and confirm each one behaves as expected before enabling the next.

Monitor closely for the first few weeks

Watch for duplicate creation from any lingering sync processes, broken associations that surface only when someone tries to use a specific report, and integration failures that don’t show up until a connected tool tries to push or pull data on its usual schedule. Data integrity issues from a migration rarely show up all at once. They surface gradually, as different teams touch different parts of the CRM.

Where migrations tend to go wrong

A few patterns show up repeatedly across CRM migrations, regardless of which platforms are involved.

• Treating Salesforce and HubSpot objects as identical. Lead-to-Contact and Opportunity-to-Deal both require real decisions, not a default mapping.
• Skipping data cleanup because it feels optional. Dirty data migrated is still dirty data, just in a new system.
• Importing before HubSpot is configured. Records land in the wrong pipeline or with missing custom properties, which then have to be fixed after the fact.
• Activating automations too early. Workflows firing on freshly imported records can send unwanted emails or trigger unintended tasks at scale.
• Skipping the test migration. A small sample import surfaces mapping problems while they’re still cheap to fix.
• Forgetting user ownership. Records without a matching HubSpot owner either fail to import or default to an unintended user.
• Assuming the migration is done at import completion. Integrations, reports, and automations still need to be rebuilt before the team can actually work in the new system.

These mistakes are ordinary, predictable outcomes of treating a CRM migration as a simple export-then-import task, when the real work is rebuilding how customer information flows through the business. Teams with heavy Salesforce customization, custom objects, or complex automation, and without the internal bandwidth to work through all of it carefully, are often better served bringing in a specialist for the mapping and test-migration phases instead of learning the platform’s edge cases under production pressure.

Putting It All

A Salesforce-to-HubSpot migration succeeds or fails long before the first record is imported. The organizations that get it right treat the data map as the real deliverable, test with a small sample before committing to production, and validate methodically rather than assuming a clean import log means a clean CRM. The organizations that struggle are usually the ones that skipped the audit, mapped fields on the fly, or turned every automation on the moment records landed. Budget more time for planning and validation than for the import itself, and the migration becomes a manageable project rather than a recurring source of bad data for the next two years.