Salesforce to HubSpot Migration: The Complete Checklist

Moving from Salesforce to HubSpot is one of the most common projects I run, and one of the easiest to make a mess of. The temptation is to treat it as an export here, an import there, job done. That is exactly how you end up shipping a decade of accumulated rubbish into a shiny new system. A migration is your one good chance to clean up the mess and rebuild your processes the way they should have worked all along, rather than faithfully recreating the old chaos. This checklist walks through every phase so nothing slips through the cracks.

Work through it in order. The phases build on each other, and skipping the planning steps is precisely what produces the nasty surprises at cutover.

Phase 1: Plan and audit before you touch any data

Get this right and the rest is mostly mechanical. Rush it and you will be cleaning up for months.

1. Define what success actually looks like, and name who owns the project internally. “Everyone” owns nothing.
2. List every Salesforce object, custom object, and field in use, and be honest about which ones you genuinely need.
3. Identify your data volumes: how many accounts, contacts, opportunities, and activities.
4. Audit data quality now, before it travels: duplicates, empty fields, inconsistent picklists, stale records.
5. Document every workflow, process builder, flow, validation rule, and assignment rule.
6. List all integrations and connected apps touching Salesforce.
7. Inventory the reports and dashboards people genuinely use. Most of them, you will find, nobody opens.
8. Agree a cutover date and a parallel-running window.

If your Salesforce org is a mess, decide now what comes across and what gets left behind. You do not have to migrate everything. Honestly, you usually should not.

Phase 2: Map your objects and fields

HubSpot and Salesforce model data differently, so a clean one-to-one mapping is not always on the table. Plan the structure deliberately rather than discovering the mismatches mid-import. A solid CRM setup in HubSpot starts right here.

Salesforce	HubSpot	Notes
Account	Company	Map ownership and parent/child relationships carefully
Contact	Contact	Watch for contacts not linked to an account
Lead	Contact	HubSpot has no separate Lead object; use lifecycle stage instead
Opportunity	Deal	Map stages to a HubSpot deal pipeline
Opportunity Stage	Deal stage	Rationalise stages while you are at it
Case	Ticket	Requires Service Hub
Custom object	Custom object	Enterprise tier only; otherwise rethink the model
Campaign	Marketing campaign / list	Depends on how you use them
Task / Event	Task / Meeting / Activity	Map activity types thoughtfully

Key field-level steps:

1. Map each Salesforce field to a HubSpot property, creating new properties where you have to.
2. Recreate picklists as dropdown or radio properties, and tidy up the values as you go. This is your chance.
3. Decide how record ownership transfers, and how owners map to HubSpot users.
4. Plan the relationships: company-to-contact associations, deal associations, and parent companies.
5. Flag any fields that ought to be calculation or workflow-driven properties rather than something a human keys in by hand.

A note on custom objects

If you lean heavily on Salesforce custom objects, remember that HubSpot custom objects need an Enterprise subscription. On Professional you will be modelling that data as extra properties, activities, or a connected app instead. Sort this out before you commit to a tier, not after, because it is a painful thing to discover once the contract is signed.

Phase 3: Clean, dedupe, and prepare the data

Migrate clean data, not your historical mess. This is the highest-value phase, and the one teams chronically under-resource because it is the least glamorous.

1. Deduplicate accounts, contacts, and opportunities, either in Salesforce or in the export files.
2. Standardise formats: phone numbers, country names, job titles, picklist values.
3. Fill or strip out the critical empty fields your processes actually depend on.
4. Decide your history strategy: which activities, emails, and notes come across, and how far back you really need to go.
5. Export in batches by object, and keep the Salesforce record ID as a reference for re-linking later. You will be glad of it.
6. Validate the exports against your mapping before a single record goes into HubSpot.

History is where migrations quietly balloon in cost. Be ruthless about it. Full activity history for the last two years is usually plenty, and hauling a decade of logged calls across almost never earns its keep. Nobody is reading the call notes from 2017.

