Merging two HubSpot portals into one is among the most complex operations a RevOps team will face. Unlike a fresh implementation where you build from scratch, a portal merge requires reconciling two complete systems — each with its own data model, automation logic, and user workflows — into a single, coherent environment.
This guide provides a structured methodology for portal merges, drawn from dozens of consolidation projects. Whether you are merging portals after a corporate acquisition, consolidating regional instances into a global hub, or simply eliminating a redundant portal that should never have existed, the principles are the same.
When Portal Merges Happen
Portal merges are almost always triggered by an organizational change rather than a technical one.
Post-Acquisition
Company A acquires Company B. Dual portals mean duplicated costs, fragmented reporting, and growing operational complexity.
Regional Consolidation
Decentralized HubSpot adoption leads to separate portals for regions or divisions. Centralization provides unified reporting.
Partner Consolidation
Multiple HubSpot partner relationships create scattered portals. Bringing everything under one roof is a governance initiative.
Cost Rationalization
Two Enterprise portals cost twice as much as one. Consolidation is a high-impact cost reduction move.
Post-Acquisition Consolidation
The most common scenario. Company A acquires Company B, and both have active HubSpot portals. Maintaining two portals means duplicated subscription costs, fragmented reporting, and operational complexity that grows with every passing month. Our post-merger consolidation playbook covers the organizational side of this process.
Regional or Divisional Consolidation
Organizations that adopted HubSpot in a decentralized fashion often end up with separate portals for different regions, business units, or product lines. As the company matures, centralizing on a single portal provides unified reporting and reduces administrative overhead.
Partner Portal Consolidation
Companies that have worked with multiple HubSpot partners may have accumulated portals tied to different partner relationships. Bringing everything under a single, company-owned portal is a common governance initiative.
Cost Rationalization
Two Enterprise portals cost twice as much as one. When budgets tighten, consolidation is one of the highest-impact cost reduction moves available.
Choosing the Primary Portal
The first and most consequential decision in any merge is which portal becomes the primary (surviving) portal and which becomes the secondary (deprecated) portal. This is not always obvious.
Factors That Determine the Primary Portal
| Factor | Favors Portal A | Favors Portal B | Weight |
|---|---|---|---|
| Subscription Tier | Higher tier | Higher tier | High |
| Data Quality | Cleaner, more complete data | Cleaner, more complete data | High |
| Integration Footprint | More active integrations | More active integrations | High |
| Workflow Complexity | More mature automation | More mature automation | Medium |
| User Adoption | More daily active users | More daily active users | Medium |
- Higher subscription tier retained
- Existing integrations stay intact
- Larger user base avoids retraining
- Portal B data migrates into A
- Cleaner data foundation
- Better-configured automation
- Newer HubSpot features available
- Portal A data migrates into B
When Neither Portal Is Ideal
In some cases, both portals have significant issues. Starting with a fresh third portal and migrating the best of both into it can be the right call, though this approach doubles the migration effort. Weigh the long-term benefit of a clean start against the short-term cost.
Starting fresh with a new portal doubles migration effort but eliminates inherited technical debt from both source portals. Only choose this path when both existing portals have significant structural problems that would be costlier to fix than to rebuild.
Data Deduplication Strategy
When two portals merge, duplicate records are inevitable. The same contact may exist in both portals with slightly different data. The deduplication strategy you choose determines the quality of your merged dataset.
Pre-Merge Deduplication
Clean each portal individually. Remove or merge obvious duplicates (same email, same domain) before any data moves.
Cross-Portal Matching
Identify records that exist in both portals using email address, company domain, and deal associations as matching keys.
Conflict Resolution
Define rules for when the same property has different values: most recently updated wins, primary portal wins, or field-level rules.
Post-Merge Cleanup
Run a deduplication pass in the destination portal within the first week to catch duplicates that slipped through.
Pre-Merge Deduplication
Before moving any data, deduplicate within each portal individually. Remove or merge obvious duplicates (same email address, same company domain) so you are working with the cleanest possible dataset on both sides.
HubSpot’s built-in deduplication tool handles basic cases. For large-scale deduplication, consider exporting to a tool like Excel, Google Sheets, or a purpose-built data quality platform where you can apply fuzzy matching rules.
Cross-Portal Matching
Once each portal is internally clean, identify records that exist in both portals. The most reliable matching keys are:
| Matching Key | Object Type | Reliability | Limitations |
|---|---|---|---|
| Email address | Contacts | High | Only works if email is consistent |
| Company domain | Companies | High | Subdomains may cause mismatches |
| Deal name + company | Deals | Medium | Requires manual review |
| Phone number | Contacts | Low | Formatting inconsistencies |
For contacts and companies that match, you need a conflict resolution rule: which portal’s data wins when the same property has different values? Common approaches include:
- Most recently updated wins: Simple and usually correct for fast-moving fields like phone number or job title.
- Primary portal always wins: Appropriate when one portal’s data is known to be more reliable.
- Field-level rules: Different fields follow different rules. For example, lifecycle stage follows the higher value, while email follows the most recently updated.
The best conflict resolution strategies use field-level rules rather than blanket policies. Lifecycle stage should always take the higher value (to avoid downgrading qualified leads), while contact details should favor the most recently updated record.
Post-Merge Deduplication
Even with careful pre-merge deduplication, some duplicates will slip through. Plan for a deduplication pass in the destination portal within the first week after merge. Our CRM data cleanup guide covers the tools and techniques for this.
Property Mapping and Conflict Resolution
Two HubSpot portals will never have identical property schemas. Reconciling them is one of the most detail-intensive parts of a portal merge.
Identifying Overlaps and Gaps
Export the full property list from both portals (Settings > Properties in HubSpot, or via the Properties API). Compare them side by side to identify:
| Category | Description | Action Required |
|---|---|---|
| Identical Properties | Same internal name and type | Direct mapping |
| Semantic Equivalents | Different names, same purpose (e.g., "Lead Source" vs. "Original Source") | Standardize naming |
| Unique Properties | Exists in only one portal | Create in primary portal |
| Type Conflicts | Same concept, different field types (dropdown vs. text) | Data transformation required |
Dropdown and Multi-Select Values
When both portals have the same dropdown property but with different option values, you need to merge the option lists. Watch for:
- Different labels for the same concept (“SaaS” vs. “Software as a Service”)
- Options that exist in one portal but not the other
- Display order differences that affect reporting
Industry Dropdown Mismatch
Portal A uses a dropdown with "SaaS," "FinTech," and "HealthTech." Portal B uses a free-text field for industry. Merging requires converting Portal B's free-text values into Portal A's dropdown options, which means mapping hundreds of unique text entries to a standardized list. Plan for manual data cleaning.
Handling Custom Properties at Scale
Enterprise portals often have hundreds of custom properties, many of which are unused or redundant. A merge is the ideal time to rationalize. Audit property usage (how many records have values, when they were last updated) and retire properties that no longer serve a purpose. This is a core element of a pre-migration audit.
Workflow Reconciliation
Merging workflows from two portals is rarely a matter of simply copying them all into one place. Workflows from different portals often overlap, conflict, or depend on assets that do not yet exist in the primary portal.
Cataloging and Categorizing
Export a complete list of workflows from both portals. Categorize each one:
Duplicate
Both portals have a workflow that does essentially the same thing (e.g., a welcome email sequence). Keep the better-performing version.
Unique
A workflow exists in only one portal. Migrate it if still needed and its dependencies can be resolved.
Conflicting
Both portals automate the same trigger but with different actions. Requires manual resolution and stakeholder input.
Obsolete
Workflows that are broken, turned off, or no longer relevant. Do not migrate these — the merge is the ideal time to retire them.
When two workflows automate the same trigger with different actions, do not simply pick one. Involve the stakeholders who use each workflow to understand the business logic before deciding which to keep, merge, or redesign.
Dependency Mapping
Each workflow depends on forms, lists, properties, email templates, and sometimes other workflows. Before recreating a workflow in the primary portal, ensure all its dependencies exist. Our workflow dependencies guide covers this process in depth.
Rebuild Order
Migrate workflows in dependency order:
Create Properties
Create all required custom properties in the primary portal with matching internal names and field types.
Recreate Forms and Lists
Build forms with correct field mappings and lists with equivalent filter criteria.
Rebuild Email Templates
Migrate design assets, recreate templates, and validate personalization tokens.
Recreate Independent Workflows
Build workflows that have no dependencies on other workflows first.
Recreate Chained Workflows
Build workflows that depend on other workflows last, ensuring the full chain is intact.
For step-by-step guidance on moving workflows between portals, see our workflow migration checklist.
User and Team Migration
People are the most overlooked element of a portal merge. The team from the secondary portal needs to be onboarded to the primary portal with appropriate access.
User Provisioning
Create user accounts in the primary portal for all active users from the secondary portal. Map their roles and permissions to the primary portal’s permission model. If the two portals used different team structures, this is an opportunity to align on a unified structure.
Portal merges are the ideal time to standardize roles and permissions. Rather than replicating both portals' permission models, design a unified structure that serves the combined organization.
Ownership Reassignment
Contacts, companies, and deals in the secondary portal have owner assignments tied to users in that portal. When records are imported into the primary portal, update owner fields to reference the correct users. This requires an owner mapping table.
| Source Portal User | Primary Portal User | Records to Reassign |
|---|---|---|
| rep-a@acquired.com | rep-a@parent.com | Contacts, Deals |
| mgr-b@acquired.com | mgr-b@parent.com | Companies, Tickets |
| admin@acquired.com | admin@parent.com | All object types |
Training and Change Management
Users accustomed to the secondary portal’s layout, saved views, and workflows will need training on the primary portal. Do not underestimate the productivity dip during the transition period. Provide documentation, office hours, and a support channel for migration-related questions.
Timeline Planning for Portal Merges
Portal merges are multi-week endeavors. Trying to compress the timeline invites errors.
Typical Phase Durations
| Phase | Duration | Can Run In Parallel? |
|---|---|---|
| Discovery and audit | 1-2 weeks | Starting point |
| Property mapping and schema alignment | 1-2 weeks | Yes (with discovery) |
| Data deduplication and cleanup | 1-2 weeks | Yes (with property mapping) |
| Data migration | 1-2 weeks | After dedup complete |
| Workflow and asset migration | 2-3 weeks | After data migration |
| Testing and validation | 1-2 weeks | After asset migration |
| Go-live and monitoring | 1 week | Final phase |
Total timeline: 8 to 14 weeks for a typical mid-market merge. Enterprise merges with custom objects, complex integrations, and CMS pages can take 16 weeks or more.
Property mapping and data deduplication can happen simultaneously. Workflow cataloging can begin during the discovery phase. Identify these parallelization opportunities to compress the timeline without increasing risk.
Jetstack’s Portal Merge Methodology
At Jetstack, we have refined a portal merge methodology through dozens of engagements. Our approach includes:
Automated Property Comparison
Generates a complete mapping document in hours rather than days, catching type conflicts and semantic equivalents automatically.
Deduplication Tooling
Cross-portal matching with configurable conflict resolution rules. Handles email, domain, and fuzzy name matching at scale.
Workflow Dependency Analysis
Maps every asset reference before migration begins, ensuring no workflow is recreated before its dependencies are in place.
Validation Framework
Compares source and destination record counts, property values, and association integrity to verify migration completeness.
Our implementation services cover the full merge lifecycle, and our audit services can assess your portals before the merge begins. If you are facing a portal consolidation, reach out to our team to discuss your timeline and requirements.
Frequently Asked Questions
How much does it cost to merge two HubSpot portals?
Cost varies widely based on data volume, workflow complexity, and the number of integrations involved. A simple merge with clean data and minimal automation might take 40-60 hours of professional services time. Complex enterprise merges with custom objects and dozens of integrations can require 200+ hours. The primary cost driver is the quality of the source data — cleaner data means faster migration.
Can I merge HubSpot portals on different subscription tiers?
Yes, but the destination portal’s tier determines which features are available after the merge. If you are merging an Enterprise portal into a Professional portal, you will lose access to Enterprise-only features like custom objects, calculated properties, and advanced permissions. Plan the merge direction accordingly.
What data do I lose when merging HubSpot portals?
The most common data losses during portal merges are activity history (emails, calls, notes), workflow execution logs, form submission history, and analytics data. Our guide on what you lose in a HubSpot data migration covers this topic comprehensively.
How do I handle contacts that exist in both portals?
Cross-portal deduplication is essential. Match contacts using email address as the primary key. For matched records, apply conflict resolution rules to determine which portal’s property values take precedence. Most teams use a “most recently updated wins” approach for regularly changing fields and a “primary portal wins” approach for stable fields like lifecycle stage.
Should I merge portals before or after onboarding the acquired team to HubSpot?
Onboard users to the primary portal as early as possible, even before the merge is complete. This gives them time to learn the new environment while their old portal is still accessible for reference. Running both portals in parallel during the transition period adds subscription cost but significantly reduces disruption.
Can Jetstack help with our portal merge?
Absolutely. Portal merges are one of our core service offerings. We handle everything from the initial audit and property mapping through data migration, workflow rebuilding, and post-merge validation. Visit our implementations page or contact us to get started.