HubSpot to Salesforce
Move to Salesforce without losing your history
Every contact, deal, ticket, and note, mapped to the right Salesforce object and validated before anything goes live. Your old portal stays up until you say the new one is right.
Teams we have built CRM systems for
UAE
USA
Why teams make this move
The honest reasons, not the ones on a sales deck.
You outgrew the reporting
The questions leadership asks now need joins and rollups HubSpot will not give you without a fight.
You need real permissions
You have reached the point where not everyone should see every record, and HubSpot's permission model is too coarse for that.
One pipeline no longer fits
Different products, regions, or motions need genuinely different sales processes, with different stages and different rules.
The rest of the business is already there
Finance, support, or the parent company runs on Salesforce, and being the one team outside it is costing you more than the move would.
What actually gets migrated
This is the part most vendors keep vague. Here is the real mapping, including the things that do not move cleanly.
| Feature | Becomes in Salesforce | What to watch |
|---|---|---|
| Contacts | Contacts, or Leads | Salesforce splits people into Leads and Contacts. HubSpot does not. We agree the split by lifecycle stage before anything moves. |
| Companies | Accounts | Associations become Account lookups. Contacts with no company get flagged for you, not silently dropped. |
| Deals | Opportunities | Deal pipelines become Sales Processes and Record Types. Stage names almost never map one to one, so we agree them up front. |
| Tickets | Cases | Ticket pipelines and statuses become Case record types and status values. |
| Properties | Fields | Custom properties become custom fields, and dropdowns become picklists. This is where dirty values surface, so cleanup happens here. |
| Workflows | Flows | Rebuilt, not copied. There is no import path between the two. We rebuild the logic in Flow Builder and run it side by side before switching. |
| Lists | Reports, or Campaigns and Campaign Members | Active lists become report filters. Static lists usually become Campaigns. |
| Products and line items | Products, Price Books, Opportunity Line Items | Salesforce requires a Price Book and HubSpot has no equivalent, so we build one from your pricing. |
| Quotes | Quotes | Templates get rebuilt. Heavy quoting logic is a CPQ conversation, and we will tell you if you are in that territory. |
| Emails, calls, meetings, notes | Tasks, Events, EmailMessage, Notes | Activity history is the slowest part of the load and the part teams most often forget to budget time for. |
| Files and attachments | Files | Large libraries take time and count against your org's storage limits, so we size this before we start. |
| Owners and users | Users and Role Hierarchy | Record ownership only lands correctly if the users exist first. This is always step one, never an afterthought. |
| Forms | Web-to-Lead, or keep HubSpot forms | Plenty of teams keep HubSpot for marketing and sync the two. If that is cheaper for you, we will say so. |
If you have custom objects or an integration not listed here, tell us and we will map it explicitly in the plan rather than discover it mid-migration.
Our migration process
Nothing goes live until you have seen it work on your own data.
Discovery and field mapping
We inventory every object, property, and integration, then write the mapping down and get your sign-off on it before touching data.
Test migration
A full run into a Salesforce sandbox. You get to open it, search it, and find the things that look wrong while they are still cheap to fix.
Cleanup and dedupe
Duplicates, dead fields, and inconsistent values get resolved before the real load, not carried into your new org.
Validation
Record counts and spot checks against the source, in a document you approve. If the numbers do not match, we do not proceed.
Cutover
The real load, in an agreed window, with your old portal still live and readable the entire time.
Post-migration support
We stay on for an agreed period after go-live for the things that only surface once real users start clicking.
How we protect your data
The whole job is not losing anything. Everything below is standard, not an upsell.
A full export first
We take a complete export of your HubSpot data before we touch anything, and you get a copy of it.
Sandbox before production
Every migration runs in a sandbox first. Production sees the data once, on cutover day, after it has already worked somewhere else.
You approve the counts
No cutover happens until you have signed off on record counts and spot checks against your source data.
A rollback plan on paper
Written down before we start, not improvised on the day. Your old system stays live and readable until you tell us to shut it off.
Timeline, and who does what
Most migrations run four to eight weeks. What moves that number is record volume, how much activity history you keep, and how many custom objects and integrations are in play. The other thing that moves it is how fast decisions come back, which is why this list exists.
What we do
- Inventory your objects, properties, and integrations
- Write the field mapping and get it approved
- Run the test migration into a sandbox
- Deduplicate and clean the data before load
- Validate record counts against the source
- Run the cutover and stay on afterwards
What we need from you
- Admin access to both systems, when each step needs it
- One person who can decide how fields map, and make that decision stick
- Someone to sign off on the record counts before cutover
- A freeze window where nobody edits records during the load
- A list of the integrations you cannot live without
Related work
Frequently asked questions
How much downtime will we have?
For most teams, none that they notice. The load happens in an agreed window, usually over a weekend, and your HubSpot portal stays live and readable the whole time. What we do ask for is a freeze window where nobody edits records mid-load, because edits made during a migration are the ones that go missing.
What drives the cost?
Three things, in order: how much activity history you want to keep, how many custom objects and integrations are involved, and how dirty the data is. Record count matters far less than people expect. We quote a fixed price after discovery, so the number you approve is the number you pay.
Do we keep our historical activity?
Yes, if you want it. Emails, calls, meetings, and notes come across as Salesforce activities. It is worth asking whether you need all of it, because activity history is usually the slowest and most expensive part of the load, and plenty of teams keep two years instead of ten.
What happens to our custom objects?
They get mapped explicitly in the plan, not discovered halfway through. Salesforce is generally more flexible here than HubSpot, so custom objects moving in this direction usually land cleanly.
Which integrations will break?
Anything wired directly to HubSpot will need repointing, and we list those in discovery so there are no surprises. Some tools have a Salesforce connector and it is a config change. Others need rebuilding. We tell you which is which before you commit.
Will our team need retraining?
Yes. Salesforce is not HubSpot with a different logo, and pretending otherwise is how migrations fail after a successful data load. We include a walkthrough for your team and documentation they can go back to.
Can we run both systems in parallel?
For a while, yes, and many teams do keep HubSpot for marketing while sales moves to Salesforce. Running both as a full CRM long term is a slow way to get two sets of bad data, so we would talk you out of that.
Get a migration plan
Tell us roughly what is in your portal and we will come back with a mapping outline, a timeline, and what it would cost. No obligation to proceed.
No sales sequence, no drip campaign. One human, one reply.