Phase 4: Rebuild in HubSpot

Now you build the destination, then pour the data into it. Order matters more than you would think.

Set up the foundation

1. Create your properties, pipelines, lifecycle stages, and deal stages per the mapping.
2. Add users and configure permissions and teams to match your structure.
3. Configure email, domains, tracking, and any sender setup.

Recreate automation

Do not copy your Salesforce automation across blindly. Use the move to thin it out. Rebuild lead routing, deal stage automation, internal notifications, and handovers as HubSpot workflows, and treat this as the moment to quietly retire the rules nobody can remember creating or explain the purpose of. Thoughtful automation here buys back hours every week once you are live. Lazy automation just recreates the noise.

Rebuild reports, dashboards, and integrations

1. Rebuild only the reports and dashboards people actually use. Refer back to that inventory from Phase 1.
2. Recreate or replace your integrations, starting with the ones the business leans on every day.
3. Test each integration on its own before you let it anywhere near live data.

Import the data

Import in an order that lets the relationships resolve: companies first, then contacts, then deals, then activities. Lean on those stored Salesforce record IDs to wire the associations up correctly. Get the order wrong and you will spend a day chasing orphaned records.

Phase 5: Validate, run in parallel, and cut over

Resist the urge to flip the switch the second the data lands. This is where discipline pays off.

1. Validate. Spot-check record counts, associations, owners, and key fields against Salesforce. Confirm the automation fires the way you expect on test records, not just in your head.
2. Test with real users. Get a few people to work real (or realistic) scenarios end to end, and log every issue, however small.
3. Run in parallel. Keep Salesforce read-only for an agreed window while the team works in HubSpot. This is your safety net, and it is cheap.
4. Cut over. Once you genuinely trust it, make HubSpot the system of record, tell everyone clearly that the switch has happened, and set Salesforce to read-only or archive it.
5. Post-migration care. Block out a fortnight of close support. Fix issues fast, deliver the training, and mop up the small things that always crawl out of the woodwork once people start using it for real.

What to watch out for

The same handful of traps come up on nearly every move:

• The Lead object shock. HubSpot has no Lead object. Leads become contacts with a lifecycle stage, which is usually a better model, but it reliably throws a Salesforce-trained team on day one. Warn them early.
• Over-migrating. Drag every field, report, and rule across and congratulations, you have rebuilt the exact clutter you were trying to leave behind.
• Custom object assumptions. Confirm your tier actually supports what you need before you design the whole thing around it.
• Underestimating history and activities. This is where the volume hides, and where the timeline quietly doubles.
• No parallel run. Switching Salesforce off with no fallback is a risk you simply do not need to take.

Frequently asked questions

How long does a Salesforce to HubSpot migration take?

It depends on your data volume, how heavily customised your Salesforce org is, and how many integrations are tangled up in it. A clean, straightforward move can be done in a couple of weeks. A complex, heavily customised org with years of history behind it can run to a few months, and there is no point pretending otherwise.

Can I keep my Salesforce history when I move to HubSpot?

You can bring across the records and the historical activity that genuinely matter, but not always a perfect copy of every last log and field. Decide early what history you actually need, because chasing a total one-to-one copy piles on cost and almost never earns it back.

Should I run Salesforce and HubSpot in parallel before switching?

Yes. A short parallel run before cutover is the safest approach by a distance. It lets you validate the migrated data and your rebuilt processes in HubSpot while Salesforce is still sitting there as a fallback, so you only switch the old system off once you actually trust the new one. I would not run a migration any other way.

Make the move with confidence

A Salesforce to HubSpot migration is a real opportunity, not just a chore, but only if you treat it as a process redesign rather than a copy-paste. Plan properly, clean ruthlessly, rebuild deliberately, test before you commit. Do those four things and the new system will be better than the old one, not just newer.

If you would rather not pick your way through this on your own, migration is a core part of what I do. Get in touch and we will map out your move.