HubSpot to HubSpot migration.
Two portals, one company. You acquired a company and inherited their HubSpot. There is no merge button. Consolidating two portals is a full migration in both directions at once, and the acquirer usually has the worse data.
Both portals think they own the customer.
Overlapping contact databases, two lifecycle models that mean different things by the same words, two sending domains with different reputations, and two teams each convinced their portal is the good one. Technically this is a migration. Practically it is a negotiation with a data model attached.
No merge button.
Consolidation — the acquisitionThe decisions that set the whole sequence.
Marketing contacts are billed twice
Every contact that exists in both portals is paid for twice until consolidation, and merging naively can push the combined tier up. Deciding who is genuinely a marketing contact usually pays for a meaningful part of the project.
Two lifecycle models
Both teams have an MQL definition and they are not the same. The consolidated portal needs one, agreed by both revenue leaders, before any records move.
Sending domain authentication
Two authenticated sending domains with different reputations. Which survives, and how the other is wound down, decides whether the first consolidated campaign reaches the inbox.
Workflow and property ID collisions
Same property label, different internal name, different meaning. Same workflow name, opposite logic. This is where an unplanned merge corrupts data quietly and irreversibly.
Sequences, templates and ownership
Sales assets belong to individual users. Moving them across portals means recreating them under new owners, and anything personal to a rep who left is simply gone.
Integrations pointed at both
Two sets of forms on two websites, two Zapier accounts, two billing connections. Every integration needs an inventory and a cutover slot, and the website forms are the ones people forget.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
The acquirer assumes their portal wins.
It frequently should not. The smaller company often has the cleaner model, a real lifecycle definition and properties somebody owns. We assess both portals on the data rather than on the org chart, and we have told an acquirer to keep the target portal more than once.
What people ask before they commit.
Can HubSpot merge two portals for us?
No. There is no native portal merge. Consolidation is an export, transform and import project with the same care as a migration from another platform, plus the complication that both sides are live.
How long does it take?
Six to fourteen weeks. The technical work is predictable; the time goes into agreeing one lifecycle model and one set of definitions across two revenue teams.
Will we pay for duplicate marketing contacts in the meantime?
Yes, which is a real argument for not letting the project drift. We usually run a marketing contact rationalisation early so the combined bill is manageable while consolidation runs.
What happens to the acquired company website?
It depends on the brand decision. If it is folding into yours, that is a CMS migration with a redirect map. If it stays, it stays on its own domain and just points at the consolidated portal.
Can we keep both portals running?
For a while, and sometimes indefinitely if the businesses genuinely do not share customers. We will tell you when consolidation is not worth the disruption, because occasionally it is not.
Where people go from here.
Two portals into one.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.