What goes wrong when we move from one CRM to another?

Objects move cleanly; semantics do not

Contacts, companies and jobs are straightforward to move because both systems have something roughly equivalent. The trouble is in everything that carried meaning by convention rather than by structure.

Your old system had a stage called “Follow Up” that everyone understood to mean the customer asked for a call in the spring. The new system has no such stage. Whatever you map it to, that shared understanding does not survive the move, and six months later nobody remembers what those records were.

The things that get lost quietly

• Note authorship and timestamps. Many migrations dump notes as a text blob attributed to the migration user, dated the day of the import. Historical context becomes unreadable.
• Attachments. Photos, signed estimates and permits often live in a separate store that the export ignores. This is a common and expensive discovery made after cutover.
• Activity history. Calls, texts and emails frequently do not have a target object in the new system and get dropped rather than mapped.
• Deleted and merged records. Tombstones rarely migrate, so old references break silently.
• Automation state. Which sequence a contact was in, and where. Restarting everyone at step one after cutover is a classic way to send a very confusing batch of messages.

Reconcile before you cut over, not after

The minimum bar is a count comparison by object type between source and destination: contacts, companies, open opportunities, closed opportunities, jobs, invoices, notes, attachments. Any gap should be explained before you proceed, not investigated afterward.

Then spot-check depth, not just breadth. Pull twenty of your most complex records — a commercial customer with several sites, a household with a long service history, a customer with an open estimate and a warranty claim — and inspect them field by field. Aggregate counts can match perfectly while every complex relationship is broken. This kind of verified data migration work is slow by design, and the slowness is where the risk goes.

Plan the tail, not just the switch

Keep the old system readable long enough to cover a full seasonal cycle, because the questions that expose migration gaps arrive when someone tries to service a job they sold last year. Read-only access is usually cheap; rebuilding lost history is not.

Also plan for the reporting discontinuity. Definitions change during a migration — what counts as a lead, when a job is marked complete — and your year-over-year comparisons will break at the cutover date. Decide in advance whether you will rebuild history under the new definitions or simply annotate the break. Either is defensible. Pretending the seam is not there is what erodes trust in every dashboard afterward.