A HubSpot portal merge or migration should be handled carefully, taking the time to align processes, review data and document how things should work after the merge has happened.
Some common reasons that companies choose to merge HubSpot portals include:
In any of these circumstances, there can be a temptation to move EVERYTHING, or at least everything that can easily be exported or recreated. One of the biggest mistakes we see companies make is to just export all object data and reimport it without properly reviewing and rethinking the data.
It’s not just object data either, it can also include templates, emails, forms, call to actions, segments (formally lists), call to actions, reports etc.
If you’re wondering why this isn’t the best approach, take a minute to think of everything you currently have set up in HubSpot and then consider the following questions:
Depending on the age of the HubSpot portal, the information and data being used and the Hubs that you have set up, it might well be that you do need all of the above, but the important step here was taking the time to think about it first.
On that note, here are seven serious considerations that should help form your approach to a HubSpot merge or migration of portals:
Take the time to think about how the teams currently use HubSpot. If you’re merging one portal into another established portal, map out how users are doing things and whether they align.
Are imports done in the same way? Does the data structure match up between portals? What tools and features are being used by each team? What automations need to be taken into account?
If processes aren’t agreed upfront, before anything is merged, it will take weeks, or even months to unpick how people work, and agreeing the best processes retrospectively can be tricky to do.
Example: When two companies using HubSpot merged into one portal due to acquisition, they quickly learned that how leads and contacts were being tagged was different. One was exclusively using lifecycle stages, while the other was using a combination of lifecycle stages and lead status. As a result, the marketing team was left confused as to which process should be followed, as the two processes were triggering automations and lead handover at different stages.
By rethinking the processes, they agreed on one process moving forward, but had to then review and update thousands of leads that had followed the original processes and rethink the stages they were in and the automations they were receiving. It was a massive time drain that could have been avoided.
Take into consideration all users and the hubs and tools they are using across all portals in discussion. Once this has been done, you can agree and map the processes to be followed in the future and set up the master HubSpot portal so it aligns with the agreed processes.
Review each object being used in each portal, from standard objects like contacts, companies and deals to custom objects that might be in use. Once you’re clear on what this set up looks like, review how the data is structured for each object, in each portal.
Consider the following questions as a starting point:
As part of this approach, make sure all users are consulted to better understand how the data is used. You can then take the steps to set up the master portal so that it includes any custom properties, historic data properties or any other information that is needed in the future.
Example: When a company acquired two additional businesses, both of which were using HubSpot, they decided that historic form submission data was important for how they segment and nurture leads. As a result, they considered using custom properties to map out which forms a contact had submitted. The caveat to this was how they would also record the data of the form submission across multiple forms.
With over 120 forms in use, they decided a better approach was to repurpose the form submission information (form name, date of submission, notes etc.) as a note on the contact record. By importing the data in this way, the form submission information showed the correct activity date on the contact record timeline and could still be utilised in reporting and segmentation.
With more users being added to one master portal, review the users and what they need to be able to access. It might be that everyone should be able to see and edit everything, but more often than not, different users need access to different content and data, especially when the teams still have some separated processes.
Once you have worked out who needs access to what, you can create permission sets and teams to manage the permissions and access.
Example: In the case of one organisation, set up in a group structure, they chose to onboard all of the companies in the group onto one master HubSpot portal. Some companies already used HubSpot, some didn’t, but to ensure that each company only saw the data related to their pipeline or marketing processes, they used permission sets and teams to only allow access to the data each user needed access to.
If you’re using marketing emails and subscriptions in the master HubSpot portal, look into whether your licence type allows for different email subscriptions and preferences per company, or whether you’ll need to use the same communication preferences page for all subscriptions.
If it’s the latter, make sure the naming and description of each subscription type is very clear so people can choose which are relevant to them. It will also be important to manage the subscription types on emails being set out and forms that create marketing contacts.
It’s simple, but very important - set a clear naming convention for the brands/companies/teams early on and stick to them - it will make reporting and searching for content a lot easier! Managing content will also be easier and more convenient.
Example: The naming convention for new assets such as emails, website pages, forms, segments etc. can follow a similar structure: [Brand name] content name - for ease, the brand/company/team name could use a shortcode that’s easy for everyone to understand.
Before you merge all of the data and move to one master portal, consider the analytics and reporting you need moving forwards. If you’re moving to one master portal, that already exists and is in use, remember to review the reports, segments and analytics that are already in place and add any additional filtering needed so it’s not impacted by additional data being added to the portal.
Example: When two companies were moving to an existing master portal, it was important to tag current object data to the company already using the master portal and update the already existing reports to filter them to only the existing data.
If using multiple pipelines, contact, company and lead tagging becomes even more important, especially for trying to work out deal sources and the channel that deals have come from.
If you’re merging pipelines, deal tags or naming conventions can help to see exactly which brand the deal is associated with, and also allows for filtering and reports based on this information.
Ultimately, merging HubSpot portals, whatever the starting conditions, comes down to process alignment and properly reviewing all of the data that needs to be migrated. Moving everything to make the migration process easier will potentially create issues later on, so taking the time to get it right first will save time and improve processes further down the road.