HubSpot to HubSpot Migration: How to Move Data Between Portals
HubSpot has no way to merge one portal into another, so a HubSpot to HubSpot migration is an export, a rule for which record wins, and an import that rebuilds associations. This guide covers what moves, what does not, and the order to do it in.
Part of the guide: CRM migration guide
Key takeaways
- HubSpot's own help center says there is no way to merge all the data between HubSpot accounts. The route it recommends is to export from one account, then import and recreate data in the other (HubSpot Knowledge Base, checked October 12, 2026).
- A record export carries current property values and associations, but not activities. Calls and notes come out through a separate contact export, activity reports or the engagements API.
- Match records across portals on email for contacts and domain for companies, not on Record ID. Record ID only helps for updating records that already exist in the destination.
- Workflow exports do not include performance data or history, so automations are rebuilt in the destination from the exported list, not copied.
- Decide the survivorship rule first: when the same contact exists in both portals with different values, which portal's value wins, field by field.
Two HubSpot portals, one company. It happens after an acquisition, when a regional team bought its own portal, or when a first portal was set up in a hurry and the business wants a clean second one. The request sounds like a simple merge. HubSpot’s own help center says otherwise: “there is no way to merge all the data between HubSpot accounts” (checked October 12, 2026). A HubSpot to HubSpot migration is a planned export, a conflict rule, and an import.
This page covers what comes out of a portal, what goes into the other one, and the decisions that make or break the result. For the general method that applies to any CRM move, use the CRM migration guide. For moving into HubSpot from a different system, see migrating to HubSpot.
Can you merge two HubSpot portals into one?
No, not as one operation. HubSpot recommends exporting from one account, then importing the objects and recreating other data in the second. That makes the work a migration with a source portal and a destination portal, even when both belong to the same company. Pick the destination first. It is the portal whose properties, pipelines, users and subscription you want to keep.
The choice has consequences. Marketing contact counts, tracking code, forms, landing pages, domains and integrations are all tied to a portal. If the source portal has forms embedded on live pages, the destination needs equivalents before the source is shut down, or submissions quietly go nowhere.
What moves in a HubSpot to HubSpot migration, and what gets rebuilt?
Records move by file. Activities move by a separate route. Automations, templates, forms and settings are recreated. The table is built from HubSpot’s export and import help articles, checked October 12, 2026.
| What you have | How it moves | Catch |
|---|---|---|
| Contacts, companies, deals, tickets, custom objects | Record export, then import | Exports include current property values and associations, not history |
| Associations between records | Included in the export, rebuilt on import through a shared column or a multi-object file | Default export caps each association column at 1,000 IDs; a CSV can include all |
| Association labels | Import | Needs a Professional or Enterprise subscription; an imported label is added alongside any existing label |
| Calls, notes and other activities | Separate: single-contact export, certain activity reports, or the engagements API | Not in the record export |
| Existing emails, meetings, notes, tasks | Cannot be updated by import | Create them again in the destination if you need them |
| Workflows | Exported as a spreadsheet list and images | No performance data or history; rebuild by hand |
| Unsubscribed contacts | Included when you export all contacts | Import them with their status so nobody is re-mailed |
| Forms, pages, domains, integrations | Recreated | Tied to the portal; rebuild before the source is retired |
Which record wins when the same contact is in both portals?
Decide this before touching a file. When two portals have the same person with different job titles, owners or lifecycle stages, an import will silently apply one value over the other unless you choose how. Write the rule per field, not per record.
| Field type | Sensible default | Why |
|---|---|---|
| Email, name | Destination, unless blank | The destination is the system of record going forward |
| Lifecycle stage, lead status | The more advanced stage | Dropping someone from customer back to lead breaks reporting |
| Owner | Destination mapping table, built by hand | Users differ between portals; unmatched owners hide records from reps |
| Marketing opt-out, unsubscribe | Opted out in either portal means opted out | Consent errors are the costly kind |
| Last activity date, create date | Earliest create date, latest activity | Keeps cohort reports honest |
| Custom properties that exist in only one portal | Create the property in the destination first | An import cannot fill a property that does not exist |
This table is a recommendation, not HubSpot documentation. Your own rules may differ, but they should exist in writing before the first import.
How do you match records across portals without creating duplicates?
Use a unique identifier that means the same thing in both portals. HubSpot’s import article names Email as the identifier for contacts and Company domain name for companies, and notes the domain property only accepts values up to the top-level domain. If you include a Record ID column, HubSpot says it supersedes any other unique identifiers in the import. A source portal’s Record IDs will not line up with anything in the destination, so leave that column out unless you are updating records that already exist there.
Two traps are worth naming:
- Secondary emails. HubSpot states that a secondary email will not replace the primary email unless you include the Record ID column. Include both and the secondary replaces the primary.
- Rows without an identifier. In a single-file, multi-object import, a row with no match key creates a new record. Blank domains on company rows are a common source of duplicate companies.
Run a data cleaning pass on the source first. Merging duplicates inside the source is cheaper than finding them in two portals at once.
What is the right order for a HubSpot to HubSpot migration?
- Inventory both portals. Properties, pipelines, lifecycle stages, teams, users, active workflows, forms, integrations. Note which are in use.
- Build the destination schema. Create every property and pipeline stage the incoming data needs. Imports cannot fill what does not exist.
- Write the survivorship rule and the owner mapping. One page, signed off by sales and marketing.
- Export the source. Records first, with associations. Mind the limits: 300 exports per rolling 24 hours, and download links that expire after 30 days.
- Import a sample. One hundred records that include the ugly cases: no company, two companies, secondary email, unsubscribed.
- Check the sample. Counts, associations, owners, opt-out status. Fix the mapping, not the records.
- Import the full set, parents before children: companies and contacts, then deals and tickets, then associations if you use separate files.
- Bring activities across by the route you chose, accepting that they arrive as new activities.
- Rebuild workflows and forms from the inventory and test each with a dummy contact.
- Cut over and keep the source read-only for a set number of weeks before shutting it down.
For the choice between one weekend cutover and a staged move, read CRM migration strategy: big bang or phased.
What breaks most often, and how do you fix it?
| Symptom | Likely cause | Fix |
|---|---|---|
| Contacts imported but not linked to companies | Association column missing or key mismatch | Re-import with a shared column, or use the multi-object file format |
| Duplicate companies after import | Blank or inconsistent domain values | Clean domains in the source; match on domain with no subdomain or path |
| Reps cannot see their records | Owner not mapped to a destination user | Build the owner table before import, create users first |
| Previously unsubscribed people got an email | Opt-out status not imported | Import unsubscribe status with the contact and test with a seed list |
| Dates look wrong in reports | Date format or time zone mismatch in the file | Standardise date format in the file and test one record per pipeline |
| Association labels missing | Subscription tier | Association labels need Professional or Enterprise in the destination |
When should you hire help for a HubSpot to HubSpot migration?
A small portal with a few thousand clean records and no custom objects is a job for a careful admin. Bring in a partner when two portals have overlapping contacts, different property schemas, regulated data, custom objects, many workflows, or when the move has to happen without a gap in lead routing. aibrevo scopes migrations from an export of your actual data, so the quote reflects record counts, associations and automations rather than a guess. Book a 30-minute call or see our HubSpot implementation services.
Sources
All checked October 12, 2026.
- HubSpot Knowledge Base, Export your content and data: no way to merge all data between accounts; workflow export limits; unsubscribes included in a full contact export.
- HubSpot Knowledge Base, Export your records: associations in exports, the 1,000 association cap, export limits, 30-day link expiry, activities exported separately.
- HubSpot Knowledge Base, Import records for multiple objects: unique identifiers, secondary email behaviour, association labels and subscription requirement, activities that cannot be updated by import.