Skip to content
  • There are no suggestions because the search field is empty.

HubSpot migrations: understanding scope, preparation and responsibilities

Understand the main ways to migrate data into HubSpot and how preparation, testing, cutover and validation affect the outcome.

A HubSpot migration moves selected data, content or configuration from an existing system into HubSpot.

A migration is rarely a direct copy of everything held in the source platform. Different systems structure information in different ways, so a successful migration requires decisions about what should move, how it should be represented in HubSpot and what should remain available elsewhere.

Common migration methods include:

  • Standard file imports
  • HubSpot Smart Transfer
  • Specialist migration tools or custom solutions

The appropriate method depends on the source system, data volume, complexity, history, relationships and quality.

A migration is more than an import

An import is the technical action of adding or updating information in HubSpot.

A migration is the wider process of:

  • Identifying source data
  • Deciding what should move
  • Cleaning and transforming information
  • Mapping it to HubSpot
  • Testing the migration
  • Completing the final transfer
  • Validating the result
  • Managing the transition from the previous system

An import tool may perform part of a migration, but it does not make the planning and governance decisions.

What can be migrated?

Depending on the migration method, HubSpot can receive information such as:

  • Contacts
  • Companies
  • Deals
  • Tickets
  • Leads
  • Products and line items
  • Invoices and orders
  • Custom objects
  • Calls
  • Meetings
  • Notes
  • Tasks
  • Selected email activities
  • Record owners
  • Pipelines and stages
  • Associations between records

The objects and activities that can be transferred depend on your HubSpot subscription, the source system and the selected migration method.

Assets such as workflows, reports, dashboards, forms, marketing emails and website content may require separate recreation or specialist migration work. They should not be assumed to move with CRM records.

Standard file imports

Standard imports use spreadsheet or CSV files prepared for HubSpot’s import tool.

This is often the most flexible approach for straightforward or selective migrations.

How file imports work

The usual process is:

  1. Export the required information from the source system.
  2. Clean and restructure the data.
  3. Create the required HubSpot properties, pipelines and objects.
  4. Map source columns to HubSpot properties.
  5. Import a test sample.
  6. Review records, associations and errors.
  7. Correct the source files or mapping.
  8. Complete the agreed final imports.
  9. Validate the result.

HubSpot can import individual objects or multiple related objects. Multi-object imports can create associations when the files contain appropriate identifiers.

When file imports may be suitable

File imports can work well for:

  • Data held in spreadsheets
  • Straightforward CRM exports
  • Contacts and companies
  • Deals and simple pipelines
  • Tickets
  • Products and other supported objects
  • Selected activities
  • One-off or phased migrations
  • Situations where data should be cleaned before it enters HubSpot

Key considerations

File imports require careful preparation.

Consider:

  • Required properties
  • Unique identifiers
  • Date and number formats
  • Dropdown option values
  • Record owners
  • Pipeline and stage values
  • Associations between objects
  • Duplicate prevention
  • Marketing contact status
  • Lawful basis and communication consent
  • Whether existing values may be overwritten

HubSpot can import supported activities, including calls and meetings. However, activity migration has additional requirements and limitations. For example, existing emails, meetings, notes and tasks cannot be updated through a later import.

Historical data should therefore be tested carefully rather than assumed to behave like standard CRM properties.

HubSpot Smart Transfer

HubSpot Smart Transfer provides a guided transfer process for supported source applications.

It uses Data Sync to transfer supported objects and engagements, with one-time post-sync transfers available for certain additional data.

Supported platforms currently include selected CRM, marketing and service applications. The list and available data types can change, so check HubSpot’s current documentation before choosing this approach.

When Smart Transfer may be suitable

Smart Transfer may work well for:

  • Moving from a supported CRM or marketing platform
  • Transferring several related objects
  • Preserving supported associations
  • Reducing manual file preparation
  • Auditing mappings before data is transferred
  • Managing a structured CRM-to-HubSpot transition

Key considerations

