-2.png)
-2.png)
.png)
.webp)
.png)
.png)
-1.webp)
-1.webp)
.webp)
-1-1.webp)
-2.webp)
-1-1.webp)
-2-1.png)
-1-1.webp)
-1-1.webp)
-1-1.png)
Extraction
Pulled every object, record, property and activity from the three source portals into local storage.
Three portals, one destinationThree HubSpot portals into one, without losing anything
An e-commerce company was running three separate HubSpot portals and wanted one, split into three business units. Every record, property, activity and attachment had to arrive intact, and one portal had to be split in two on the value of a single contact property. HubXpert built a custom Node.js migration application to do it.
3 to 1
Portals consolidated
600,000
Activities migrated
23,000
Records migrated
327
Custom properties recreated
ABOUT THE CLIENT
One Company, Three Portals, Three Histories
The client is an e-commerce company of around one hundred people. Over time it had ended up operating three separate HubSpot portals, each with its own records, its own property schema and its own accumulated history of activity.
Three portals means three versions of the truth. Reporting cannot be consolidated, a contact can exist in more than one place, and every team works from a partial view. The company wanted a single portal, organized into three business units, so the separation that mattered was preserved while the data underneath it became one database.
The difficulty was not the decision. It was that a consolidation like this is only worth doing if nothing is lost. Records, custom properties, associations between objects, activity history and attachments all had to arrive, and one of the three portals had to be split across two business units based on the value of a single contact property.
What You Will Learn
- 1 What has to be rebuilt in a destination portal before any record can be moved
- 2 Why associations and activities are the hard part of a CRM migration
- 3 How to route records into different business units during a migration
THE CHALLENGES
A Migration Is Only as Good as What Survives It
Moving contacts between HubSpot portals is not difficult. Moving a working CRM is, because the value is not in the records themselves but in the properties that describe them, the associations between them and the history attached to them.
-
1
Three portals with three different schemas.
Each portal had its own properties, and 327 custom properties existed across them. Every one had to be recreated in the destination, with its options intact, before a single record could land correctly.
-
2
Activity history is the largest and most fragile part.
Six hundred thousand activities carry the actual relationship: the calls, emails, notes and meetings. They are the hardest to move and the most obviously missing if they do not arrive.
-
3
Associations break silently.
A contact without its company, or a deal without its contacts, imports successfully and is still wrong. Associations have to be rebuilt after the records exist, which means the migration is a sequence rather than a transfer.
-
4
One portal had to split in two.
Records in one source portal belonged in two different business units depending on the value of a contact property. That routing logic had to be applied during the migration rather than cleaned up afterwards.
-
5
Native tools do not handle this shape.
Standard import tooling moves records. It does not recreate a property schema, route by a business rule into business units, rebuild associations across objects and carry activity history and attachments with it.
WHAT WE BUILT
A Migration Application, Not an Import
HubXpert built a custom Node.js application for the migration. It extracts everything from the source portals to local storage first, segments it against the business unit logic, rebuilds the destination schema, then pushes records, associations and activities in the order that keeps them intact.
-
1
Full extraction before anything is written.
The application pulls every object, record, property and activity from all three source portals and stores them locally. Working from a complete local copy means the migration can be validated and rerun without hammering the source portals.
-
2
Segmentation against business unit logic.
Extracted data is segmented by which business unit it belongs to, including the portal whose records split across two business units on the value of a contact property.
-
3
Destination schema built first.
The application creates every required object, property and property option in the destination portal, all 327 custom properties included, so records land into a schema that already matches them.
-
4
Records pushed per business unit.
Records are written into the business unit the segmentation assigned them to, rather than landing in one pile to be sorted out afterwards.
-
5
Association logic run as its own step.
Once records exist, the application rebuilds the associations between objects so contacts, companies and deals are connected as they were in the source.
-
6
Activities and attachments imported last.
Six hundred thousand activities and their attachments are imported after the records and associations are in place, so each one attaches to a record that already exists and is already connected.
HOW WE GOT THERE
Extract, Segment, Rebuild, Associate
The order is the method. Every step depends on the one before it, and a migration run out of sequence produces records that import cleanly and are quietly wrong.
Segmentation
Segmented the extracted data by destination business unit, including the property-based split of one source portal across two units.
Schema creation
Created all required objects, properties and property options in the destination portal, covering 327 custom properties.
Record migration
Pushed 23,000 records into their assigned business units.
Associations
Ran the association logic to reconnect objects to each other as they were in the source portals.
Activities and attachments
Imported 600,000 activities with their attachments against the migrated records.
THE OUTCOMES
One Portal, Three Business Units, Nothing Lost
The company now runs on a single HubSpot portal organized into three business units. The separation the business needed is preserved at the business unit level, while the database underneath it is one.
3 to 1
Portals consolidated
600,000
Activities migrated
23,000
Records migrated
Three portals became one. Consolidation removed three separate systems of record and the reconciliation work that came with maintaining them.
The property schema arrived intact. All 327 custom properties were recreated in the destination with their options, so records mean the same thing after the move as they did before it.
Relationship history survived. 600,000 activities and their attachments were imported against the correct records, which is what keeps a migrated CRM usable rather than merely populated.
Objects are still connected to each other. Association logic rebuilt the links between contacts, companies and deals rather than leaving correctly imported but isolated records.
Records landed in the right business unit. Including the source portal that split across two units on a contact property value, routed during the migration rather than corrected afterwards.
Before
- Three separate HubSpot portals
- Three property schemas describing the same things differently
- Reporting that could not be consolidated
- History trapped in the portal it was created in
- No way to separate teams without separating databases
After
- One portal with three business units
- 327 custom properties recreated in one schema
- Consolidated reporting across the business
- 600,000 activities carried across with their records
- Business unit separation on a single database
What teams ask before consolidating portals
Frequently asked questions
-
Yes. In this engagement 600,000 activities were imported with their attachments, against records that had already been migrated and associated so each one attached correctly.
-
They are recreated in the destination portal before records are moved, with their options, so records arrive into a schema that already matches them. This migration recreated 327.
-
Yes. Segmentation is applied to the extracted data before anything is written, so records land in the business unit they belong to. One source portal here split across two business units on the value of a contact property.
-
Native import moves records. It does not recreate a property schema, apply routing logic, rebuild associations across objects, and carry activity history and attachments. A consolidation of this shape needs all four.
-
They are rebuilt as a dedicated step after the records exist. Migrating associations at the same time as records produces links pointing at records that have not been created yet.
