Migrating to HubSpot Without Losing Your History

"We're treating it as a fresh start," the operations lead said, "so we're just bringing the active contacts across." I asked what would happen to the four years of closed deals, call notes, and won-and-lost history sitting in the old system. There was a pause. "I suppose that's... in the old CRM if we ever need it." That pause was the whole project in miniature.

This is an anonymised, composite version of a situation I see regularly — a B2B services firm, several years of accumulated CRM data, moving to HubSpot and understandably keen to leave behind a system they'd grown to dislike. Moving to a new CRM is often sold as a fresh start, and part of that framing is genuinely healthy and part of it is quietly dangerous. A fresh start on process, structure, and discipline — yes, welcome it. But a fresh start that leaves your history behind is a disaster you won't feel until three months later, when someone opens a long-standing customer's record, sees nothing before the migration date, and asks where the last four years went.

The data being moved isn't just names and email addresses. It's the record of every relationship the business has — who spoke to whom, what was agreed, when a deal was won or lost and why, which customers have quietly been loyal for years. Lose that context in the move and you've kept the contacts but discarded the relationships. The migration is the exact moment that history is most at risk, and getting it across intact turned out to be most of the actual work.

The migration isn't the move — it's the mapping

People picture a migration as lifting data from one place and setting it down in another. The moving is the easy part; tools do it. The hard part, and the part that decides whether the result is any good, is the mapping: deciding how the concepts in the old system correspond to the concepts in HubSpot.

The old CRM had its own idea of what a contact was, what a company was, what a deal was, and which fields described each. HubSpot has its own model, and the two never match exactly. Every field has to be deliberately mapped to a destination, and the fields with no obvious home are where the real thinking happens. Rush this and you get data landing in the wrong places, custom fields silently dropped on the floor, and relationships broken because the link between a contact and their company didn't survive the translation.

The old system, for instance, had a single free-text "Account Manager" field. HubSpot models ownership as a proper user association. Mapping one to the other wasn't a copy — it was a decision about how ownership should work going forward, disguised as a data question.

A migration is a data-modelling exercise wearing the costume of a data-transfer exercise. Treat it as the former and you'll do it well; treat it as the latter and you'll faithfully transfer a mess.

Deciding what was worth bringing

Not everything in the old system deserved to make the trip, and pretending otherwise makes the migration harder and the result worse. A migration is a rare, valuable chance to leave the rubbish behind — the one moment when deleting data feels like progress rather than loss.

So before moving anything, we sorted the data honestly into buckets:

The operations lead had it exactly backwards, in a common way. Her instinct was to bring across little — just active contacts — while dropping the history. The right instinct is closer to the opposite: be ruthless about junk records, but protective of the history attached to the records you keep.

Preserving the history, not just the records

Here's the distinction that separates a good migration from a hollow one. Bringing across the current state of things — the contacts, the companies, the open deals — is relatively easy. Bringing across the history — the record of what happened over time — is much harder and much more valuable.

That history includes past interactions and notes, the timeline of how a deal progressed, when a relationship began, and the closed deals, won and lost, that tell you which customers matter and how they found you in the first place. A CRM without this can tell you who your contacts are but not the story of your relationship with them — and that story is most of a CRM's real worth. It's the difference between "this is a company we have a contact at" and "this is a client who has renewed three years running, first came via a referral, and once churned briefly over a billing dispute we resolved."

Some of this maps cleanly into HubSpot's own structures — activities, notes, deal stages, associations. Some of it needs judgement and a bit of craft:

// The old system had one "Customer Since" text field with no HubSpot equivalent.
// Rather than lose it, we created a custom property and preserved a human-readable
// summary of pre-migration history that wouldn't map field-for-field.
{
  "properties": {
    "original_acquisition_date": "2021-03-14",
    "legacy_account_id": "OLD-4471",
    "migration_note": "Client since 2021 via referral. Churned Q2-2023 over a "
      + "billing dispute (resolved), renewed 2023. History before this date "
      + "lives in the archived export, ref OLD-4471."
  }
}

