HubSpot migration checklist

Old systems collect fields someone needed for a month or two, and years later nobody knows what they are for. Moving them to HubSpot means moving the mess.

There are three options: do not move it, map it to an existing HubSpot property, or create a new one. Write the decision in the mapping sheet before the import starts.

Activity history is separate work. A native email migration leaves only a note without the message body, so decide what your team really needs.

You cannot copy the old system one to one, and you should not try. Migration is the right moment to fix the data model, because changing the structure later means moving the data again.

With the old ID stored in a unique property, HubSpot updates records on the next import. Without it, deals and notes are easy to duplicate.

A contact usually by email, a company by domain or VAT number. Merged records are practically impossible to split, so only merge the clear cases.

The import assigns records to users who already exist in the portal. Without accounts, reps cannot see their customers after launch and someone has to reassign records by hand.

Moving in pieces, starting with sales, is simpler than switching everything at once.

When both systems run side by side, people go back to where their data is. The old system can stay, but read-only.

An import can trigger workflows and send email to your whole database. Back up the data, turn off automation and run the import on a weekend, when nobody is working in the data.

Compare record counts in the old system and in HubSpot, then check a dozen of the oddest records by hand. A green import status does not tell you the data landed in the right fields.

The hardest part of a migration is people, not data. The team needs a few short sessions on their own data to stop looking for things where they used to be.