Someone at this company was manually googling company web addresses to figure out whether two records were the same client.
That's not an exaggeration for effect. It was the actual deduplication process, a person and a search bar, because the database had no unique identifier for clients. This is a healthcare company with a real business and smart people, running on a CRM whose data model was designed in 2018 for a business model they no longer have. The symptoms had been piling up for years: outreach going to the wrong clients, an import that couldn't proceed because there was nothing to match records on, and reps accidentally enrolling existing customers in prospecting sequences because the enrollment screen surfaces the most recent contacts and nothing marks a contact as a customer.
They came to us planning a CRM migration. Our recommendation was to not migrate anything yet.
Here's the uncomfortable mechanic. A migration moves data and hardens it on the way. It cleans nothing. Records get matched, merged, and written into a new schema, and every ambiguity in the old system becomes a permanent decision in the new one, made by a matching algorithm at 2 a.m. rather than by anyone who understands the business. Migrate a database with no unique identifiers and you get your duplicates back, with new IDs, in a system where everyone now assumes the data is trustworthy because it's new.
The sequence that works is audit first, re-architect second, migrate third. Understand the business as it runs today, redesign the data model to match it, fix the identifier problem while records still live where people understand them, and only then move. Yes, it delays the migration by a few months. It also means the new system starts clean instead of inheriting a mess with better branding.
The same audit reviewed this company's licensing and found 20 legacy enterprise-grade seats grandfathered onto their plan, quietly inflating cost for capacity nobody used. That's a real reduction in annual spend, discovered as a side effect of understanding the system before changing it. In my experience this is typical. Systems that haven't been examined in years accumulate both data debt and spend debt, and the audit that finds one usually finds the other.
The objection I hear is momentum: "we've finally got budget and executive attention for the migration, and an audit phase risks losing both." I get it, and it's a real risk. But executive attention survives a phased plan with visible early wins (the seat savings alone funded a chunk of this audit). What executive attention does not survive is a migration that ships on time and produces a system nobody trusts.
If your migration plan has no audit phase, ask one question before you sign it: what's our unique identifier, and does every record have one? If the room goes quiet, you have your answer about sequencing.