Preparing for HubSpot's Salesforce Integration v2

The HubSpot-Salesforce integration is one of HubSpot’s most widely used, with nearly 11,000 companies actively using it every day. Given how popular it is, you may be surprised to learn that its core architecture hasn’t had a real overhaul since 2014.

Twelve years is a long time to leave the foundation of something that critical untouched, and RevOps teams have felt it. This is the integration known for duplicate records, for owner assignments that drift out of sync after a reorg, and for silent errors nobody catches until a rep asks where their deal went. Most teams have built workarounds into their systems to deal with at least one of its shortcomings.

That era is ending. HubSpot is rebuilding the integration from the ground up, and that will change how you use it moving forward.

HubSpot is taking a phased approach to the rollout, with the full release landing in 2027. That gives RevOps teams time to plan how they want to handle the transition. Before you change anything, it helps to understand what’s actually changing, why the old integration caused the problems it did, what the new one fixes, and how it might push your current setup to evolve.

What's changing

In a community post titled “Rebuilding the Engine,” HubSpot laid out its plan: a near-complete refactor of the backend that processes data flowing between the two systems. The sync engine and the logic underneath it are being rebuilt. HubSpot calls the effort the “v2” project.

Instead of shipping everything at once, HubSpot is going object by object. Custom objects, tickets, and activities are already running on v2 for everyone. Company sync launched recently as a self-service upgrade. Deal sync is next. Contact sync, the big one, is targeted for a beta in Q4 2026, with the old engine slated for full retirement by mid-2027.

Alongside the object rollout, HubSpot has already shipped several of v2’s new capabilities: association-label sync earlier in 2026, expanded inclusion lists in the spring, and, most recently, selective Salesforce-side sync.

Where the old integration broke down

Before we get into what’s coming in v2, it’s worth revisiting where the original integration fell short. This isn’t an exhaustive list. These are the limitations teams have run into most, and each one is something they’ve spent years working around.

• It shared Salesforce’s API budget and burned through it fast. The integration drew on the same daily Salesforce API allocation as every other connected tool, and a single record sync could eat several API calls. A bulk change in Salesforce, like reassigning owners across tens of thousands of records, could trigger a full resync that drained the day’s allocation, backed up the sync queue for hours, and in some cases suspended the integration entirely until the limit reset. The failure was usually silent until someone went looking for a record that never arrived.
• Deduplication only worked on email. The legacy integration could only match records by email address, which holds up until you hit shared inboxes, people who change jobs, or the fact that Salesforce treats Leads and Contacts as separate records. To fill the gap, most teams bought a third-party dedupe tool or wrote their own scripts.
• There was no native owner sync. The integration had no built-in way to keep record ownership aligned between the two systems. Reassign a territory or move a rep, and the two sides could quietly disagree about who owned what, with no error to flag the drift. Teams patched it with custom middleware that tended to break the next time the org chart changed.
• Field-level control was ambiguous. When both systems can edit the same field, something has to decide which value wins, and the native integration left that unclear. Without carefully hand-built ownership rules, fields would toggle back and forth on every sync cycle. Nothing errored out. The data just quietly disagreed with itself.
• Picklist values caused sync errors. Because HubSpot stores many dropdowns as open text on the backend, a value that was valid in one system could be rejected by the other. Every time you refined a lead source or added a deal stage, you risked a fresh batch of sync errors on records that no longer matched cleanly on both sides.
• Lead-to-Contact conversion caused problems. Salesforce keeps Leads and Contacts as separate objects, while HubSpot treated them as one. Reconciling the two at conversion was one of the integration’s weakest points, and HubSpot has acknowledged this logic caused a meaningful share of sync errors. It’s where records tended to get stuck or drop out of reporting.
• When it broke, it was hard to debug. The legacy integration ran on layers of tangled logic that were difficult to trace, so diagnosing a single sync error often meant opening a support ticket and waiting. HubSpot has been unusually candid here, acknowledging the old architecture was hard to debug even internally. The teams who spent years fighting this integration weren’t imagining things.

None of this is news to anyone who’s lived with the integration. What matters now is that every one of these limitations produced a workaround (a dedupe tool, an owner-sync script, a set of hand-maintained mapping rules), and those workarounds are now technical debt you finally get to reassess. Nearly every shortcoming on this list is also something v2 sets out to fix.

What v2 unlocks, and what it doesn't

