Salesforce to HubSpot Migration: The Complete Checklist

Moving from Salesforce to HubSpot is one of the most common projects I run, and it is also one of the easiest to get wrong. The temptation is to treat it as a data export and import. In reality, a migration is a chance to clean up years of accumulated mess and rebuild your processes the way they should work, not just copy them across. 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 what causes painful surprises at cutover.

Phase 1: Plan and audit before you touch any data

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

1. Define what success looks like and who owns the project internally.
2. List every Salesforce object, custom object, and field in use, and flag which are actually needed.
3. Identify your data volumes: how many accounts, contacts, opportunities, and activities.
4. Audit data quality now: 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 reports and dashboards that people genuinely use (most go unused).
8. Agree a cutover date and a parallel-running window.

If your Salesforce instance is messy, decide now what to bring across and what to leave behind. You do not have to migrate everything, and you usually should not.

Phase 2: Map your objects and fields

HubSpot and Salesforce model data differently, so direct one-to-one mapping is not always possible. Plan the structure deliberately. A solid CRM setup in HubSpot starts 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 needed.
2. Recreate picklists as dropdown or radio properties, standardising values as you go.
3. Decide how record ownership transfers and how owners map to HubSpot users.
4. Plan relationships: company-to-contact associations, deal associations, and parent companies.
5. Note any fields that should become calculation or workflow-driven properties rather than manual ones.

A note on custom objects

If you rely heavily on Salesforce custom objects, remember that HubSpot custom objects require an Enterprise subscription. On Professional, you may need to model that data as additional properties, activities, or a connected app. Decide this before you commit to a tier.

Phase 3: Clean, dedupe, and prepare the data

Migrate clean data, not your historical mess. This is the highest-value phase and the one most teams under-resource.

1. Deduplicate accounts, contacts, and opportunities in Salesforce or in your export files.
2. Standardise formats: phone numbers, country names, job titles, picklist values.
3. Fill or remove critical empty fields that your processes depend on.
4. Decide your history strategy: which activities, emails, and notes come across, and how far back.
5. Export in batches by object, keeping the Salesforce record ID as a reference for re-linking.
6. Validate exports against your mapping before any import.

History is where migrations balloon in cost. Be deliberate: full activity history for the last two years is often plenty, and dragging across a decade of logged calls rarely earns its keep.

Phase 4: Rebuild in HubSpot

Now you construct the destination, then load the data into it.

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 Salesforce automation blindly. Use the move to simplify. Recreate lead routing, deal stage automation, internal notifications, and handovers in HubSpot workflows. This is the right moment to retire the rules nobody remembers creating. Thoughtful automation here saves hours every week once you are live.

Rebuild reports, dashboards, and integrations

1. Rebuild only the reports and dashboards people actually use.
2. Recreate or replace integrations, prioritising the ones the business depends on daily.
3. Test each integration in isolation before connecting it to live data.

Import the data

Import in a sensible order so relationships resolve: companies first, then contacts, then deals, then activities. Use the stored Salesforce record IDs to associate records correctly.

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

Resist the urge to flip the switch the moment data is in.

1. Validate. Spot-check record counts, associations, owners, and key fields against Salesforce. Confirm automation fires as expected on test records.
2. Test with real users. Have a few people work real (or realistic) scenarios end to end and log every issue.
3. Run in parallel. Keep Salesforce read-only for an agreed window while the team works in HubSpot, so you have a safety net.
4. Cut over. Once you are confident, make HubSpot the system of record, communicate the switch clearly, and set Salesforce to read-only or archive it.
5. Post-migration care. Plan a fortnight of close support, fix issues quickly, deliver training, and capture the small fixes that always surface once real usage begins.

What to watch out for

A few traps I see repeatedly:

• Lead object surprises. HubSpot has no Lead object. Leads become contacts with a lifecycle stage, which often improves the model but can confuse a Salesforce-trained team.
• Over-migrating. Bringing across every field, report, and rule recreates the clutter you wanted to escape.
• Custom object assumptions. Confirm your tier supports what you need before you design around it.
• Underestimating history and activities. This is where volume, and therefore time, hides.
• No parallel run. Switching off Salesforce with no fallback is a needless risk.

Make the move with confidence

A Salesforce to HubSpot migration is genuinely an 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, and test before you commit.

If you would rather not navigate this alone, migration is a core part of what I do. Get in touch and we can map out your move.