Smart Transfer does not automatically move everything from the source platform.

Each supported application has its own:

  • Object mappings
  • Supported engagements
  • Unsupported data
  • One-time transfer options
  • Field limitations
  • Subscription requirements

Custom objects are not currently supported by Smart Transfer.

Custom automation, reports and business logic should also be assessed separately. A data transfer does not recreate every process or configuration from the previous platform.

Specialist migration tools and custom solutions

A specialist migration tool or custom solution may be required when standard imports and Smart Transfer cannot meet the requirement.

This approach may use:

  • A specialist migration platform
  • Extract, transform and load software
  • Middleware
  • HubSpot APIs
  • Custom scripts or applications
  • A combination of file imports and API-based processing

When a specialist approach may be suitable

It may be appropriate for:

  • Unsupported source systems
  • Heavily customised CRMs
  • Complex custom objects
  • Large data volumes
  • Extensive historical activity
  • Complicated associations
  • Significant data transformation
  • Multi-system consolidation
  • Phased or multi-region migrations
  • Requirements for repeatable migration runs

Key considerations

Specialist migrations normally require additional technical design and testing.

They may also involve:

  • Separate software licences
  • Development costs
  • API and infrastructure requirements
  • Additional security assessment
  • Custom monitoring and error handling
  • Ongoing technical support

Using a specialist tool does not remove the need to clean source data or define how it should map to HubSpot.

Choosing a migration method

The migration method should be based on the actual data requirement rather than a preference for a particular tool.

Review:

  • The source systems
  • The objects that need to move
  • The required properties
  • Record volume
  • Associations and hierarchy
  • Historical activities
  • Attachments and files
  • Custom objects
  • Pipeline history
  • Ownership information
  • Consent and subscription data
  • Data quality
  • Cutover timing
  • Available budget and technical resources

A migration may use more than one method. For example, Smart Transfer might move supported CRM records while a separate process handles attachments, unsupported history or custom data.

Decide what should migrate

Moving every available record is not always the best approach.

Before migration, classify data as:

  • Required for active operations
  • Required for reporting or compliance
  • Useful historical context
  • Suitable for archiving
  • Duplicate, obsolete or unnecessary
  • Inappropriate to retain

Migrating poor-quality or irrelevant information increases effort and can make the new CRM harder to use.

An archive outside HubSpot may be more appropriate for information that must be retained but does not need to support day-to-day processes.

Data cleaning and preparation

Source data should be profiled and cleaned before the final migration.

Common issues include:

  • Duplicate contacts or companies
  • Missing identifiers
  • Invalid email addresses
  • Inconsistent dates
  • Unrecognised owners
  • Obsolete pipeline stages
  • Free-text values that should be structured
  • Conflicting consent information
  • Missing associations
  • Incomplete or unsupported activity data

Data should also be transformed to fit the approved HubSpot data model rather than simply reproducing the structure of the previous system.

Mapping data to HubSpot

A migration mapping defines how source information will be represented in HubSpot.

The mapping should document:

  • Source object
  • Source field
  • HubSpot object
  • HubSpot property
  • Field type
  • Transformation rule
  • Accepted values
  • Unique identifier
  • Association method
  • Whether the field is required
  • Whether empty values may overwrite existing information

Mapping decisions should reflect the future operating model. Recreating every legacy field can carry outdated processes into the new CRM.

Unique identifiers and duplicate prevention

HubSpot uses unique identifiers to match imported rows with existing records.

Depending on the object, these can include:

  • HubSpot Record ID
  • Contact email address
  • Company domain name
  • A custom property configured to require unique values

The correct identifier should be selected before importing data.

Where no reliable identifier exists, additional cleansing or matching logic may be required. Otherwise, the migration may create duplicates or update the wrong records.

Associations

Associations connect records such as:

  • Contacts to companies
  • Contacts to deals
  • Deals to companies
  • Tickets to contacts
  • Activities to relevant CRM records
  • Parent and child companies

