What Actually Breaks When You Migrate a CRM (Lessons From 9,000 Contacts)

The migration: 9,000 contacts, 1,000 accounts, one CRM to another

We moved 9,000+ contacts and 1,000 accounts out of a client's HubSpot portal into Dynamics 365 Sales Enterprise. The number by itself isn't the interesting part — plenty of migrations move more. What it confirmed is that the failure points in a CRM migration don't depend on which two platforms are involved. They depend on how much the sending system and the receiving system disagree about what a "contact" actually is.

Where duplicates come from, and why exporting them doesn't fix anything

A contact gets created from a web form, then again from a CSV import six months later, then a third time when a rep adds them manually because search didn't turn up the first two. Same person, one email address, three records — different notes on each, and none of them owns the full call history. Migrate that straight across and the new system inherits the mess, and usually gets blamed for it. Deduping has to happen before the move, because once independent activity history is attached to each duplicate in the new system, merging means picking whose notes survive.

Fields that don't have anywhere to go

Every CRM accumulates custom properties nobody quite remembers creating — an old lifecycle stage, a lead-score field from a scoring model that got retired, a free-text box someone used for three months and then abandoned. The destination system rarely has a matching field waiting for it. Each one needs a decision — keep it, map it to the closest equivalent, or archive it — made before the migration runs, not discovered during it.

The part everyone forgets: history

A contact record's value usually isn't the name and email — it's the years of notes, emails, and call logs attached to it. Most migration tools move the object cleanly and leave the timeline behind unless someone builds that step in on purpose. Losing that is invisible on migration day and expensive three weeks later, the first time a rep needs to know what was already said to someone.

Same problem, whichever direction the data moves

The migration above went out of HubSpot. The same three things — duplicates, orphaned fields, and history — are exactly what we check first on the way in, when the project is a HubSpot implementation rather than a HubSpot migration. The direction changes which schema you're mapping into; it doesn't change what has to survive the trip.

Related services

Frequently asked questions