Integration Services
Business Consulting & Advisory
AI Solutions
AppExchange Development
Tailored Salesforce Engineering
Managed Services
Implementation
Executive Summary
- Decide whether HubSpot leaves or stays before mapping a single field.
- Data migrates, but the business processes around it must be rebuilt.
- Clean and archive HubSpot data before you migrate, not after go-live.
- Give every HubSpot lifecycle stage a clear rule for Leads or Contacts.
- Store each record’s HubSpot ID in Salesforce and go live only when you can explain how you would roll back.
- A sync connector keeps systems aligned but is not a migration plan.
If you lead revenue operations, sales operations, or CRM, a HubSpot to Salesforce migration usually reaches your desk for one of a few reasons: a sales process too complex for the current setup, reporting needs it no longer meets, or an acquisition that brings a mandate to standardize on the parent company’s CRM.
Once the decision to migrate from HubSpot to Salesforce is made, most teams treat it as a simple data transfer. Export the contacts, import the contacts, and call it done. That belief falls apart within the first week of planning. The reason is simple.
The records do move that way. Almost everything else does not.
Salesforce holds around 20%1 of the global CRM market. It offers deeper customization and stronger automation than most teams have previously required. Yet, that very depth makes migration difficult. Workflows, sequences, lists, and reports built in HubSpot stay behind and must be carefully rebuilt in Salesforce, designed around how your team works.
This guide covers what that actually requires: data model translation, rebuild planning for automation and reporting, tool selection, cutover execution, and post-migration adoption. The goal is a migration where critical processes survive alongside the records.
Table of Content
- What Actually Changes When Moving from HubSpot to Salesforce?
- Should HubSpot Leave Entirely or Stay for Marketing?
- How Should You Audit and Clean HubSpot Data Before Mapping It?
- How Does HubSpot to Salesforce Data Migration Translate the Data Model?
- What Cannot Migrate from HubSpot and Must Be Rebuilt?
- Which Tools Should You Use to Load HubSpot Data Into Salesforce?
- How Do You Plan a Cutover That Can Be Rolled Back?
- What Keeps Salesforce Working After Go-Live?
- How Does Achieva Run HubSpot to Salesforce Migrations?
- Conclusion
- Frequently Asked Questions
What Actually Changes When Moving from HubSpot to Salesforce?
Moving from HubSpot to Salesforce changes two things at once: how your data is organized and how your teams get work done. Most migration plans account only for the former, leaving organizations to discover the latter only after go-live.
The divergence begins with data architecture. HubSpot is built around the person, where the contact is the core record, and companies, deals, and tickets attach to it through flexible associations. A lifecycle stage tracks how far each person has progressed.
Salesforce, by contrast, is built around the company. Accounts sit at the center, Contacts belong to Accounts, Opportunities hang off Accounts, and people who are not yet qualified live in a separate Lead object until they convert. Because the same customer, deal, or support request takes a different shape on each platform, every record type needs a translation rule rather than a direct copy.
The process change is the one most plans miss. A HubSpot team’s daily routine runs on workflows that route leads, sequences that send timed follow-ups, lists that segment audiences, forms that capture prospects, and dashboards that track pipeline. None of these is data in the sense an export file understands. They are business logic built on top of the data, and they stay behind when the records are moved. During migration, these elements must be reconstructed in Salesforce using native tools like Flow, list views, reports, and Web-to-Lead.
The trigger for the migration shapes how much of that rebuild lands on your team. For example, if a parent company mandates standardization following an acquisition, your team won’t just rebuild its workflows; it will adopt the parent organization’s framework. And this will widen the scope of change.
The principle that runs through the rest of this guide is simple: data migrates while processes are rebuilt. The sections that follow explore each phase in sequence, beginning with project scope, followed by data audits, data model translations, rebuild registers, tool selection, cutover planning, and post-launch adoption.
Should HubSpot Leave Entirely or Stay for Marketing?
Setting up the project scope is the first step, and it comes before any mapping because it determines what will move, what gets rebuilt, and what stays where it is. There are two paths that organizations can choose from:
1. Replace HubSpot Completely
In this case, Salesforce becomes the system of record for sales, service, and marketing. HubSpot is retired once its records have moved and its processes have been rebuilt. Marketing automation moves to a native Salesforce product, such as Marketing Cloud Account Engagement or Marketing Cloud Next. This path carries the largest rebuild, because every marketing asset joins the sales and service processes on the migration list.
2. Keep HubSpot for Marketing and Use Salesforce for Sales and Service
Here, Salesforce becomes the sales and service CRM while HubSpot stays as the marketing platform, connected to Salesforce through integration. This approach creates a project that combines migration with integration. Sales records move to Salesforce. Marketing contacts, campaigns, and nurture programs stay in HubSpot, and the integration keeps shared records, such as contacts and companies, aligned between the two systems.
These four questions usually decide which path suits your business:
- Where does marketing automation live today? List the nurture programs, forms, landing pages, and scoring models that would need to be rebuilt under full replacement.
- How dependent is the marketing team on HubSpot? A team that runs every campaign in HubSpot is likely to lose momentum during a rebuild, and that cost must factor into your decision.
- What does licensing look like under each path? Compare the platforms you would pay for, not just the one you are adding.
- What must leadership be able to report, and from which system? Reporting needs often reveal where the system of record must sit.
For many teams, keeping HubSpot for marketing is the better fit. If you choose to migrate HubSpot to Salesforce for sales and service only, the integration design becomes a project in its own right. Our HubSpot and Salesforce integration guide covers how to run both platforms in sync. Whichever path you select, the rest of this guide focuses on the records and processes that move out of HubSpot.
How Should You Audit and Clean HubSpot Data Before Mapping It?
Once scope is established, you have a clear inventory of which HubSpot records require migration. The next job is to shrink that dataset and raise its quality, because a migration copies problems as faithfully as it copies value. In Salesforce’s State of Data and Analytics2 research, data and analytics leaders estimated that 26% of their organizational data is untrustworthy. Records like that do not improve on the way into a new platform.
An audit shows you what you would be carrying over. A useful one covers six areas:
- Record counts by object, so you have a baseline to validate against after the load.
- Duplicates, matched on email for contacts and on domain for companies.
- Incomplete or stale records, such as contacts missing key fields or showing no recent activity.
- Abandoned properties that nobody fills in or reports on.
- Records assigned to former employees, which require reassignment to new owners before they can load.
- Records kept for legal or audit reasons, which the business must retain but does not use day-to-day.
The guiding principle here is hygiene first. Clean your data before you move, not afterward. Fixing data in HubSpot, where your team knows its context, is far easier than fixing it in Salesforce once workflows and reports depend on it. While cleaning, standardize picklist values and formats, and record these standards in a data dictionary that can become your governance reference in Salesforce.
Cleaning also forces a decision about what should move at all. As Peter Drucker put it, ‘There is nothing so useless as doing efficiently that which should not be done at all.’ Every stale contact and unused property you leave behind is one less thing to maintain in Salesforce.
Records a named team will use after launch, and that are accurate enough to act on, should migrate. Records the business only needs to retain belong in an archive export that stays accessible. Capture these decisions in a mapping document and a data quality report, so the next phase starts with an agreed-upon list. The rule is simple: migrate what you will actively use; archive what you only need to keep.
Here's How You Can Move Your Data to Salesforce Without Disruptions
How Does HubSpot to Salesforce Data Migration Translate the Data Model?
With a clean, scoped data set in hand, the hardest part of HubSpot to Salesforce data migration begins: translating one data model into another. Because HubSpot starts with the person, and Salesforce starts with the company, nearly every record type needs a translation rule.
The table below sets out each translation and the failure that often follows when the rule is skipped.
| HubSpot | Salesforce | Translation Rule | Usual Failure |
|---|---|---|---|
|
Contacts and lifecycle stages |
Leads, or Contacts linked to Accounts |
Define a rule for every lifecycle stage. Unqualified people without a company usually become Leads; customers and people tied to a company become Contacts. Keep the original stage in a custom field. |
Everyone loads as one object, which breaks lead conversion and funnel reporting. |
|
Companies |
Accounts |
Deduplicate by domain and map parent and child companies to the Parent Account field. |
Name variants create duplicate Accounts that split the relationship history. |
|
Contacts associated with several companies |
One primary Account, plus account contact relationships |
Set a rule for the primary company and load other links as additional relationships. |
Secondary relationships are silently dropped. |
|
Deals and pipelines |
Opportunities, stages, record types, and sales processes |
Map each pipeline to a record type and sales process, and each deal stage to a stage value. |
Stages merge or misalign, and forecasts stop matching reality. |
|
Tickets |
Cases |
Map ticket pipelines and statuses to case support processes and statuses. |
Open and closed states are lost or misread. |
|
Associations |
Lookup and junction relationships |
Load parent records first, then resolve child links using legacy HubSpot IDs. |
Child records arrive orphaned because their parent IDs do not exist yet. |
|
Engagement history |
Tasks, Events, and notes |
Decide how much history to bring, and keep what sales actually uses. |
Every open and click is loaded, bloating the org without adding insight. |
|
Files and attachments |
Files linked to records |
Re-link each file to its record using legacy IDs. |
Files land in Salesforce attached to nothing. |
|
Custom objects and properties |
Custom objects and fields |
Map only what survived the audit, and convert field types where needed. |
Values are truncated or rejected because field types do not match. |
|
Owners and users |
Users and record owners |
Create users and map owner IDs before any records load. |
Records default to the person running the load. |
Three areas demand a closer look because they usually involve a lot of rework.
- Lifecycle Stages: HubSpot treats everyone as a contact, so its lifecycle stages must be mapped deliberately onto Salesforce’s Lead, Contact, and Account model. Remember that lifecycle stage measures where a person sits in the funnel, while lead status measures qualification on a single record. Forcing one into the other corrupts both.
- Account Relationships: Salesforce expects each contact to have a primary account, whereas HubSpot allows a contact to sit under several companies. You must create a rule that picks the primary company, while using Salesforce’s account contact relationships to preserve the rest. HubSpot’s record exports can include association columns, which give you the raw material for both.
- Field Types: Small mismatches, such as converting a HubSpot checkbox property into a Salesforce picklist, pass unnoticed in small test files and fail at production volume.
One rule protects everything above. Every migrated record should carry its HubSpot ID in a dedicated custom field. Set as an external ID, it lets you match records during reloads, trace any Salesforce record back to its source, and re-link associations and files after the primary data load. It is also what makes rollback possible, as the cutover section shows.
Not sure how your HubSpot data maps to this table? Achieva’s Salesforce team can review it with you before you commit.
What Cannot Migrate from HubSpot and Must Be Rebuilt?
When the contacts, companies, and deals are moved, they appear in Salesforce on schedule, but the workflows that routed them, the sequences that nurtured them, and the dashboards that tracked them do not follow automatically.
A rebuild register lists each of those assets, where it will be rebuilt, and who owns it.
| HubSpot Asset | Rebuild in Salesforce | Typical Owner | Notes |
|---|---|---|---|
|
Workflows |
Flow |
Revenue or sales operations |
Salesforce ended support for Workflow Rules and Process Builder on December 31, 20253, so Flow is the target. |
|
Sequences |
Sales Engagement cadences |
Sales leadership |
Check licensing for Sales Engagement before planning the rebuild. |
|
Lists and segments |
List views, reports, or campaigns |
Marketing operations |
Rebuild active logic; static lists can often be archived. |
|
Forms |
Web-to-Lead or the chosen marketing platform |
Marketing |
Implementation depends on the scope decision. |
|
Email templates |
Salesforce email templates or the marketing platform |
Marketing |
HubSpot personalization tokens do not carry over and need manual recreation. |
|
Lead scoring |
The marketing platform, or field logic in Flow |
Marketing and sales together |
Agree on the scoring model before rebuilding it. |
|
Reports and dashboards |
Report types, reports, and dashboards |
Revenue operations |
Rebuild against the new data model rather than copying legacy layouts. |
|
Teams and permissions |
Roles, profiles, and permission sets |
Salesforce admin |
Design permissions based on who needs to see what, rather than mimicking HubSpot’s team structure. |
|
Integrations with other tools |
Reconnected to Salesforce, replaced, or retired |
IT |
Inventory every application that reads from or writes to HubSpot. |
Two practices make this register work. First, rebuild what each process does today rather than what it was designed to do years ago. Many HubSpot workflows carry branches nobody uses, and a migration is the right moment to drop them.
Second, treat each row in the register as a business process with an owner in sales, marketing, or operations. The people who rely on that process every day should test and sign off its rebuilt version before go-live. Where standard configuration falls short, Salesforce customization can close the gap.
Used this way, the register becomes a powerful planning tool. It turns “what will we lose?” into a list with names, owners, and sign-off dates that a project plan can actually track.
Which Tools Should You Use to Load HubSpot Data Into Salesforce?
With the data mapped and the rebuild planned, tool choice becomes a vital decision driven by data volume and complexity rather than preference. Aligning with Salesforce Trailhead guidance4, options break down across distinct categories:
- Data Import Wizard: Suits loads of fewer than 50,000 records into supported objects with fewer than 50 fields on the target object and simple mappings. Check its object list in Setup before planning around it. In most HubSpot migrations, deals and activity history need a different tool.
- Data Loader: Handles volumes ranging from 50,000 to 150 million records and objects the wizard does not support, alongside scheduled or repeatable jobs. Its upsert by external ID pairs naturally with the legacy HubSpot ID field.
- Third-party migration tools and integration platforms: Add automated mapping and data transformation capabilities. Evaluate them on how well they handle HubSpot associations, error reporting, and repeatable test runs.
- Custom scripts against the HubSpot and Salesforce APIs: Fit complex cases that need sophisticated transformation logic that standard tools cannot express.
One tool does not belong on this list: HubSpot’s native Salesforce integration. This integration syncs contacts, companies, deals, activities, and other supported data between the two platforms according to your integration settings. And that makes it ideal for the partial-move path, where both systems keep running. It is, however, not a migration plan. A sync connector keeps two systems aligned. It does not translate a data model, load history in dependency order, or give you a way back.
How Do You Plan a Cutover That Can Be Rolled Back?
While the right tools handle data loading, the cutover plan determines whether your go-live will be safe. The plan follows a fixed order, where every step exists to catch a problem before your users do.
- Run a small test load. Start with a small sample in a sandbox to confirm data mappings, transformations, and object associations before scaling up.
- Run a full test load. Use production-like volumes and the exact sequence planned for go-live, because edge cases appear only at scale.
- Load in dependency order. Users first, then Accounts, Contacts and Leads, Opportunities, Cases, activities, and finally files, so every relationship can resolve against a record that already exists.
- Freeze HubSpot. Announce a data freeze window so no new changes land in HubSpot while the final load runs.
- Load the final delta. Move only the records created or changed since the last full test load.
- Validate against HubSpot. Compare record counts by object, spot-check records against their HubSpot originals, and reconcile key reports such as pipeline value by stage.
- Complete user acceptance testing. Require business owners to confirm that data, rebuilt workflows, and reports behave as expected. Signed-off UAT should be treated as a formal phase deliverable.
- Run in parallel for a defined period. Keep HubSpot available with view-only permissions, so users can check context while the team resolves discrepancies.
- Keep a rollback path ready. Because every record carries its HubSpot ID, you can identify what was loaded, remove or correct it, and reload, or return users to HubSpot if validation fails.
Decide in advance who makes the go or no-go call. In most migrations, this call belongs to the executive sponsor, advised by the revenue operations lead and the process owners who signed off on UAT, against criteria agreed before cutover begins. Go live only when that leadership group can explain how you would roll back if needed.
What Keeps Salesforce Working After Go-Live?
User adoption ultimately determines whether the migration pays off. A CRM migration is only finished when people use the new system, not when the data loads.
- Train by role, because a sales rep, a marketing manager, and a service agent use Salesforce in different ways. Role-based Salesforce training keeps each group focused on its own workflows.
- Set a short, clearly announced window for users to report mapping issues, and fix them quickly while the team still remembers how things looked in HubSpot.
- Decommission HubSpot features and licenses on a schedule tied to the scope decision. Under full replacement, HubSpot retires once parallel running ends. Under a partial move, only the sales and service features go.
- Protect the cleanup you achieved before the move. Implementing validation rules and duplicate rules in Salesforce stops the same problems from building up again, and a periodic Salesforce org health check confirms those safeguards still work.
Significance of Data Cleansing and Migration in Salesforce Implementation
How Does Achieva Run HubSpot to Salesforce Migrations?
As a trusted Salesforce Summit Partner, Achieva treats a HubSpot to Salesforce migration as an evolution of your data model and processes, not a simple file transfer. Our approach follows the structured framework described in this guide.
We start with the scope decision, so the project is built for the right end state, whether HubSpot leaves or stays for marketing. Next, we audit and clean your HubSpot data before anything is mapped, working closely with your team to determine what migrates and what gets archived. From there, we build a translation table for your actual objects, properties, and lifecycle stages, with a legacy HubSpot ID on every record.
We then run the rebuild register with your process owners, so workflows, sequences, forms, and reports are rebuilt in Salesforce and signed off by the people who use them daily. Finally, we plan and run a cutover with sandbox test loads, a freeze window, validation, and a tested rollback path.
Our specialized Salesforce data migration services cover the move itself, and our Salesforce implementation services handle the configuration and rebuild work around it. If you are weighing a move away from HubSpot, we would be glad to plan the migration and cutover with you, starting with the scope decision.
Conclusion
A HubSpot to Salesforce migration works best when you make the tough calls before any data moves. Decide whether HubSpot leaves or stays, clean up what you plan to carry over, and give every record type a clear translation rule. From there, plan who rebuilds each process, and cut over with a tested way back. Always remember the core principle: data migrates, but processes get rebuilt, and planning for both keeps the go-live day calm and controlled.
External Links:
- [1]: Salesforce
- [2]: Salesforce
- [3]: Salesforce
- [4]: Trailhead
