Why your Salesforce-HubSpot sync breeds duplicates.

Every team running Salesforce and HubSpot side by side tells me the same thing: the sync works. It does, in the sense that records move. Ask a different question. Ask how many of the records moving are the same record wearing two IDs.

We rebuilt an instance that had run a live two-system sync for years before committing to HubSpot. The same engagement I described in the field bloat piece: 1,532 fields after migration, common fields in four or five lookalike versions. The fields were half the story. The sync had spent those years manufacturing duplicate records the same way it manufactured shadow fields, quietly, and with perfect uptime.

Why does a Salesforce-HubSpot sync create duplicates?

Because the two systems disagree about what makes a record unique, and a sync resolves disagreements by creating rather than deciding. Salesforce keys on its own record IDs. HubSpot leans on email address. Any contact that enters the two systems through different doors, a list import on one side, a form fill on the other, becomes two records with a pipe between them, each convinced it is the original.

From there the mechanics compound. Integration users create instead of match when a lookup misses. One side resurrects records the other side deleted. Field mapping conflicts get settled by spawning a new field, which is how an instance ends up with fourteen ways to say Source. A sync is a replication tool, and it replicates whatever you feed it, including the mess.

How bad does duplication get?

Bad enough to be measurable at industry scale. Plauti’s 2021 analysis of more than 12 billion Salesforce records found 45% of new records entered were duplicates, with API integrations from marketing and sales tools running the worst at an 80% duplicate rate. A two-CRM stack takes whatever baseline you have and gives it a second system to live in.

The freshness picture underneath is better than the internet believes, which is its own tell about this category. Much of the ecosystem still quotes 28% annual email decay. ZeroBounce’s 2026 Email List Decay Report, based on more than 11 billion verified emails, found at least 23% of an email list degrades annually. The improvement went unremarked because nobody updates a slide that still scares people. Scope that one correctly: it measures email list decay, not CRM decay in general. The duplicate figures are the ones a two-CRM stack should lose sleep over. Meanwhile your reps reconcile the overlap by hand, out of a selling week they did not have to spare.

A merge is a business decision in a technical costume

Dedup software can find the lookalikes. It cannot decide which one survives, because survival is a business call: which Source value wins, which rep keeps the account, which activity history the surviving record carries, and which stage the deal sits in when the two systems disagree. Batch-merging on default rules answers all four by coin flip, at scale, permanently.

That is why the vendors in this category sell cadence. Software can run a schedule. It cannot sit in the room where someone who owns the number decides that a Source value wins because comp was already paid against it, or that an owner keeps an account because the alternative left the company. Those sentences never appear in a settings panel.

At the two-CRM client, the sharpest example was Source. Fourteen fields claimed to answer where a record came from, and no default rule could rank them, because the ranking was a judgment about which history the business trusted. We made those calls with their revenue leadership in the room, consolidated what was worth keeping into a single source field, and moved the ongoing story into campaign and event associations. An admin could not have made that decision alone, and neither could we. The people who owned the number had to own the merge.

The order of operations for the surgery

The sequence matters more than the software. First, inventory the match keys both systems use and write down where they disagree. Second, set survivorship rules with the people who own the number, not the admin alone, because the admin cannot know which value comp was paid on. Third, merge in small tranches with the sync’s write path under control, so a merged record does not get unmerged by the next sync cycle. Fourth, re-check routing and reporting after every tranche, because merges move records between owners and segments whether you meant them to or not.

At this client the write path came under control in two stages. The sync moved to one-way first, so a single system held the pen. When the full migration began, we turned the sync off entirely and ran manual daily pushes to keep data fresh until the team was fully on the new CRM. Slower than leaving the pipe open, and worth it: a merge only stays merged when nothing is writing behind you.

None of this requires new software. The systems you already pay for can do all of it. What it requires is decisions, made by people senior enough to make them stick, which is the part no tool has ever shipped.

Count them this week

If you run both systems today, export the count of contacts sharing an email address across them. The number either lets you sleep or starts the project.

Both outcomes are worth an afternoon.