When Your CRM Data Is Lying to You: A Migration Reality Check

Every CRM migration I’ve done starts the same way. The client tells me they have X records. I ask how many are genuinely active. There’s a pause. Then a number considerably smaller than X.

The gap between those two numbers is where the problems live.

I’ve seen a 40-person sales team working out of a CRM with 90,000 contacts — of which maybe 12,000 had been touched in the past 18 months, 3,000 were duplicates in various states of conflict, and at least 800 had email addresses that hadn’t been valid since the Obama administration. The CRM said 90,000. Reality said somewhere around 9,000, and even that number required caveats.

This is not unusual. It might be your situation right now. And if you’re planning to use AI to do anything with your CRM data — scoring leads, personalizing outreach, forecasting pipeline, building a RAG system over your customer records — the state of that underlying data is the single most important variable in whether the AI actually works.

Your AI cannot outperform your data. It will faithfully, consistently learn whatever patterns exist in what you’ve given it — including the garbage.

How CRM Data Gets This Bad

It doesn’t happen all at once. It accumulates over years through a set of completely predictable behaviors.

Import-and-forget. A tradeshow, a webinar, a list purchase. Someone imports a spreadsheet of 2,000 contacts into the CRM in batch. They work through maybe 200 of them. The other 1,800 sit there indefinitely, technically “in the system.” Nobody deletes them because nobody thinks to. Over five years of quarterly events, that’s 40,000 contacts of varying quality, provenance, and relevance sitting in a system that counts them all the same.

Field discipline entropy. The company started using HubSpot in 2019. The original team had a clear convention for the “Lead Source” field: seven values, used consistently. Then people left. New reps joined. Nobody documented the convention. By 2024 the same field has 47 distinct values, including “tradeshow,” “Trade Show,” “Trade show 2022,” “Event,” and “austin event (sarah).” You can’t segment on that field in any meaningful way. It’s noise wearing the costume of data.

The duplicate accumulation problem. Most CRMs have duplicate detection. Most duplicate detection is set to “flag for review.” Most flagged duplicates never get reviewed because it’s not anyone’s job. Over time you get contact records for the same person across five different email address variations — their work email, their old work email from two jobs ago, their Gmail, the email they used to download your ebook, and the email their assistant used to book a demo. You have five records. You have one relationship. Your reporting thinks you have five relationships.

Contact decay. Email addresses become invalid. People change jobs. Companies get acquired. Roles shift. Industry benchmarks suggest B2B contact data decays at roughly 22-30% per year — meaning in three years, a third of your contacts are pointing at the wrong place. The CRM doesn’t know this. It just keeps counting.

What You’re Paying for Bad CRM Data

The cost isn’t just operational. It’s financial, and it’s direct.

Email deliverability. Sending to a list with 30% bad addresses tanks your sender reputation. Gmail and Outlook’s spam filters are increasingly sophisticated — once your domain is flagged as a high-bounce sender, you’re fighting uphill on every campaign you send after that, including to the valid addresses. Cleaning your list before your next send is not optional if you care about deliverability.

Wasted sales capacity. If your reps are working from a lead queue that includes a significant percentage of dead, irrelevant, or duplicate records, they’re spending time on contacts that can’t convert. At a fully-loaded cost of $80-120k per sales rep, every hour spent on records that shouldn’t be in the queue is expensive. At scale, across a team, it’s the kind of waste that doesn’t show up on any single line item but absolutely shows up in why pipeline targets keep getting missed.

Broken AI. If you build a lead scoring model on CRM data that’s 30% noise, your lead scores are built on noise. If you build a customer segmentation on data where the industry field has 80 inconsistent variations, your segments are fiction. If you train an AI to forecast deal probability on data where the “stage” field was entered inconsistently across three sales teams over five years — every probability score it outputs inherits that inconsistency. Bad data doesn’t just limit AI performance; it poisons it in ways that look like model problems but aren’t.

The Migration Moment of Truth

Here’s when the bad news usually lands: during a CRM migration.

You’ve decided to move from Salesforce to HubSpot, or from HubSpot to a custom Postgres database, or from a legacy on-premise CRM to anything modern. You hire someone (hopefully with migration experience — there are questions worth asking) and the project starts.

The first phase is data audit. We map every field, every object, every relationship. We run profiling queries. And then you see it: the completeness rates, the duplicate ratios, the field value distributions, the records with no activity in years.

Most clients experience this as the migration “finding problems.” But the problems were there before we looked. What changed is that migration forced you to look — to actually enumerate the data rather than just use it case by case in a UI that papers over the inconsistencies.

The migration moment is actually an opportunity, which is genuinely how I’ve come to think about it. You’re touching everything anyway. You’re making decisions about what to carry forward and what to leave behind. The cost of cleaning is lower during migration than any other time because you already have the data mapped, the transformation scripts running, and the context to make good decisions about what “clean” means for your business.

The alternative — migrating the dirty data as-is — means carrying five years of accumulated noise into your new system on day one.

A Practical Framework for CRM Data Remediation

You don’t have to wait for a migration to do this, and the approach is the same either way.

Step 1: Profile before you touch anything. What’s the completeness rate for each important field? What are the actual value distributions for categorical fields — and how many “legitimate” values are there versus noise? What’s the duplicate rate, estimated by email address match? What percentage of contacts had any activity in the past 12 months? 24 months? These numbers set the scope.

Step 2: Define what “good” looks like. For lead source, define the canonical list of values and what they mean. For company size, agree on whether it’s an employee count, a revenue band, or some other classification. For deal stage, map every value in the current system to the intended stage definition. This is the unglamorous work — it involves actual human beings with domain knowledge making actual decisions. There’s no automated shortcut for it.

Step 3: Automate the mechanical cleanup. Deduplication logic (email-based matching plus fuzzy name matching for edge cases). Standardization of categorical fields to canonical values using mapping tables. Null-filling for fields that can be derived from other fields. Email validation against a bulk validation service to identify hard bounces proactively. These are scriptable, parallelizable, and worth running before any human touches anything.

Step 4: Route the judgment calls to humans. After automated cleanup, you’ll have a residual set of records that need a human decision: true duplicates where the master isn’t obvious, contacts where the right “Lead Source” is genuinely ambiguous, companies that have been acquired and need to be merged or split. Build a lightweight review queue. Give it to someone with context. Time-box it. Don’t let perfect be the enemy of materially better.

Step 5: Enforce going forward. Data contracts at field level — required fields can’t be null, categorical fields can only accept defined values, duplicate check runs at import. Whatever the new system is, the data entry rules that prevented discipline in the old system shouldn’t follow you. This is also where the migration’s value compounds: clean data at migration time only stays clean if you build the guardrails that keep it that way.

The Payoff

I’ve seen teams get measurable improvement in email open rates within 60 days of a list-cleaning exercise, simply by removing bad addresses and re-engaging only the records that could actually receive messages. I’ve seen AI lead scoring that was running at frustrating accuracy levels dramatically improve after the underlying data was standardized — without touching the model at all.

The pattern holds: the real cost of bad data shows up downstream, in AI performance, in sales efficiency, in marketing deliverability, in pipeline accuracy. The remediation pays for itself multiple times over. But it has to be the first step, not something you plan to do after you’ve built everything on top of the mess.

If you’re approaching a CRM migration and you want to understand what the data audit would actually surface — or if you’re already seeing AI performance that you suspect has a data problem underneath it — let’s look before we build.