Implementations

The Complete Guide to HubSpot-to-HubSpot Portal Migration

Jetstack Team 17 min read
hubspotmigrationportal migrationdata migrationcrm

There are few CRM projects more consequential than moving an entire HubSpot portal to another HubSpot instance. Whether you are consolidating after an acquisition, moving from a partner-managed account to one you own, or upgrading from a legacy free portal to an Enterprise subscription, a HubSpot-to-HubSpot migration demands meticulous planning, disciplined execution, and thorough validation.

8-12Weeks Average Timeline
270+Assets in a Typical Portal
30%Time Spent on Planning
100%Data Integrity Target

This guide covers the full lifecycle of a portal migration: the reasons teams migrate, the planning frameworks that prevent data loss, the step-by-step process for moving every major object and asset type, and the post-launch checks that ensure nothing falls through the cracks. If you only read one resource before your migration, make it this one.

Why Teams Migrate Between HubSpot Portals

Not every migration starts with a spreadsheet of complaints. Some of the most common triggers are structural rather than technical.

Trigger

Mergers & Acquisitions

Two organizations merge and end up with parallel HubSpot instances. Consolidation eliminates reporting blind spots and duplicated costs.

Trigger

Rebranding

A corporate rebrand tied to a new domain and legal entity requires the old portal's data, automations, and reporting to follow.

Trigger

Tier Upgrade

Moving from a bundled starter portal to a dedicated Enterprise instance requires controlled migration, not a settings change.

Trigger

Agency Handoff

Agencies that build environments for clients need to move every asset cleanly into the client's production portal.

Mergers and Acquisitions

When two organizations merge, they almost always end up with two (or more) HubSpot portals. Maintaining parallel instances creates reporting blind spots, duplicated workflows, and higher subscription costs. Consolidation into a single portal is typically the first RevOps project after the deal closes. We cover the M&A playbook in detail in our guide to portal consolidation after mergers.

A corporate rebrand often comes with a new HubSpot portal tied to the new domain and legal entity. The old portal’s data, automations, and reporting need to follow, even when the branding around them changes completely.

Tier Upgrades or Downgrades

Organizations sometimes outgrow their portal configuration. Moving from a bundled starter portal to a dedicated Enterprise instance — or vice versa during cost rationalization — requires a controlled migration rather than a simple settings change.

Agency-to-Client Handoffs

Agencies that build HubSpot environments for clients often work inside their own portal or a sandbox. At project completion, every asset needs to move into the client’s production portal cleanly.

Sandbox Sunset Preparedness

HubSpot’s legacy sandbox environments are scheduled for sunset in March 2026. Teams still relying on those sandboxes need a migration path to either production or the newer development sandbox type. Our legacy sandbox sunset guide breaks down the timeline and options.

⚠️
Sandbox Sunset Alert

HubSpot legacy sandboxes are being retired in March 2026. If your team is still using one, begin planning your migration path now to avoid disruption.

Planning Your Migration: The Foundation Phase

A migration without a plan is a data loss event waiting to happen. The planning phase typically takes two to four weeks and produces the artifacts every subsequent phase depends on.

1

Stakeholder Alignment

Identify the migration owner, approval chain, and departmental stakeholders across Sales, Marketing, CS, and IT.

2

Portal Audit

Catalog every object, property, workflow, list, form, email template, report, and dashboard. Flag obsolete or redundant assets.

3

Scope Definition

Define explicit include and exclude lists for CRM objects, assets, configurations, and integrations.

4

Timeline & Cutover Strategy

Choose between a "big bang" cutover or a phased migration approach based on risk tolerance.

5

Rollback Plan

Define rollback conditions and preserve the source portal in its pre-migration state for a defined period.

Stakeholder Alignment

Identify the migration owner (usually a RevOps lead or HubSpot admin), the approval chain for go-live, and the departmental stakeholders whose workflows will be affected. Sales, marketing, customer success, and IT all need representation.

Portal Audit

Before moving anything, audit the source portal. Catalog every object, property, workflow, list, form, email template, report, and dashboard. Flag assets that are broken, obsolete, or redundant — migration is the ideal time to clean house. Our ultimate HubSpot portal audit checklist provides a comprehensive framework for this assessment.

Scope Definition

Not everything in the source portal needs to move. Define explicit include and exclude lists for:

  • CRM objects: Contacts, companies, deals, tickets, custom objects
  • Assets: Workflows, sequences, templates, forms, landing pages, blog posts
  • Configurations: Properties, pipelines, deal stages, lifecycle stages, lead scoring
  • Integrations: Connected apps, API keys, webhooks, data sync connections