The new architecture brings capabilities teams have asked for for years. Deduplication can now run on fields beyond email, matching on something like a company domain or a unique ID instead of hoping every record has a clean email address. Owner fields can sync natively. Those two changes alone retire a whole category of custom scripts and middleware teams built just to keep records matched and ownership aligned.

Control over what syncs has also expanded considerably. Inclusion lists now cover companies, tickets, and custom objects, not just contacts. Selective sync lets you filter from the Salesforce side, controlling which Salesforce records come into HubSpot at all. Association-label sync lets you choose which labeled relationships (a primary contact, a decision maker, a billing contact) carry across.

That last one still has limits. As of early 2026, only a contact’s primary company association syncs, so many-to-many account structures aren’t fully represented yet. And for companies specifically, you can finally merge records and have that merge carry over to the other system, something the old platform couldn’t do.

Here’s the catch. v2 will be a better integration, but it runs on whatever sync logic, field mappings, and data you already have. It removes the platform’s excuse for poor sync hygiene without doing the hygiene for you. If your mappings are muddled and your data is dirty, a faster, more capable engine will just produce bad results more efficiently. The upgrade is an opportunity to fix the underlying decisions, not a substitute for making them.

Sequence Matters

The single most useful thing about this rollout is the sequence. HubSpot is rolling v2 out one object at a time, and you should adopt it the same way. This is where teams either set themselves up well or create months of cleanup.

Start by establishing a clean baseline before you change anything. You can’t tell whether v2 improved your sync if you never documented how it worked to begin with.

Then move to company sync, since it’s the object currently available to upgrade. Test in a sandbox before moving it into production. Validate that merges flow correctly between systems and that your field mappings, especially custom ones, behave the way you expect. Companies are a lower-stakes place to learn how the new platform behaves before you get to deals or contacts.

Treat the new company-merge capability as the trigger for a cleanup you couldn’t safely do before. Plenty of portals carry years of duplicate company records that piled up precisely because merging used to break the Salesforce sync. That constraint is gone, so the cleanup is finally on the table.

When deal sync becomes available, don’t rush it. Deals carry higher stakes than companies because your pipeline and revenue data are on the line. Test thoroughly in a separate environment, validate your mappings and pipeline logic, and only push it live once you’ve confirmed it behaves as expected.

Leave contacts for last. They’re the most complex object by a wide margin, with the highest volume, the most field associations, and the most entanglement with lifecycle stages, marketing status, and Lead-to-Contact conversion. That complexity is exactly why HubSpot is rebuilding contacts last, and why they deserve the most preparation on your end.

How to prepare 

The rollout runs on HubSpot’s clock, but the prep work is entirely within your control, and most of it is worth doing regardless of when each object migrates. Some teams will run this themselves. Others will bring in help to move faster or handle the trickier pieces. Either way, the work is the same.

Run a sync-error and field-mapping audit
Document what’s syncing, what’s breaking, and which direction data flows. This is your baseline and your test plan in one.

Inventory your custom workarounds
Every dedupe script, owner-sync workflow, inclusion-list hack, and middleware connection you built to get around a v1 limitation is now a retirement candidate. List them all so you can evaluate each one as its object moves to v2. Several may no longer need to exist.

Define your sync direction and conflict rules deliberately
For each important field, decide which system wins when both have a value, and what should be one-way versus two-way. Lead score flowing one way from HubSpot while contact details sync both ways: that kind of intentional rule-setting is what separates a clean sync from a constant source of overwrites.

Standardize your picklist and dropdown values before they migrate
Inconsistent values are a common cause of the sync errors v1 was known for. Cleaning them up now keeps them from carrying over into the new platform.

Decide how you'll control what syncs
The dedicated Salesforce integration user has long been the standard way to govern what flows between systems, and it still has real value for permissions, security, and a clean audit trail. Selective sync now offers another way to control Salesforce-side flow directly. The two solve overlapping but distinct problems, so the right move is deciding which combination fits your setup, not assuming the integration user is obsolete.

Review your association labels
Now that you can choose which labeled relationships sync, confirm which ones actually should, so the relationships that matter for reporting and routing stay accurate across both systems.

None of this requires the migration to have reached your most important objects yet. It’s the groundwork that makes every later step safer.

The bottom line

The teams that come out of this ahead won’t be the ones who rushed the upgrade. They’ll be the ones who used the runway to fix what the old integration let them get away with: the duplicate data, the muddled mappings, the workarounds nobody fully remembers. v2 gives you a better engine. What it runs on is still up to you.

Need help preparing your integration for v2? Contact the Pros.