What Actually Breaks in a CRM Migration, and the Order That Prevents It

The migration goes live on a Friday. The record counts match the old system to the row, and everyone signs off. Three weeks later, a rep opens an account before a renewal call and finds no deals attached to it. Nothing was lost. It just is not connected to anything — and nobody noticed, because nobody was checking for that.

The records arrive. The relationships don’t.

Most migration plans verify the thing that is easiest to count. But a CRM is only useful because of how its records connect — which contacts belong to which company, which deals belong to both — and that is where migrations quietly fail. HubSpot’s import documentation states the rule that decides it: “At least one record in a record pair must already exist in HubSpot before importing.” In practice, that means you cannot create two new records and connect them in the same import.

HubSpot states the rule. It never spells out the order that follows from it. So a team imports deals before companies, the deals arrive with nothing to attach to, and no error appears. The count still matches. The sales team inherits a database full of records that belong to nobody.

A migration that passes the count check can still hand sales a CRM with no memory.

Two things that never carry over

Some history cannot be imported at all, no matter how carefully the file is built.

The first is stage timing. HubSpot tracks when each deal entered and left each stage, and those properties are read-only — they only update as deals move inside HubSpot. Every migrated deal starts its clock on import day. Report on sales velocity the quarter you migrate and you are measuring the migration, not the sales team.

The second is lifecycle history. HubSpot’s lifecycle stages only move forward automatically, and moving a record backward clears the date for the later stage. Import a customer as a lead by mistake and fixing it is not a quick edit.

If velocity and stage-duration reports matter to your board, export them from the old system before cutover and keep them as a static baseline. They will not survive the move, but the history does not have to disappear with them.

The order that works

1. Clean up duplicates first. Validity’s survey of CRM admins in the US, UK, and Australia put duplicates on the problem list for more than half of them. In HubSpot, duplicates do not just clutter the database — they break connections, because relationships get matched on unique keys like email and domain.
2. Companies. They are the parent everything else attaches to.
3. Contacts, connected to their companies.
4. Deals, connected to both.
5. Activities — notes, emails, meetings — connected to records that now exist.

Decide before you start what is not coming over. Records nobody has touched in five years are cost, not history, and every one of them is another chance for a duplicate to break a connection.

The check that actually matters

Skip the count. Open ten accounts the way a rep would before a call. Does each company show its contacts? Do the contacts show their deals? Do the deals show their notes and history? It takes about twenty minutes, and it catches problems no totals report ever will. If any of the ten fail, the migration is not done, whatever the totals say.

So the question to ask a migration partner isn’t “will all our records come over?” They will. It’s “in what order, and how will we know the connections survived?” The answer is the difference between a new CRM and an expensive copy of the old one. 

If you find this content insightful, consider subscribing to our LinkedIn Newsletter and following our company page for our latest articles!