Timeline and Cutover Strategy

Decide whether you will run a “big bang” cutover (everything moves at once, single weekend of downtime) or a phased migration (data first, assets second, integrations third). Phased approaches are safer but require maintaining two live portals for a transition period.

Big Bang Cutover
  • Everything moves in a single weekend
  • Shorter total timeline
  • Higher risk if issues arise
  • No parallel portal maintenance
Phased Migration
  • Data first, then assets, then integrations
  • Longer total timeline
  • Lower risk per phase
  • Requires maintaining two live portals

Rollback Plan

Define the conditions under which you would roll back and the process for doing so. This means preserving the source portal in its pre-migration state for an agreed-upon period after go-live.

Data Migration: Contacts, Companies, Deals, and Beyond

Data migration is the highest-risk phase. HubSpot’s native tools handle some data types well, but most portal-to-portal migrations require a combination of HubSpot’s import tools, APIs, and third-party middleware.

Data TypeCSV ImportAPI MigrationJetstack
Contact PropertiesFullFullFull
Company PropertiesFullFullFull
Deal RecordsFullFullFull
AssociationsNoFullFull
Activity HistoryNoPartialFull
Stage ProgressionNoPartialFull
Custom ObjectsNoFullFull
Email Engagement DataNoNoArchived

Property Mapping

Before a single record moves, map every source property to its destination equivalent. Pay special attention to:

  • Property types: A single-line text field in the source cannot map to a dropdown in the destination without a value conversion step.
  • Internal names vs. display labels: HubSpot uses internal names for API operations. Display labels can differ, which causes confusion during mapping.
  • Custom properties: These do not exist in the destination portal by default. Create them before importing data.
  • Calculated and rollup properties: These cannot be imported directly. They regenerate based on the underlying data once records are in place.
💡
Property Mapping Tip

Always map using internal names, not display labels. HubSpot's API relies on internal names, and two properties with different internal names but identical labels will cause silent mapping failures.

Contact and Company Migration

Export contacts and companies from the source portal using HubSpot’s native export or the CRM API. Include all standard and custom properties, lifecycle stage, lead status, and owner assignments.

Key considerations:

  • Deduplication: Run deduplication before migration, not after. Merging duplicates in the destination portal is more disruptive than cleaning the source. See our guidance on CRM data cleanup.
  • Associations: Contact-to-company associations must be recreated in the destination. Export the association data separately and import it after both object types are in place.
  • Activity history: Emails, calls, meetings, notes, and tasks associated with contacts do not transfer via CSV import. Use the Engagements API to migrate activity history, or accept that historical activities will only exist in the source portal.

Deal and Pipeline Migration

Deals are the most sensitive data type for most organizations. Migrate pipelines and stages first (as configuration), then import deal records mapped to the correct pipeline and stage.

  • Preserve deal amounts, close dates, and owner assignments.
  • Historical deal stage progression (the audit trail of when a deal moved through stages) requires API-level migration and is often the most technically demanding piece.
  • Pipeline-specific properties need to exist in the destination before deals are imported.
⚠️
Deal Stage History

Deal stage progression history requires the API — CSV imports only capture the current stage. Without API migration, every historical deal will show a single stage entry on the import date.

Ticket and Service Data

If you use HubSpot Service Hub, tickets follow the same pattern as deals: migrate pipelines first, then ticket records. SLA configurations, knowledge base articles, and feedback surveys require manual recreation.

Custom Objects

Custom objects added via HubSpot’s custom objects feature must be recreated in the destination portal (schema, properties, and associations), then populated via the API. There is no CSV import path for custom objects.

Asset Migration: Workflows, Templates, and Forms

Assets are the operational layer of your portal. Unlike data, most assets cannot be exported and imported in a structured format. This is where manual effort — or specialized tooling — becomes essential.

Asset TypeNative ExportManual RecreationJetstack Tooling
WorkflowsNoYesAutomated
Email TemplatesHTML OnlyYesAutomated
SequencesNoYesAutomated
FormsNoYesAutomated
ListsStatic OnlyYesAutomated
Reports & DashboardsNoYesGuided
Landing PagesHTML OnlyYesAutomated

Workflows

HubSpot does not provide a native workflow export or import feature between portals. Each workflow must be recreated manually in the destination portal, or cloned using third-party tools. Our workflow migration checklist covers the full process, and our guide to tools for copying HubSpot assets reviews the options available.

