How to Merge Two HubSpot Portals After an Acquisition (Without Losing Data)

Merging two HubSpot portals is a migration, not a merge. HubSpot has no native button that combines two portals into one, so you move one portal's contacts, companies, deals, content and automation into the other, then reconcile every conflict by hand. Done properly it is a phased project: audit both portals, map the data, prove it in a controlled environment, validate, then cut over. The biggestes risks are losing data, duplicating or overwriting it.

If your company has just acquired another, and both of you run on HubSpot, congratulations: you now have two of everything. Two contact databases, two sets of custom properties, two lifecycle definitions, two libraries of workflows, and almost certainly two versions of the same customers. Bringing those together looks like an export and an import. It is not.

Here is what actually happens, why it is riskier than it looks, and how a merge is done safely.

Can you merge two HubSpot portals natively?

No. There is no supported one-click way to combine two HubSpot portals. HubSpot's own guidance is to migrate assets and records from one portal into the other. That means one portal becomes the target, or "surviving", portal, and everything of value from the other is rebuilt or imported into it.

That single fact changes everything. A merge is not a technical event that happens on a Saturday night. It is a reconciliation project, because two portals that grew up separately almost never agree on how data should look.

Why is merging portals harder than a normal import?

A standard import moves clean data into an empty or well-understood field. A portal merge moves messy, opinionated data into a portal that already has its own messy, opinionated data. The two disagree, and every disagreement is a decision.

Which lifecycle stage wins when the same person is a customer in one portal and a lead in the other? Which portal's definition of "MQL" survives? What happens to a custom field that exists in one portal and not the other? What happens to someone who unsubscribed in one system but not the other?

Get these decisions wrong and you do not get an error message. You get bad data that looks fine until it costs you a deal, a report, or a compliance headache.

Who actually makes these decisions?

Here is the part most merge pitches skip. Your migration partner does not decide which lifecycle definition wins, which consent basis applies, or whose data is the source of truth. The acquiring business does.

That is not us dodging responsibility. It is the opposite. A partner like us surfaces every conflict, lays out the options, spells out the consequence of each one, builds the mapping and executes it without breaking anything. But the calls themselves are commercial, legal and operational. Which brand's "MQL" definition survives shapes how your sales team is measured. Which consent basis you rely on is a legal position your business has to own. Which records win decides who your reps call on Monday. Nobody outside your business can make those choices for you, and you would not want them to.

So a good merge is a partnership with a clear split. We own the mechanics and the safety. You own the decisions only the business can own. When that line is clear from day one, the merge is faster, cleaner and far easier to stand behind afterwards.

The five places data quietly duplicates or disappears

In practice, almost every merge risk falls into one of five buckets. This is where teams lose data without realising it.

1. Duplicate contacts, companies and deals. The same buyer often exists in both portals, especially if the two companies ever shared a market. Import naively and you split each person's history across near-duplicate profiles, especially where the same buyer appears under a different email. Companies and deals are worse: they do not dedupe as cleanly as contacts, so they multiply quietly and are far harder to unpick later. Every report built on counts and conversion rates is quietly corrupted in the process.
2. Custom properties with nowhere to land. If a field exists in the source portal but has no matching property in the target, that data does not throw an error on import. It simply does not arrive. Years of custom scoring, segmentation and sales notes can evaporate silently because nobody mapped the fields first.
3. Lifecycle and attribution overwrites. Original source and first-touch attribution rarely survive a naive import. HubSpot sets the source of imported records to "Import", so unless you deliberately preserve the original values in dedicated properties first, the real acquisition story is gone and cannot be recovered. The same applies to lifecycle stage: a careless merge can promote or demote thousands of contacts in one move.
4. Consent and subscription conflicts. If opt-out and subscription status does not carry across cleanly, you risk emailing people who explicitly unsubscribed. That is a GDPR problem, a deliverability problem, and a trust problem, all at once, and it tends to surface only after the first send.
5. Missing or misfiring automation. Workflows that never made the move stop running silently, so lead routing, nurturing and internal alerts just quietly stop. Worse, workflows that do move can re-enrol your entire imported database and fire a mass email the moment they activate. We have seen merges blast thousands of contacts this way. It is one of the first things a careful migration protects against.

What does a safe portal merge actually look like?

The teams that come through a merge cleanly treat it as a phased project rather than a single cutover event. Broadly, it runs like this.

First, audit both portals. Inventory contacts, companies, deals, properties, workflows, forms, lists and content, and note where the two disagree. Second, map the data, deciding field by field which values survive, how duplicates are matched, and which lifecycle and consent rules win. Third, prove it in a controlled environment. Use a sandbox to test structure and automation, and validate the data against controlled test batches, so nothing hits live records or triggers a live send until the behaviour is proven. Fourth, validate against a test pack, checking record counts, property values, consent status and automation behaviour before anything goes live. Only then do you gate and cut over, migrating in controlled stages with a clear rollback position.

None of this is glamorous. All of it is the difference between a merge your revenue team never notices and one they are still cleaning up six months later.

How long does a HubSpot portal merge take?

The timeline hinges mostly on complexity, although an extremely large or disorganized database can introduce its own delays. A straightforward portal with minimal custom fields and basic automation may migrate within a few weeks. In most cases, our projects run about one to three months, based on how fast your team replies and how accessible the source company’s details are. The audit is what clarifies which situation applies, which is precisely why it happens first.