Skip to content
ERP & CRM 3 min read

Migrating CRM without losing the history that makes it useful

Most CRM migrations move contacts and deals and quietly drop everything that explains them. Then forecasting breaks and nobody can say why.

The webbox team ·

Short answer: A CRM migration that moves only current state — contacts, open deals, owners — will look successful on the day and fail three weeks later, when someone asks how this quarter compares to last and the answer is not in the system any more. Stage history, activity timelines and closed-won records are what make a CRM worth querying, and they are the first thing a rushed migration drops.

What actually needs to move

Every migration plan lists contacts, companies and open opportunities. Those are the easy part; they map almost one-to-one between platforms. The parts that get left behind are the ones that carry meaning:

  • Stage transition history. When a deal entered each stage, and how long it sat there. Without it, you cannot compute cycle time, stage conversion or velocity, which is most of what a sales leader looks at.
  • Activity timelines. Calls, emails, meetings and notes attached to the record. A rep opening an account with no history has to reconstruct the relationship from memory or from their inbox.
  • Closed-won and closed-lost. Including loss reasons. Drop these and year-on-year comparison silently starts from zero.
  • Custom fields nobody documented. There is always a picklist somebody's reporting depends on that appears in no requirements document.

De-duplicate on the way in, not afterwards

Every CRM that has been running for a few years has duplicates. Migration is the one moment when merging them is cheap, because you are touching every record anyway and no user is mid-edit.

Agree the merge rules with whoever owns sales operations before extraction: which system wins on conflict, how you match (domain, not company name), what happens to two owners on the same account. Then apply them during load. Left as a cleanup project for afterwards, it does not happen, and reps lose trust in the new system in the first fortnight.

Reconcile before you switch anybody over

The step that separates a migration from a data dump is reconciliation. Before the team stops using the old system, tie back:

  • Record counts by object and by owner.
  • Total open pipeline value, and by stage.
  • Closed-won totals for the last several periods, matched against the reports leadership already trusts.

If the new system's numbers do not match the old system's reports, find out why before cutover. Almost always it is a definition difference rather than lost data, and finding that out afterwards costs far more than finding it out now.

Automation does not port

This is the part that surprises people. Contacts and deals migrate. Workflows, validation rules and automation do not, in any meaningful sense — the models are different enough that porting is usually more work than rebuilding, and rebuilding gives you the chance to drop the six automations nobody remembers enabling.

Budget for re-implementing the automation deliberately, and use the migration as the opportunity to keep only what earns its place.

Run parallel briefly, then commit

A short parallel period — one or two weeks, with the old system read-only — lets the team find what is missing while the fix is still cheap. Any longer and you get dual entry, which is worse than either system alone.

We migrate between Salesforce, HubSpot, Zoho, Pipedrive and ERP-native CRM in every direction, which mostly means we have seen which of these steps teams are tempted to skip. It is always reconciliation, and it is always the one that costs the most to skip.

#crm#migration#salesforce#hubspot#zoho
Share
T

The webbox team

Engineering

Notes from the engineers building software, ERP and AI at webbox.

Want help with something like this?

Tell us the problem. We'll come back with a plan, a price, and who'd actually build it.

  • Free scoping call
  • Reply within 1 business day
  • No lock-in