Critical workflow migration considerations:

  • Enrollment triggers: Rebuild triggers using the destination portal’s lists, forms, and properties.
  • Dependencies: Workflows often depend on specific lists, forms, properties, and other workflows. Map these dependencies before starting. Our workflow dependencies guide explains how to untangle them.
  • Branching logic: If/then branches referencing specific property values must use the destination portal’s property options.
  • Internal notifications and task assignments: Update owner references to match destination portal users.
PropertiesListsFormsEmailsWorkflows

Email Templates and Sequences

Email templates can be exported as HTML and recreated in the destination portal’s design manager. Sequences (used by Sales Hub) must be rebuilt manually, including the email steps, task steps, and delays.

For a detailed walkthrough, see our guide on transferring HubSpot email templates and sequences.

Forms

Forms must be recreated in the destination portal. Embedded forms on external websites will need their form IDs and portal IDs updated in the embed code — a step that is frequently overlooked and causes lead capture to silently break.

🚨
External Form Embeds

Every form embedded on an external website must have its portal ID and form ID updated. Missing this step causes lead capture to silently fail with no error messages — leads simply disappear.

Lists

Active and static lists need to be recreated with equivalent filter criteria. Static list membership can be imported via CSV, but active list filters must reference the destination portal’s properties and values.

Reports and Dashboards

Custom reports and dashboards cannot be transferred. Recreate them in the destination portal, using the opportunity to clean up reporting that no longer serves the business.

Testing: The Phase Everyone Wants to Skip

Testing is not optional. Every migration produces surprises, and the goal of testing is to surface them before your sales team discovers them on a Monday morning.

Test Type

Data Validation

Compare record counts between source and destination for every object type. Spot-check individual records.

Test Type

Workflow Testing

Trigger every migrated workflow with a test record. Verify enrollment, branching, emails, and notifications.

Test Type

Form Testing

Submit every form and verify submissions create records, trigger workflows, and deliver notifications correctly.

Test Type

Integration Testing

Reconnect each integration and verify data sync in both directions, especially Salesforce if applicable.

Data Validation

Compare record counts between source and destination for every object type. Spot-check individual records to verify property values, associations, and activity history transferred correctly.

Workflow Testing

Trigger every migrated workflow with a test record. Verify that enrollment criteria, branching logic, email sends, task creation, and internal notifications all function as expected.

Form Testing

Submit every form in the destination portal and verify that submissions create or update records correctly, trigger the appropriate workflows, and deliver notifications.

Integration Testing

Reconnect each integration and verify data sync in both directions. Pay particular attention to Salesforce sync, if applicable, as field mapping and sync rules may need reconfiguration.

User Acceptance Testing

Have representatives from each department perform their typical daily workflows in the destination portal. This surfaces usability issues that automated testing misses.

💡
UAT Best Practice

Create a shared spreadsheet where each department logs their test scenarios and results. This provides an audit trail and ensures nothing is tested in isolation.

Go-Live Checklist

Go-live is a coordinated event, not a checkbox. Use this checklist to ensure nothing is missed.

  • All CRM data imported and validated
  • All workflows rebuilt and tested
  • All forms recreated, embed codes updated on external sites
  • All email templates and sequences rebuilt
  • All integrations reconnected and sync verified
  • All users provisioned with correct roles and permissions
  • All reports and dashboards recreated
  • DNS records updated if migrating CMS or email sending domains
  • 301 redirects configured for any URL changes (see our SEO redirect guide)
  • Source portal set to read-only or deactivated
  • Communication sent to all internal teams with go-live date and support contacts
  • Rollback plan documented and accessible

The go-live checklist is your final gate. No item should be marked complete until it has been independently verified — not just built, but tested in the destination portal with live data.

Post-Migration Validation

The first two weeks after go-live are the validation period. Monitor these areas daily.

1

Data Integrity Monitoring

Run daily comparison reports between source and destination record counts. Watch for contacts or deals that appear to be missing.

2

Workflow Performance

Monitor execution logs for errors, skipped enrollments, and unexpected behavior during the first days of live operation.

3

Lead Flow Verification

Confirm that new form submissions, chatbot conversations, and imported leads are flowing into the correct pipelines.

4

Integration Health

Check each connected integration daily for sync errors, failed API calls, or data mismatches.

5

User Feedback Loop

Create a dedicated Slack channel or email alias for migration issues. Small issues reported early prevent large problems later.

Data Integrity Monitoring

