Salesforce to HubSpot migration: map it, then rebuild
Moving from Salesforce to HubSpot is sold as a switch. Turn on a connector, wait for the rows, cut over on a Friday. That is not a migration. A connector keeps two live systems talking. It does not backfill history, decide what a deal is in HubSpot, or rebuild pipelines, properties, and permission sets so your team can actually run the new portal. If you skip the map, you will spend the next year explaining why HubSpot does not match the old reports.
This page is how I run a Salesforce to HubSpot migration: object mapping, architecture in HubSpot that matches how you sell, import order, a parallel run, then cutover. It is written for marketing and RevOps leads at small and mid-size B2B companies who need the move to survive contact with real deals, not a demo org. I will not promise zero data loss. We plan the move. We do not sell a guarantee.
In scope: what a migration actually is, why a connector is not one, what has to be mapped, architecture then import order, what will not survive, parallel run and cutover, how I do the work, and a short note on Zoho and spreadsheets. Out of scope: a HubSpot portal audit of a mess you are landing in (that is the audit page), a net-new implementation with no source system (that is how I implement), HubSpot.com's switch marketing, and a row-mover that dumps contacts into a default portal.
What this migration actually is
A Salesforce to HubSpot migration is a mapped rebuild. Salesforce is the source. HubSpot is the system you will run. The work is a written object map, HubSpot architecture that matches how you sell, an import order that does not break associations, a parallel run on live records, then a cutover date after which HubSpot is the system of record. If any of that is missing, you did not migrate. You copied rows into a second CRM.
What is in: accounts and contacts, leads, opportunities, products and line items, activities, custom objects, associations, owners, create dates, and legacy Salesforce IDs. Also the HubSpot properties, pipelines, lifecycle, and permission sets those records will land in. What is out: turning on the native Salesforce connector and calling it done, dumping a CSV into default HubSpot stages, cloning Salesforce inside HubSpot so reps have a familiar mess, and an overnight cutover with no map.
The point of the rebuild is not to make HubSpot look like Salesforce. The point is to land in a portal your team can run. If Salesforce was already lying (duplicate accounts, dummy stages, fields nobody can explain) bringing that over is how the new portal starts already lying.
A connector is not a migration
HubSpot's native Salesforce integration is a sync. Used correctly, it is useful during a parallel run: two live systems, a defined window, Salesforce still the source of truth until I say otherwise. It does not backfill years of history. It does not decide whether a Salesforce Opportunity becomes a HubSpot deal with line items. It does not rebuild permission sets. It does not fix create dates that will get restamped if you import without exporting them.
A row mover is not a migration either. Moving contacts without mapping associations, activities, and create dates is how a lead-source report looks like everything was born on cutover day. The report is not wrong in HubSpot's logic. The data is. Cleanup first, then backfill. Skip that, and every date-based dashboard in the new portal is a guess.
I will use the connector where it belongs. I will not sell it as the project. If a vendor is quoting you a move as "we load the rows," ask them what happens to associations, activities, owners, and create dates. If they cannot answer on the object, they are not migrating you.
What has to be mapped
Objects first. Salesforce Account to HubSpot company. Contact to contact. Lead is a decision, not a default: convert in Salesforce and map as contact, map leads separately, or both, on purpose. Opportunity to deal. Products and opportunity line items to HubSpot line items if you want a revenue report that is not a story you tell yourselves. If the deal has no line items in HubSpot, and Salesforce was counting products, the new revenue report will not reconcile.
Then associations. Which contact is on which deal. Which company owns the relationship. If that is fuzzy in Salesforce, it will be fuzzy in HubSpot, only now you have a second system arguing about it. I would rather map the mess and write it down than pretend HubSpot will infer the relationship.
Then activities. Notes, tasks, meetings, logged email. Some of this will not come across clean. That belongs in what will not survive, not in a surprise after cutover. Then custom objects. If Salesforce used a custom object for something HubSpot already has, I will say so. If you need a custom object in HubSpot, we map it. We do not invent one because the old org had it.
Every record needs a unique identifier you can upsert on. Email for people, in most portals. Legacy Salesforce ID stored on the HubSpot record so you can prove parity. Create date exported, not restamped by the import. Miss the identifier and you will create duplicates. Miss the create date and history dies even if the rows arrived.
Architecture, then import order
Cleanup first, then backfill. Do not skip steps. If we import into a default HubSpot portal, we have migrated into a template. The architecture has to exist before the load: properties with owners, pipelines that match how you sell, a written definition of a deal, lifecycle that maps to real handoffs, permission sets that separate view from edit. Then we import.
Order matters because associations depend on parents existing. Companies first. Contacts second. Deals third. Line items after deals. Activities after the records they hang off. Custom objects last. If we load deals before companies, associations break. If we turn on workflows before the data holds still, the workflows write junk on the way in. If we skip create dates, every report by date is a lie from day one.
I verify in the portal on a sample, not in a spreadsheet that says the row counts matched. Row counts can match and the associations can still be wrong. Same account, same deal, same next step, side by side with Salesforce. If they do not match, we do not load the rest.
What will not survive
I will not promise zero data loss. Some Salesforce-only setup does not have a HubSpot twin. Sharing rules. Some page layouts. Some activity types. Some custom buttons and automations. We map what your team still needs. We leave the rest, in writing, before cutover. If that is not in the decision log, it is not agreed.
Junk should not survive on purpose. Duplicate accounts. Dummy stages. Fields nobody can explain. Bringing that over is how the new portal starts already lying. Create dates, owners, and associations only survive if we export them and map them. Miss that, and the history is gone even if every row has a HubSpot ID.
I will be specific about what we are not moving. A vague "some loss is possible" is how people feel betrayed on Monday. A list of objects, activity types, and automations that stay behind is how you cut over without a surprise. We plan the move. We do not sell a guarantee.
Parallel run and cutover
We run both systems for a defined window. Salesforce remains source of truth until cutover. HubSpot gets the mapped load, then new work is proven on live records. The connector, if we use it, lives in this window. It is not a substitute for the map.
Parity is a sample, not a feeling. Same account, same deal, same next step. Amount, line items, owner, create date. If they do not match, we do not cut over. Cutover is one date. After that, new records in HubSpot. Salesforce goes read-only, then off. Living in both forever is how you get two pipelines and one argument.
I will not pick a Friday and hope. Cutover is after the sample holds still, after workflows are still off or tightly owned, and after someone on your side can say what a deal is in HubSpot without looking at Salesforce.
How I run a Salesforce to HubSpot migration
I do the work. All Gusto is a HubSpot Solutions Partner, est. 2014. Senior only. No juniors. No offshore ticket queue. That is the delivery model, and it is on About.
I start with what a deal is in both systems. Amount, line items, closed versus backlog. Then the object map. Then HubSpot architecture. Then a sample load, verified in the portal. I export unique IDs and create dates. I upsert. I check associations on real records. I will not turn on the full workflow stack until the data holds still. I will tell you what not to bring. Honest over agreeable.
I will not invent a timeline for an unscoped org on this page. After I can see Salesforce and the HubSpot portal you are landing in, I will tell you what has to be true before the first sample load.
Zoho and spreadsheets
Same job, smaller objects. Map, then rebuild. Zoho has its own modules and custom fields, and the same rule applies: a connector is not the migration. Spreadsheets have no associations unless you invent them, so we decide those before import. Unique identifier still matters. Create dates still get restamped if you skip the export.
Dedicated pages for those sources come later. I will not pretend those URLs are live. If Zoho or a pile of sheets is your source, say so on contact. Do not hire a Salesforce page to cover for a different system.
After the move
The migration is the move. It is not automatically an implementation, and it is not automatically an audit.
If you are moving into a HubSpot portal that is already a mess, diagnose it first. That is a HubSpot portal audit. Loading Salesforce onto dirty HubSpot objects will not clean either system. If the HubSpot side still needs to be built so it matches how you sell, that is how I implement. Do not hire that by default. Sometimes the architecture and the load belong in one sequence. They are still two jobs, written down as two jobs.
FAQ
Can we just turn on HubSpot's Salesforce integration and call it a migration?
No. The native sync is a connector. It is useful in a parallel run. It does not backfill history, rebuild HubSpot architecture, or map associations, activities, and create dates. I will use it where it belongs. I will not sell it as the project.
Will we lose data?
Some things will not survive, and I will write them down before cutover. I will not promise zero data loss. Create dates, owners, and associations only survive if we export and map them. Salesforce-only setup with no HubSpot twin stays behind. Junk should stay behind on purpose. We plan the move. We do not sell a guarantee.
How long does a Salesforce to HubSpot migration take?
It depends on how clean Salesforce is, whether HubSpot already exists, and whether anyone on your side can say what a deal is. I will not put a fake number of hours on an unscoped org. After I can see both systems, I will tell you what the sample load is for and what has to be true before cutover.
Do we have to run Salesforce and HubSpot in parallel?
Yes, for a defined window, unless the org is small enough that a sample load plus a short freeze is safer. Living in both forever is the failure mode. Cutover is one date. One system of record after that.
What about our Salesforce custom objects?
We map them on purpose, or we do not bring them. If HubSpot already has the object, I will say so. If you need a HubSpot custom object, we build it to match how you sell, not to mirror the old org. Custom objects last in the import order, after the records they hang off exist.
Who does the migration?
I do. No junior, no offshore pod. Ask anyone you are evaluating for the names of the people in both orgs. The person who can explain the object map on the call is the person you are hiring.
Should we audit HubSpot before we migrate into it?
If the HubSpot portal already exists and is drifted, yes. Loading mapped Salesforce onto unowned properties and fighting workflows encodes both messes. The audit is how we decide whether the landing zone can take the load.
Let's talk HubSpot
Tell me what you are leaving, and what has to be true in HubSpot on day one. I will tell you whether this is a migration, an audit of the portal you are landing in, or both, in that order.