The Data You Will Lose in a HubSpot Portal Migration

Nobody puts this list in the sales deck.

We've now run enough HubSpot-to-HubSpot portal migrations, splitting a business unit into its own instance or sunsetting an acquired brand, to know the question that comes up in week three every single time: "Wait, that doesn't move?" So here is the list up front, from two recent projects, of what a portal migration leaves behind. Some of it can't be helped. All of it can be planned for, and the partner who tells you before you sign is the one who deserves the rest of the project.

Performance history stays in the old portal

Contacts, companies, deals, and assets move. Their history mostly doesn't. Historical conversion data, form submission statistics, email send and open performance, and social media publishing history are tied to the portal they happened in. When one client split a business unit into a fresh portal, the honest answer to "how do we keep three years of conversion reporting?" was: you don't migrate it, you keep the old portal alive in read-only mode as an archive and report from there when you need to. When another client sunset a brand entirely, the email and form performance for that brand was simply gone from the new instance. We tagged every migrated contact with a "previous brand" property so at least the provenance survived. The performance numbers didn't.

The domain trap that breaks a sibling unit

This one is the reason to read the whole post. Sending domains are verified per portal. If your company's primary domain is already verified in a legacy portal, applying new DNS records to connect it to the new portal can break email sending for every other business unit still on the old one. On one project that meant the cutover for a single subdomain had to be scheduled to the hour, with the DNS disconnect and reconnect sequenced so nobody else's nurture emails died mid-send. Check domain verification across all your portals before anyone promises a go-live date. It is the most common surprise and the most avoidable one.

The tooling has prerequisites nobody mentions

HubSpot's asset-copy tooling, which moves templates, workflows, and other assets between portals, requires the multi-account feature to be in place. A trial or newly-provisioned portal may not have it, and you find out when the copy button isn't there. Similarly, the connector that syncs the new portal to Salesforce needs its own dedicated API user, its own permissions review, and its own field mapping pass. None of this is hard. All of it takes calendar time you didn't budget if you assumed "same platform" meant "just copy it over."

To be fair to HubSpot: most of these limits exist for sensible reasons. Analytics are tied to the portal that generated them because that's what makes them trustworthy, and domain verification is strict because it protects deliverability for everyone. The problem isn't the limits. It's that the limits get discovered in the project instead of the proposal.

If you're planning a portal split or a brand consolidation, ask your partner for their version of this list before signing. If they don't have one, that tells you something too.