Run daily comparison reports between source and destination record counts. Watch for contacts or deals that appear to be missing — they may have been filtered out by list criteria that differs between portals.

Workflow Performance

Monitor workflow execution logs for errors, skipped enrollments, and unexpected behavior. The first few days of live workflow operation will reveal any dependency or logic issues that testing missed.

Lead Flow Verification

Confirm that new form submissions, chatbot conversations, and imported leads are flowing into the correct pipelines and triggering the correct workflows. A single broken form can mean days of lost leads if not caught quickly.

🚨
Lead Loss Risk

A single broken form can mean days of lost leads if not caught quickly. Verify every lead capture point within the first 24 hours of go-live.

Integration Health

Check each connected integration daily for sync errors, failed API calls, or data mismatches. Pay special attention to bi-directional syncs where conflicts can cascade.

User Feedback Loop

Create a dedicated Slack channel or email alias for migration issues. Encourage teams to report anything that looks wrong, no matter how minor. Small issues reported early prevent large problems later.

Common Pitfalls and How to Avoid Them

Even well-planned migrations encounter obstacles. Here are the issues we see most frequently at Jetstack.

Common Failure

Skipping the Audit

Migrating a messy portal produces a messy destination. Always audit and clean before moving. A pre-migration audit catches broken workflows, orphaned properties, and duplicate records before they contaminate your new portal.

Common Failure

Underestimating Activity History

CSV imports do not include emails, calls, or notes. Budget API development time if activity history matters. Teams who skip this step discover the gap weeks after go-live when reps lose all historical context.

Common Failure

Forgetting Embed Codes

Forms embedded on external websites silently break when portal IDs change. Audit every external page with an embedded HubSpot form and update the embed code to the new portal's IDs.

PitfallImpactPrevention
Skipping the auditMessy destination portalRun a full portal audit before migration
Underestimating activity historyLost sales contextBudget API migration time for engagements
Forgetting embed codesSilent lead capture failureAudit all external pages with HubSpot forms
Ignoring time zonesShifted dates and timestampsAlign portal time zone settings before import
Rushing the cutoverMonday morning panicBuild buffer time into every milestone

How Jetstack Streamlines HubSpot Portal Migrations

Jetstack’s implementation services include dedicated HubSpot portal migration support. Our methodology covers every phase described in this guide, from pre-migration audits through post-launch validation, with tooling that automates property mapping, dependency resolution, and data validation.

50-70%Faster Than Manual
100%Dependency Coverage
0Data Loss Tolerance
24/7Post-Launch Monitoring

If you are planning a HubSpot-to-HubSpot migration and want to reduce risk and timeline, get in touch with our team to discuss your project.

Frequently Asked Questions

How long does a HubSpot-to-HubSpot migration typically take?

A straightforward migration with clean data and fewer than 50 workflows typically takes four to six weeks. Complex migrations involving multiple pipelines, custom objects, extensive integrations, and CMS pages can take eight to twelve weeks. The planning and audit phases account for roughly 30% of the total timeline.

Can I migrate HubSpot activity history (emails, calls, notes) between portals?

Activity history does not transfer via CSV import. You need to use HubSpot’s Engagements API to programmatically recreate activities in the destination portal. This is technically feasible but adds significant development time. Many organizations choose to maintain read-only access to the source portal for historical reference instead.

Will my HubSpot workflows transfer automatically to the new portal?

No. HubSpot does not offer native workflow export or import between portals. Each workflow must be manually recreated or migrated using third-party tooling. This is one of the most labor-intensive parts of any portal migration.

What happens to my SEO rankings when I migrate HubSpot CMS pages?

If URLs change during migration, you must implement 301 redirects from old URLs to new ones to preserve SEO equity. Our SEO redirect migration guide covers the full process. If URLs remain identical, rankings should be unaffected.

Should I clean my data before or after migration?

Always before. Migrating dirty data — duplicates, incomplete records, outdated properties — means you are paying to move garbage and then paying again to clean it in the new portal. A pre-migration audit saves significant time and cost.

Can Jetstack handle my HubSpot-to-HubSpot migration?

Yes. Jetstack provides end-to-end HubSpot portal migration services, including pre-migration audits, data and asset migration, testing, and post-launch support. Visit our implementations page or contact us to scope your project.

Ready when you are

Less busywork. More delivery, everywhere.

See how JetStack AI turns weeks of manual ops into minutes.
Book a demo now. No commitment, no sales pitch.

Free trial
Set up in under 5 minutes
Works with your existing portal