Associations often require shared identifiers across import files or suitable relationship fields in the source system.

A record count alone does not prove that a migration is correct. The relationships between records must also be tested and validated.

Historical activities

Historical activities can provide valuable context, but they increase complexity.

Before migrating activities, decide:

  • Which activity types are required
  • How far back the history should go
  • Which records each activity should be associated with
  • Whether ownership and timestamps can be preserved
  • Whether attachments or message content are included
  • Whether the source export contains enough information
  • Whether HubSpot supports the required import behaviour

Older activity data may also contain sensitive, irrelevant or poor-quality information. Retention and privacy requirements should be considered before it is moved.

Consent and marketing status

A migration must preserve more than names and email addresses.

Where relevant, include approved information about:

  • Communication subscriptions
  • Opt-outs and unsubscribes
  • Lawful basis
  • Consent evidence
  • Marketing contact status
  • Data retention requirements

Historical opt-out data should be migrated through the appropriate HubSpot process before marketing communications begin.

Your organisation remains responsible for confirming that personal data can be lawfully migrated and used.

Test migrations

Complete at least one controlled test before the final migration.

Testing should confirm:

  • Record counts
  • Property values
  • Dropdown mappings
  • Dates and time zones
  • Currency and number formats
  • Owners
  • Pipelines and stages
  • Associations
  • Activities
  • Duplicate behaviour
  • Consent and subscription information
  • Automation triggered by imported data
  • Reporting results
  • Import errors

Use representative records, including complex and unusual examples rather than only the cleanest data.

Test results should be documented and any mapping changes reflected in the next migration run.

Automation during migration

Imports and synchronisation can trigger workflows, notifications, lead rotation and other automation.

Before importing data:

  • Review active workflows
  • Check enrolment criteria
  • Decide which automations should be paused
  • Prevent unwanted emails or notifications
  • Review connected integrations
  • Confirm how imported dates and statuses will affect reporting

Automation should be re-enabled only after the relevant data has been validated.

Final migration and cutover

The final migration needs a clear cutover plan.

This should define:

  • When users stop updating the old system
  • When the final source data is extracted
  • Which changes occurred after the test migration
  • The order of imports
  • Who validates each data area
  • When users can begin working in HubSpot
  • How rejected records and errors will be handled
  • Whether the legacy system remains available as an archive
  • What would trigger a rollback or correction process

Without a controlled cutover, records may be updated in both systems and important changes can be missed.

Security and responsibilities

Migration files may contain personal, financial or confidential information.

Your organisation should:

  • Restrict access to source exports
  • Use approved storage and transfer methods
  • Avoid sending sensitive files through inappropriate channels
  • Control who can import information
  • Retain backups before transformation
  • Define when working files should be deleted
  • Record who approved the migration
  • Include migration data within applicable security and retention policies

HubSpot provides import and transfer tools, but your organisation remains responsible for deciding what data can be moved, retained and used.

Validating the completed migration

After the final migration, compare the result with the approved source and mapping.

Validation should include:

  • Record counts by object
  • Spot checks of important records
  • Required property completion
  • Associations
  • Owners
  • Pipeline stages
  • Activities and dates
  • Opt-outs and subscription status
  • Duplicate checks
  • Import errors
  • Workflow behaviour
  • Reporting totals

A migration should not be considered complete until the agreed checks have passed and material exceptions have been documented.

What can Forbidden help with?

Forbidden can help you:

  • Assess migration options
  • Review and profile source data
  • Define the migration scope
  • Design the HubSpot data model
  • Prepare mapping documents
  • Clean and transform data
  • Configure properties, objects and pipelines
  • Complete test and final imports
  • Support Smart Transfer where suitable
  • Coordinate specialist migration requirements
  • Validate records, associations and automation
  • Plan cutover and handover

Your organisation remains responsible for approving the data to be migrated, confirming retention and privacy requirements, providing complete source data and validating that the migrated information meets its operational needs.

Further information