That migration_note is not elegant data modelling, and I'd never design a live system around free text like it. But it preserved something that would otherwise have evaporated, and it meant that someone opening the record after the migration saw a continuous history rather than a record that appeared to spring into existence on migration day. The goal throughout was continuity: no customer should look, in the new system, like they were born the week we switched.

Testing on a slice before moving everything

The most common way a migration goes wrong is running the whole thing in one big attempt and discovering the problems only after everything has landed badly. By then the damage is spread across the entire dataset, and untangling it is genuinely miserable — you can't cleanly tell which records were wrong on arrival and which got mangled in transit.

So we migrated a small, representative slice first: a few hundred records chosen to include the awkward cases as well as the easy ones — the contact linked to three companies, the deal with a decade of notes, the record with the missing acquisition date. Then we checked the result properly against the source. Did every field land where it should? Did the relationships survive? Did the history come across? Did the associations between contacts and companies hold?

   ┌───────────┐   slice    ┌───────────┐   verify    ┌──────────────┐
   │  old CRM  │ ─────────▶ │  HubSpot  │ ──────────▶ │ compare vs   │
   └───────────┘  ~300 recs └───────────┘  field-by-  │   source     │
        │                        ▲          field      └──────┬───────┘
        │                        │                            │
        │                        │        fix mapping ◀───────┘  problems
        │                        │        (cheap now)
        │      full load         │
        └────────────────────────┘  ◀── only when the slice is clean

The slice surfaced two mapping problems while they were still cheap to fix: a multi-select field that was collapsing to a single value, and a company association that broke whenever a contact belonged to more than one company. Both would have been catastrophic across the full dataset and were trivial to correct on three hundred records. Skipping this step to save a day almost always costs several days later, and a good deal of trust along the way. The team that watches a migration land badly is the team that quietly starts keeping its own spreadsheets again — the exact outcome the migration was meant to end.

Validating like you don't trust it — because you shouldn't

After the full migration, the temptation is to declare victory and move on. Resist it. A migration isn't finished when the data has moved; it's finished when you've confirmed the data moved correctly. Those are different milestones, and the gap between them is precisely where silent errors live.

Real validation meant several passes, each assuming the worst:

• Count records against the source. If the old system had 8,400 active contacts and HubSpot shows 8,100, three hundred relationships walked off somewhere and you need to know where before anyone relies on the system.
• Spot-check a sample field by field. Not a glance — an actual comparison of specific records against the original, including the awkward ones from the test slice.
• Confirm relationships and associations are intact. Contacts still linked to the right companies, deals still attached to the right contacts.
• Verify the history actually came across rather than assuming it did because the migration reported success. A tool reporting "done" is not evidence the notes are readable.

Crucially, we pulled in the people who'd actually use the system. They spot a wrong or missing value faster than any automated check, because they know what the data is supposed to say — one rep immediately noticed a long-standing client's first-contact date was wrong, something no count or checksum would ever have flagged.

Why the care is the whole job

A migration done properly gives you the best of both worlds: a clean, well-structured new system that still carries the full weight of your history. The team opens a record and sees continuity. The relationships built over years are intact. And because you were selective on the way in, the new CRM isn't burdened from day one with the junk that made the old one hard to trust.

A migration done carelessly gives you the opposite — a new system missing its context, full of misplaced data, and distrusted from the first week. Which is, of course, the very outcome the business switched CRMs to escape.

The moving of data is a technical task that largely takes care of itself. The care — the mapping, the selectiveness, the preservation of history, the slice test, the sceptical validation — is what determines whether you've genuinely moved your business into a new home, or merely copied half of it across and quietly lost the rest. When I went back to that operations lead at the end and opened a long-standing client's record in HubSpot, the whole relationship was there: four years of it, continuous, exactly as it had been. That, and not the number of rows transferred, is what a migration is actually for.