When two companies merge, the CRM conversation tends to happen late. Leadership is focused on financials, organizational structure, and go-to-market alignment. Meanwhile, two separate HubSpot portals continue running independently — accumulating divergent data, conflicting automations, and duplicated subscription costs — until someone finally asks the question: “What are we doing about our CRM?”
This playbook answers that question. It is a structured approach to HubSpot portal consolidation after a merger or acquisition, covering every phase from the initial assessment through post-consolidation stabilization. The methodology applies whether you are merging two portals, three, or five — the principles scale.
The Assessment Phase: Understanding What You Have
Consolidation begins with discovery. You cannot make informed decisions about which portal survives, which data migrates, or which workflows are kept until you understand what exists in each portal.
Portal Inventory
For each portal, document a comprehensive inventory across every dimension.
Subscription and Features
Which Hubs are active (Marketing, Sales, Service, CMS, Operations)? What tier is each? This determines feature parity and migration constraints.
Users and Activity
How many active users? Who logs in daily versus quarterly? Active user count often determines which portal has the strongest adoption and should survive.
Data Volume
Record counts for contacts, companies, deals, tickets, and custom objects. Include both active and archived records to understand the full migration scope.
Assets and Automations
Number of workflows, email templates, sequences, forms, landing pages, blog posts, reports, and dashboards across each portal.
Integration Landscape
Every connected app, API integration, data sync, and webhook. Include native HubSpot integrations and custom-built connections.
Domain Configuration
Which domains are connected? Are email sending domains authenticated? Is HubSpot CMS hosting the company website?
Stakeholder Mapping
Identify every team and individual who depends on each portal. Each stakeholder group has different priorities and concerns — acknowledging these perspectives early prevents conflicts later.
| Stakeholder Group | Primary Concern | Key Assets | Migration Risk |
|---|---|---|---|
| Sales Teams | Deal history and pipeline continuity | Deals, sequences, tasks, meeting links | Lost activity history, broken sequences |
| Marketing Teams | Lead scoring, attribution, campaign data | Workflows, lists, emails, landing pages | Broken automations, lost attribution |
| Customer Success | Ticket history and knowledge base | Tickets, knowledge articles, feedback surveys | Lost service history, broken SLAs |
| Operations | Automation integrity and data quality | Integrations, workflows, custom properties | Broken syncs, duplicate data |
| Executive Leadership | Reporting continuity and cost savings | Dashboards, reports, KPI tracking | Reporting gaps, lost historical data |
| External Partners | Portal access continuity | Agency accounts, consultant access | Lost access, permission confusion |
Technical Debt Assessment
Every portal has technical debt. Broken workflows, unused properties, outdated lists, disconnected integrations, and orphaned content are the norm, not the exception. A consolidation is the ideal moment to audit and rationalize.
For a structured approach to this assessment, see our ultimate HubSpot portal audit checklist. Running this audit on each portal before consolidation planning begins will save significant time and prevent you from migrating problems from one portal into another.
Data Governance Decisions
Data governance is the set of rules that determine how data is structured, who owns it, and what quality standards it must meet in the consolidated portal. These decisions must be made before any data moves.
Property Model Alignment
Each portal will have its own custom properties, naming conventions, and data types. Aligning the property model requires resolving every conflict.
Decide Which Properties Survive
Keep properties that are actively used and serve a business purpose. Retire properties that are unused, redundant, or outdated. This is your opportunity to clean house.
Establish Naming Standards
Create a naming convention for the consolidated portal. Common patterns include [Object]_[Category]_[Name] (e.g., contact_marketing_lead_score) or simpler [Category] - [Name] labels.
Resolve Data Type Conflicts
When the same concept exists as different data types (e.g., "Industry" as a dropdown in one portal and free text in another), the stricter type usually wins. Map conversion rules for existing data.
Define Required vs. Optional
Determine which properties are required for record creation in the consolidated portal. Required fields enforce data quality but can block imports if data is missing.
Lifecycle and Lead Scoring Alignment
If both portals have lifecycle stage definitions and lead scoring models, they are almost certainly different. Aligning these is one of the most strategically important governance decisions because they drive automation, reporting, and sales-marketing handoff.
Adopt One Model
If one organization's lifecycle framework is more mature, adopt it wholesale. Fastest to implement, but requires the other team to adapt completely.
Create a Unified Model
If both models have strengths and weaknesses, build a new model incorporating the best elements of each. Most robust, but most time-consuming to design.
Phased Alignment
Start with a baseline model and refine it over the first 90 days as both teams learn the new system. Pragmatic, but requires commitment to revisiting.
Data Ownership and Retention
Decide how contacts, companies, and deals are assigned (by territory, account, or round-robin). Define who can create, modify, or delete custom properties. Establish workflow ownership and approval processes. Unclear ownership creates governance chaos in the consolidated portal.
For historical data that does not migrate, options include archiving the source portal in read-only mode, exporting to a data warehouse, downloading CSV exports, or planned deletion for data with no ongoing business value.
User and Team Migration
People are the hardest part of any consolidation. Technology changes are disruptive, and teams that feel their tools are being taken away will resist the transition.
User Provisioning Plan
Create a comprehensive user list that maps every user from every portal to the consolidated portal.
| User | Source Portal | Role (Source) | Role (Consolidated) | Team (Consolidated) |
|---|---|---|---|---|
| Jane Smith | Portal A | Sales Admin | Sales Manager | East Coast |
| John Doe | Portal B | Marketing Editor | Marketing Specialist | Global Marketing |
Consolidation is an opportunity to align permissions with actual responsibilities. Users who had admin access in a smaller portal may not need the same level of access in the consolidated environment. Review each role assignment carefully.
Team Structure Design
Geographic Teams
Appropriate for global organizations with regional sales teams. East Coast, West Coast, EMEA, APAC.
Functional Teams
Marketing, Sales, Service, Operations. Clean separation of concerns and tool access.
Hierarchical Teams
Parent teams with child teams for granular visibility controls. Managers see their team's records plus child teams.
Hybrid
A combination of geographic and functional, using HubSpot's nested team feature. Most flexible but most complex to maintain.
Permission Model Alignment
- ✓Super admin access — Limit to a small number of trusted users
- ✓Standard permissions — CRM access, marketing tools, sales tools, service tools, reporting
- ✓Custom permission sets — Create standardized sets for common roles (Sales Rep, Marketing Manager, Service Agent)
- ✓Content partitioning — Define which teams can access which content types, blogs, and landing pages
- ✓Department head review — Document the permission model in a matrix and have each department head approve
Reporting Consolidation
Reporting is often the most politically sensitive aspect of consolidation. Each team has reports and dashboards they rely on, and discovering that their favorite dashboard does not exist in the new portal creates immediate friction.
Report Inventory
Catalog every report and dashboard in each portal. For each, note what it measures, who uses it and how frequently, and whether it can be recreated in the consolidated portal.
Unified Reporting Framework
Build Executive Dashboard
Design KPIs that leadership tracks across the merged organization. This must be ready on day one to maintain executive confidence in the consolidation.
Build Departmental Dashboards
Sales pipeline, marketing performance, service metrics — each department needs its core dashboard from day one to maintain operational continuity.
Build Operational Dashboards
Data quality metrics, workflow performance, and integration health. These give the operations team visibility into consolidation health.
Test with Sample Data
Build high-priority dashboards before go-live and test them with sample data. Reports that rely on migrated data must be validated before the full migration.
Historical Reporting
Activity timestamps, attribution data, and some engagement metrics do not transfer between portals. Take screenshots or PDF exports of key historical reports before decommissioning source portals. Document baseline metrics (MRR, pipeline value, lead volume) at the time of consolidation. Set expectations with leadership that year-over-year comparisons may have a discontinuity at the consolidation date.
Workflow and Automation Reconciliation
Two portals means two sets of automations that evolved independently. Merging them requires more than copying — it requires reconciliation.
Workflow Audit
Run a workflow audit on each portal to categorize every workflow. Our guide to finding and fixing broken automations provides a detailed framework.
| Category | Description | Action |
|---|---|---|
| Active and Essential | Core automations critical to daily operations | Must migrate to consolidated portal |
| Active but Redundant | Both portals have a similar workflow | Keep the better-performing version |
| Active but Obsolete | Runs but no longer serves a business purpose | Retire — do not migrate |
| Inactive | Turned off or paused | Review whether to revive or discard |
Conflict Resolution
When both portals automate the same process differently, you need a decision framework.
Performance Data
If one portal's welcome email sequence has a 45% open rate and the other's has 28%, keep the better performer.
Complexity vs. Simplicity
When performance is similar, prefer the simpler workflow. Complexity increases maintenance cost and error risk.
Strategic Alignment
The workflow that aligns with the merged organization's go-to-market strategy wins, even if currently lower performing.
Dependency Mapping
Before recreating any workflow in the consolidated portal, map all its dependencies: forms, lists, properties, email templates, and other workflows it references. Our workflow dependencies guide covers this process in detail. Migrate dependencies first, then workflows. This prevents the situation where a workflow is created but cannot be activated because a required form or list does not yet exist.
Change Management for Teams
Technical migration is the easier half of consolidation. The harder half is getting people to adopt the new system.
Communication Plan
Announcement (8-10 Weeks Before Go-Live)
Inform all users that consolidation is happening, why it is happening, and the high-level timeline. Transparency prevents rumours and resistance.
Impact Briefings (6-8 Weeks Before)
Department-specific briefings that cover what changes for each team. Sales, marketing, service, and operations each get their own session.
Training Schedule (4-6 Weeks Before)
Publish the training schedule with dates, topics, and enrollment links. Design training around roles, not features.
Weekly Updates (Ongoing)
Short updates covering migration progress, upcoming milestones, and how to provide feedback.
Go-Live Communication (Day Of)
Clear instructions on where to log in, what to expect, and where to get help. Establish a dedicated support channel from day one.
Support Model
Slack or Teams Channel
For real-time questions and issue reporting. Fastest response time for urgent problems during the transition.
Dedicated Email Alias
For non-urgent issues that need tracking. Creates a paper trail for recurring issues that need escalation.
Daily Office Hours
30-minute sessions during the first two weeks after go-live where users can screen-share and get hands-on help.
Issue Tracker
A shared spreadsheet or tool where reported issues are logged, prioritised, and resolved visibly by the consolidation team.
Phased Rollout Approach
A phased rollout reduces risk by migrating in stages rather than all at once.
| Phase | Timeframe | Key Activities | Success Criteria |
|---|---|---|---|
| 1. Foundation | Weeks 1-3 | Property model, pipelines, lifecycle stages, lead scoring, team structure, core dashboards, essential workflows, user accounts | All structural elements built and reviewed |
| 2. Data Migration | Weeks 4-6 | Contacts, companies, deals, tickets — migrate and deduplicate | Data integrity validated via source-to-destination comparison |
| 3. Asset Migration | Weeks 6-8 | Email templates, sequences, forms, remaining workflows, CMS pages, integrations | All assets functional in consolidated portal |
| 4. Testing and Training | Weeks 8-10 | UAT with department reps, training sessions, final data validation, redirect implementation | All departments sign off on readiness |
| 5. Go-Live and Stabilization | Weeks 10-12 | Cut over, source portals to read-only, daily monitoring, daily support, post-consolidation dedup | Stable operations for 2+ weeks |
For CMS pages specifically, see our CMS migration guide. This phased approach is detailed further in our complete HubSpot-to-HubSpot migration guide.
Measuring Consolidation Success
Define success metrics before the consolidation begins so you can objectively evaluate the outcome.
Operational Metrics
- ✓User adoption rate — Percentage of users from both legacy portals actively using the consolidated portal within 30 days
- ✓Support ticket volume — How many consolidation-related issues are reported, and what is the resolution time?
- ✓Workflow error rate — Are migrated workflows executing without errors?
- ✓Integration uptime — Are all reconnected integrations syncing data correctly?
Business and Timeline Metrics
- ✓Reporting continuity — Can leadership generate the same reports they relied on before?
- ✓Pipeline visibility — Do sales managers have complete visibility into the merged pipeline?
- ✓Lead flow — Are marketing-generated leads flowing to the correct teams?
- ✓Subscription cost savings — Net reduction in HubSpot costs after decommissioning redundant portals
- ✓Planned vs. actual timeline — Did consolidation complete within the planned timeframe?
- ✓Scope changes — How many unplanned additions were required during execution?
How Jetstack Supports Post-Merger Consolidation
Jetstack has guided dozens of organizations through post-merger HubSpot consolidation. Our implementation services cover every phase described in this playbook, from the initial portal assessment through post-consolidation stabilization.
Specialized Consolidation Tooling
We bring specialized tooling for property mapping, cross-portal deduplication, workflow dependency analysis, and data validation that significantly reduces the manual effort and risk associated with consolidation projects. For organizations that want an independent assessment before committing, our audit services provide a thorough review of each portal's health, technical debt, and migration readiness.
Ready to start planning your portal consolidation? Contact our team to discuss your situation and timeline.
Frequently Asked Questions
How long does a post-merger HubSpot consolidation typically take?
Most post-merger consolidations take 10 to 14 weeks from planning to stabilization. The primary variables are data volume, workflow complexity, the number of integrations, and the extent of CMS migration. Organizations that conduct a pre-consolidation audit typically save two to three weeks because they enter the planning phase with a clear understanding of each portal’s contents and technical debt.
Should we consolidate HubSpot portals immediately after the acquisition closes?
Not immediately. Wait until the organizational structure has stabilized enough to make informed decisions about team structure, ownership models, and reporting requirements. Most organizations begin consolidation planning 30 to 60 days after close, with execution starting 60 to 90 days after close.
What if the two companies use different CRMs (e.g., one uses HubSpot and the other uses Salesforce)?
This is a CRM migration rather than a portal consolidation, which is a more complex project. It requires platform-specific expertise in both systems. Jetstack supports cross-platform CRM migrations — contact us to discuss your specific scenario.
How do we handle conflicting lifecycle stage definitions?
This is one of the most common governance decisions in post-merger consolidation. The options are: adopt the more mature model, create a new unified model, or implement a phased approach where you start with a baseline and refine over 90 days. The right choice depends on how different the two models are and how much change each team can absorb.
What happens to our HubSpot subscription costs during consolidation?
During the consolidation period, you will be paying for both portals simultaneously. After consolidation, you decommission the secondary portal(s) and realize cost savings. Most HubSpot contracts allow for mid-term cancellation or downgrade of the secondary portal once consolidation is complete. Work with your HubSpot account manager to plan the subscription transition.
Can we keep the old portal active as a read-only archive?
Yes. Many organizations maintain the source portal in a downgraded (free or Starter) state for 6 to 12 months after consolidation as a historical reference. This provides a safety net for accessing activity history, old reports, and other data that did not migrate. Set a calendar reminder to decommission it after the archive period expires.