Introduction
Most HubSpot to Salesforce migrations do not lose data in one dramatic failure. They lose it quietly. A deal arrives in Salesforce without its contacts. A note lands with today’s date instead of the date it was written. A contact who worked with three companies ends up attached to one.
None of these show up as errors in an import log. They show up weeks later, when a rep opens an account and the history is missing, or when a forecast report stops matching what finance remembers.
This guide is for revenue operations leaders, CRM admins and project owners planning the move. It explains how HubSpot data maps to Salesforce, where data is usually lost, the order records need to load in, which tools fit which job, and how to check the result before you switch users over.
Key takeaways
- Migrating records is the easy part. Keeping the links between them (associations) is where most data loss happens.
- Store every HubSpot Record ID in a Salesforce External ID field. It is how you rebuild relationships and rerun loads safely.
- Load in dependency order: users, accounts, contacts, opportunities, then activities.
- Activities such as notes, calls and emails do not come out of HubSpot’s standard record export. Plan a separate path for them.
- Decide early whether HubSpot stays on for marketing. It changes what you migrate.
What does a HubSpot to Salesforce migration involve?
A HubSpot to Salesforce migration moves your CRM records, the relationships between them, and their history from HubSpot into a Salesforce org, then rebuilds the processes that worked on that data. It is three projects running together.
- Data migration. Companies, contacts, deals, tickets, products, custom objects and activity history move into Salesforce objects.
- Process rebuild. HubSpot workflows, sequences, lead rotation and lifecycle stage logic do not transfer. They are redesigned as Salesforce Flows, assignment rules and validation rules.
- Change for the people who use it. Reps, managers and marketers learn new screens, new reports and new habits.
This article focuses on the first project, because it is the one that cannot be fixed by reconfiguring later. A workflow built wrong can be rebuilt. A relationship that was never loaded has to be reconstructed from source files, if those files still exist.
Why do companies move from HubSpot to Salesforce?
The usual trigger is a data model that has outgrown HubSpot: many custom objects, complex record level permissions, multiple business units on one system, or integrations with ERP and finance systems that need Salesforce’s object structure. We cover that decision in detail in HubSpot vs Salesforce in 2026.
Before you start, be sure the problem is the platform. Unclear ownership, messy processes and poor data quality move with you, and will reappear in Salesforce within months.
How do HubSpot objects map to Salesforce?
Most standard HubSpot objects have a clear Salesforce equivalent. The decisions sit in the details: whether contacts become Leads or Contacts, and how many to many associations are represented.
| HubSpot object | Salesforce object | What to decide |
| Company | Account | Which domain or name rule identifies duplicates; how parent and child companies map to the Parent Account field |
| Contact | Contact or Lead | Contacts tied to a company usually become Contacts. Unqualified, companyless records may suit Leads. Lifecycle stage drives the split |
| Deal | Opportunity | Pipelines and stages map to Sales Processes, record types and Stage picklist values |
| Deal line item | Opportunity Product | Requires Products and a Price Book loaded first |
| Ticket | Case | Ticket pipelines map to Case status and support processes |
| Product | Product (with Price Book Entry) | Each product needs a price book entry before it can be used on an opportunity |
| Note, call, email, meeting, task | Task, Event, or a note object | How much history to bring, and whether email bodies are needed in full |
| Custom object | Custom object | Rebuilt in Salesforce first, including its relationships |
| Owner | User | Every HubSpot owner needs a matching Salesforce user, active or inactive |
What about properties and lifecycle stages?
Each HubSpot property needs a destination field, a matching data type and a decision on its values. Dropdown properties become picklists, so their values must exist in Salesforce before the load or records fail validation. HubSpot’s lifecycle stage has no single Salesforce equivalent. It is usually split across Lead Status, Opportunity Stage and a custom field that preserves the original value for reporting.
Where does data get lost in a HubSpot to Salesforce migration?
Data is rarely deleted during a migration. It is disconnected, truncated or stamped with the wrong date. These are the six places it happens, and how to prevent each one.
1. Associations that never reconnect
In HubSpot, a deal is linked to its contacts and company through associations. In Salesforce, those links are lookup fields that point to Salesforce record IDs, which do not exist until the parent record is loaded. If you load opportunities with only a company name, Salesforce cannot tell which account you mean.
Prevent it: create an External ID field on every target object (for example, HubSpot_Record_ID__c) and load the HubSpot Record ID into it. Child records then reference their parents by that external ID during an upsert, so relationships resolve without manual matching.
2. Associations cut off by the export
HubSpot’s record export includes associated record IDs, but by default only up to 1,000 associated records per association column. A large customer account with more contacts than that will export incomplete.
Prevent it: choose All associated records in the export settings (available for CSV files), or pull associations through the API, and reconcile counts on your largest accounts.
3. Activity history left behind
HubSpot’s standard record export returns property values and associations, not the activity timeline. HubSpot’s own documentation points to individual contact data exports, activity reports or the engagements API for notes, calls and emails.
Prevent it: treat activities as a separate workstream. Decide how many years of history reps actually need, extract it through the API or a migration tool, and load it after the records it attaches to.
4. Created dates reset to migration day
By default, Salesforce sets Created Date to the moment a record is inserted. Every deal, contact and note then appears to have been created on the same day, which breaks cohort, aging and sales cycle reporting.
Prevent it: an admin can enable the Set Audit Fields upon Record Creation permission and assign it to the migration user. Audit fields such as Created Date can then be set only when a record is first inserted, not afterwards, so this must be in place before the load. Also keep the original HubSpot dates in custom fields as a fallback.
5. Contacts linked to more than one company
HubSpot lets one contact be associated with several companies. A standard Salesforce Contact has one primary Account.
Prevent it: pick a primary company for each contact, then enable Contacts to Multiple Accounts in Salesforce and load the additional links as Account Contact Relationship records. The alternative, creating duplicate contacts per company, splits that person’s history.
6. Owners who no longer work there
Records owned by former employees fail or default to the migration user if their owner has no Salesforce user.
Prevent it: create inactive users for former owners, or agree on a reassignment rule before loading. The same Setup option that enables audit fields also enables the permission Update Records with Inactive Owners.
How do you migrate from HubSpot to Salesforce step by step?
A safe migration runs in two passes: rehearsals in a sandbox until the numbers reconcile, then a final cutover in production.
- Inventory HubSpot. List every object, property, pipeline, association type, workflow and integration. Record counts per object so you have a baseline to reconcile against.
- Decide scope. Agree what moves, what is archived and what is left behind. Closed lost deals from many years ago and contacts with no email are common candidates to leave out.
- Clean at the source. Merge duplicate companies and contacts in HubSpot, standardize picklist values, countries and phone formats. Cleaning before export is cheaper than cleaning in two systems.
- Build the Salesforce target. Create objects, fields, record types, picklist values, the External ID fields, users and the migration permission set before any data arrives.
- Write the mapping document. One row per field: HubSpot property, Salesforce field, data type, transformation rule and owner. Have the business owner of each area sign it off.
- Back up and export. Export full CSVs with Record IDs and all associations, and store an untouched copy that nobody edits.
- Load into a sandbox in dependency order (below), using upsert on the External ID so a rerun updates records instead of duplicating them.
- Reconcile. Compare record counts, spot check large accounts, test that deals show their contacts and that dates are original. Fix the mapping and reload until it passes.
- Pause automation for the load. Validation rules, Flows and assignment rules can reject or alter migrated records. Disable or bypass them for the migration user, then turn them back on.
- Cut over. Freeze edits in HubSpot, load to production, run a final delta of records changed since the freeze, then switch users and integrations over.
In what order should records be loaded?
Parents must exist before the children that point to them.
- Users (including inactive former owners)
- Products and Price Book Entries
- Accounts, then parent account links in a second pass
- Contacts (and Leads, if used)
- Account Contact Relationships for contacts with several companies
- Opportunities, then Opportunity Contact Roles and Opportunity Products
- Cases
- Custom objects, in the order of their own relationships
- Activities: tasks, events, notes and emails
- Files and attachments
What are the best data migration tools for Salesforce?
The right tool depends on volume, how many objects you are moving, and whether you need to repeat the load. For a HubSpot migration, you will usually combine two of these.
| Tool | Best for | Limits to know |
| Small, simple loads into supported objects such as accounts, contacts and leads | Salesforce recommends it for fewer than 50,000 records, objects with fewer than 50 fields, and no complex mappings | |
| Most migrations: any object, upsert by External ID, success and error logs | Desktop app; supports files up to 150 million records with Bulk API 2.0; available in Enterprise, Performance, Unlimited and Developer editions | |
| HubSpot to Salesforce migration services (for example SyncMatters). | Moving records, associations and activity history with less manual file work | Third party products with their own pricing and object coverage; confirm what each one carries over before relying on it |
| ETL and integration platforms | Large or repeated loads, heavy transformation, staging in a warehouse | Need technical setup and someone to own the pipeline |
| HubSpot Salesforce integration | Keeping both systems in sync when HubSpot stays for marketing | A sync, not a migration tool; requires a HubSpot Professional or Enterprise subscription and does not support Salesforce Group Edition |
Whichever tool you use, the External ID approach still applies. Tools move rows; the mapping decisions and the reconciliation are yours.
What are the best practices for data migration in Salesforce?
These practices apply to any Salesforce data migration, and they matter most when the source is HubSpot.
- Keep the source ID on every record. An External ID field is the single most useful thing in a migration. It makes reruns safe, links children to parents, and lets anyone trace a Salesforce record back to HubSpot.
- Upsert, never plain insert. Upsert on the External ID updates existing records on a second run instead of creating duplicates.
- Tag the import. A field recording the source and batch lets you find, fix or remove a bad load without touching records created by users.
- Rehearse at least once in a sandbox, ideally a full or partial copy of production. The first load always finds problems. Better there than in production.
- Reconcile with numbers, not impressions. Record counts per object, open pipeline value by stage and activity counts on a sample of accounts should match the HubSpot baseline.
- Have real users test. Ask a few reps to open their own top accounts in the sandbox. They spot missing history faster than any script.
- Keep HubSpot read only for a period after cutover. If something was missed, the original data is still there to check against.
- Write down what you chose not to migrate. Future admins need to know that missing records were a decision, not an error.
What affects how long a HubSpot to Salesforce migration takes?
It depends far more on decisions than on data volume. The load itself is usually the short part of the project. Agreeing how lifecycle stages map, which pipelines survive and what history to keep can take weeks.
The factors that stretch a timeline most often:
- Number of custom objects and associations. Each adds mapping, load order and testing.
- Activity history. Moving years of emails and notes is usually the slowest data workstream.
- Data quality at the start. Duplicates and inconsistent values have to be resolved before mapping is final.
- Integrations. Every tool connected to HubSpot must be rewired, replaced or retired.
- Whether HubSpot stays for marketing. Running both means designing a sync, not just a move.
- Availability of business owners. Mapping sign-off and user testing depend on people outside the project team.
Ask any partner for an estimate built from your inventory, not a standard range.
Should you keep HubSpot for marketing after moving to Salesforce?
Often, yes. Many companies move sales and service to Salesforce and keep HubSpot Marketing Hub for campaigns, email, forms and lead nurturing, connected through HubSpot’s native Salesforce integration.
This changes the migration plan in three ways:
- Marketing data can stay where it is. Email engagement, form submissions and campaign history do not all need to be copied into Salesforce.
- Field ownership must be decided. For each synced field, one system owns it and the other reads it. Fields that both systems can overwrite drift until neither is trusted.
- The sync needs its own design. HubSpot notes that records do not sync automatically after the integration is installed, and that a single contact sync can use up to four Salesforce API calls. Plan the initial sync and your API limits before switching it on.
Our admin’s guide to HubSpot Salesforce integration covers the setup in detail.
How can Mountainise help with your HubSpot to Salesforce migration?
Mountainise works on both sides of this move. We provide Salesforce consulting and HubSpot services, so the migration is planned by people who know where data lives in each system and how they connect.
- Assess your current CRM first. Our AI powered CRM audit connects to HubSpot and surfaces data quality issues and risks before you decide what to move.
- Architecture consultancy. We design the Salesforce data model, record types and sharing around how your business works, before any data arrives.
- Salesforce implementation. We configure the org, build the mapping, run sandbox rehearsals and manage the production cutover.
- Customizations and integrations. We rebuild workflows as Salesforce automation and reconnect the tools that used to talk to HubSpot, including the HubSpot sync if marketing stays on HubSpot.
- Training and adoption. Teams get training, tutorials and documentation for the new processes.
- Administration and ongoing support. After going live, we can manage security, features and day to day administration of the org.
Conclusion
A HubSpot to Salesforce migration succeeds when reps open an account on day one and find everything they had before: the right contacts, the full deal history, and dates that match what happened. That outcome comes from a handful of decisions made early. Keep every HubSpot Record ID, load in dependency order, plan activities as their own workstream, set audit fields before the first insert, and reconcile with numbers before cutover.
If you are planning the move, book a discovery call with Mountainise. We will review your HubSpot setup and outline what a clean migration to Salesforce looks like for your data.
Frequently Asked Questions
Salesforce data migration is the process of moving records from another system, such as HubSpot, spreadsheets or a legacy CRM, into Salesforce objects while keeping their relationships, ownership and history intact. It includes extraction, cleaning, mapping, loading and reconciliation.
Not in one export. The record export gives you property values and associations, but only the first 1,000 associated records per column unless you choose All associated records (CSV only). Notes, calls and emails need a separate route, such as the engagements API or a migration tool.
Only if you plan for it. Salesforce stamps new records with the load date unless the migration user has the Set Audit Fields upon Record Creation permission, and those fields can only be set when the record is first inserted.
Contacts that belong to a company you sell to usually become Contacts under an Account. Early stage records with no company relationship may fit Salesforce Leads. Use the HubSpot lifecycle stage to decide, and keep the original stage in a field for reporting.
Yes, but each phase needs a clear system of record. A common pattern is to move sales first while marketing continues in HubSpot with the integration syncing the two. Avoid periods where both systems accept edits to the same records without a sync.