How to Plan a Salesforce to HubSpot Migration Without Losing Data

Data loss during a Salesforce to HubSpot migration isn't inevitable. It happens because someone skipped the boring planning phase and jumped straight into moving records. We've managed dozens of these migrations over 22 years, and the pattern is always the same: the companies that lose data are the ones that didn't inventory, map, and validate before touching the export button.

If you've already read our take on the things nobody tells you before migrating from Salesforce, this is the tactical companion. The actual planning checklist.

Phase 1: Inventory Everything

Before you migrate anything, you need to know exactly what you have. This is tedious. Do it anyway.

Objects: Contacts, Accounts, Opportunities, Cases, Leads (yes, Leads — HubSpot doesn't have a separate Lead object, so you need to plan for that). Custom objects. Don't forget Activities, Tasks, and Notes.

Record counts: How many of each? This is your baseline for validation later. If Salesforce has 47,000 Contacts, HubSpot should have roughly 47,000 after import (minus whatever you intentionally exclude).

Fields: Export the field list for every object. Salesforce portals with 5+ years of history commonly have 200-400 custom fields. Half of them are unused. You need to know which ones matter.

Relationships: Account-Contact associations. Opportunity Contact Roles. Parent-child accounts. Activity associations. This is where most migrations break, because HubSpot models relationships differently than Salesforce.

Integrations: What connects to Salesforce today? Each integration needs a HubSpot equivalent or a plan to retire it.

Phase 2: Decide What to Migrate

Not everything should come over. This is the hard conversation most teams avoid.

Definitely migrate: Active contacts and companies. Open opportunities. Current cases. Recent activity history (12-24 months). Active automation logic.

Maybe migrate: Older activity history (weigh the cost vs. value). Closed-lost deals from 3+ years ago. Archived records.

Leave behind: Duplicate records (clean before you move, not after). Test data. Records from retired business lines. Fields nobody has used in 2+ years.

Document every decision. "We chose not to migrate Opportunities closed before 2022 because..." Someone will ask in 6 months.

Phase 3: Map to HubSpot's Data Model

This is the most technical phase and where experience matters most.

Object mapping: Salesforce Accounts → HubSpot Companies. Salesforce Opportunities → HubSpot Deals. Straightforward so far. But Salesforce Leads? They become Contacts in HubSpot, which means you need to deduplicate against existing Contacts during migration. Cases → Tickets in Service Hub.

Field mapping: Go field by field. Which Salesforce fields map to existing HubSpot properties? Which need new custom properties? Which picklist values need translation? A Salesforce multi-select picklist behaves differently than a HubSpot multi-checkbox.

User mapping: Salesforce User IDs don't exist in HubSpot. Every record owner, activity creator, and task assignee needs to be mapped to a HubSpot user. Miss this and you get orphaned records with no owner.

Phase 4: Clean Before You Move

Moving dirty data into a clean system just gives you a dirty system faster. Deduplicate in Salesforce first. Standardize formats (phone numbers, country names, state abbreviations). Validate email addresses. Archive or delete records you decided not to migrate.

This phase typically cuts 15-30% of records from the migration scope, which makes everything faster and cheaper. More on why this matters in our data hygiene guide.

Phase 5: Execute in Stages

Never migrate everything at once. Here's the order that works:

1. Reference data first: Users, teams, picklist values. These need to exist before records reference them.

2. Companies: They're the parent object. Import them, validate counts and key fields.

3. Contacts: Import, associate with companies, validate.

4. Deals: Import, associate with companies and contacts, validate pipeline stages and amounts.

5. Activities and notes: These depend on all the above existing first.

6. Tickets and remaining objects.

Test each wave with a small subset (100-500 records) before running the full batch. Fix issues on the small batch. Then scale up.

Phase 6: Validate Like Your Job Depends on It

Because it might. Validation is the phase people rush through because they're tired and want to be done.

Record counts: Compare Salesforce export counts to HubSpot import counts for every object. Discrepancies mean something was lost or duplicated.

Field spot-checks: Pull 20-30 random records and compare field values between systems. Check text fields, dates, numbers, and picklists separately. Encoding issues love hiding in text fields.

Associations: Verify that company-contact, contact-deal, and deal-company associations survived. This is the most common failure point.

Activity history: Open 10 records and check that emails, calls, notes, and tasks are attached to the right contacts and deals.

Common Failure Points

Salesforce Lead conversion history: Gets lost if you don't plan for it. The information about which Lead became which Contact/Account/Opportunity doesn't automatically translate.

Attachments: Salesforce stores files differently than HubSpot. Files attached to records, email attachments, and documents each need a separate migration approach. This alone can add a week to the project.

Character encoding: International characters (accents, umlauts, CJK characters) corrupt silently during export/import if your CSV encoding is wrong. Always use UTF-8. Always spot-check records with non-English characters.

Picklist mismatches: A Salesforce picklist with 47 values mapped to a HubSpot dropdown with 30 values means 17 values need to go somewhere. Map every single one.

Planning a Salesforce to HubSpot migration? Check out our migration services or book a discovery call to talk through your situation.