Salesforce to HubSpot Migration: What Actually Goes Wrong

Most Salesforce-to-HubSpot migrations don't fail on the contact and company records. Those move fine. They fail on four things that nobody scoped: activity history, custom objects, automation parity, and one report a director runs monthly that turns out to depend on a field nobody mapped.

Here's the plan we'd run, organized around those four risks rather than around the record types.

Risk 1: activity history

Contacts and companies are the easy part — they're flat, and the field mapping is mostly obvious. History is where the effort actually goes.

Emails, calls, meetings, and notes in Salesforce are related records with their own IDs and relationships. Getting them into HubSpot means mapping each activity to the right contact and the right deal, preserving timestamps and owners. Miss the timestamp and every activity lands with today's date, which destroys any "time to first contact" or engagement-recency reporting you had.

Decide explicitly how far back you're bringing history. Every record ever, or the last two years plus anything attached to an open deal? There's a real cost difference, and "all of it" is often not worth paying for. Write the decision down so it isn't relitigated at go-live.

Risk 2: custom objects

HubSpot supports custom objects on Enterprise tiers. Below that, a Salesforce custom object has no direct home, and you have three options:

1. Flatten it onto an existing object as properties, if the relationship is one-to-one.
2. Model it as a separate object if you're on a tier that allows it.
3. Leave it out and keep that process somewhere else — sometimes a small internal app is genuinely the right answer.

The failure mode is discovering on migration weekend that a core process runs on a custom object nobody mentioned. Inventory these first, before quoting anything.

Risk 3: automation parity

This is the one that surprises people. Salesforce workflow rules, process builders, flows, validation rules, and assignment rules all have HubSpot equivalents — but not one-to-one, and not always at the same tier.

Two specific gaps to check early:

• Validation rules. Salesforce can hard-block a save. HubSpot's equivalents are softer, so a rule you relied on to guarantee data quality may need to become a workflow plus a QA monitor instead of a blocking constraint.
• Complex assignment logic. Round-robin with capacity limits and territory rules often needs a workflow chain, or an external step, rather than one native feature.

Inventory what's running, mark what's actually load-bearing, and expect to retire a third of it. Most CRMs accumulate automations nobody needs — the migration is a good excuse to find out which.

Risk 4: the report nobody mentioned

Ask every team lead which reports they run and what decisions depend on them. Do it before the mapping, not after.

Reports depend on fields, and fields you didn't know were load-bearing don't get mapped. This is where "we migrated successfully" and "the business can still operate" diverge. It costs an hour of interviews and prevents the worst class of post-migration escalation.

The sequence

1. Inventory — objects, fields, custom objects, automations, integrations, reports. This is the deliverable that determines the real timeline.
2. Map and decide — field-by-field mapping, history depth, what gets retired. Written and approved.
3. Clean on the way through. A migration is the one moment when deduplicating and standardizing is nearly free, because you're touching every record anyway. Don't import a mess and plan to fix it later; you won't.
4. Test migration into a sandbox or a portal you can discard. Load a representative slice, then have the actual users try their actual daily tasks.
5. Reconcile with counts. Records in, records out, per object, and an explanation for every discrepancy. "Roughly the same" is not reconciliation.
6. Cutover with Salesforce read-only, not deleted. Keep it accessible for a defined period.
7. Rebuild reports and integrations, then verify against the pre-migration numbers.

Two things worth doing that people skip

Keep the Salesforce IDs. Store the original record ID on every migrated record in a custom property. It costs nothing and makes every future reconciliation question answerable.

Migrate integrations last, deliberately. Anything that writes into the CRM should stay off until the data is verified, otherwise you're debugging a moving target.

Should you migrate at all?

Sometimes not. If the reason is licence cost alone and your process genuinely depends on Salesforce-only capability, the migration will cost more than it saves. If the reason is that nobody uses Salesforce because it was configured for a company you no longer are, the migration is really a process-redesign project with a data-movement task inside it — and it should be scoped that way.

Related: CRM integration for the field-ownership contracts, and HubSpot data cleanup for the deduplication half.

Bring us your object and automation inventory on a discovery call and we'll tell you which of the four risks above is your expensive one.