TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

AI-Powered Data Quality: What CRM Migrations Get Wrong and How Machine Learning Fixes It

You can leverage AI and machine learning to improve your data quality if you approach it right. Check out the four practical recommendations in this article.

• By Omer Shakeel
• October 28, 2026

Every year, thousands of organizations migrate their donor databases from one CRM to another. In that moment, before the new system goes live, they’re sitting on the single best opportunity they’ll get in years to fix problems that have been quietly accumulating in their data for a decade. Almost none of them use it that way.

I have seen this firsthand over the years, working closely with data. Migrations are driven by deadlines, not data quality. Timelines are rushed because a vendor contract is running out, and the new platform’s billing cycle has already started, and every extra month spent running two systems in parallel is money wasted. Under that kind of pressure, the project’s definition of success narrows to a single question: Did the records make it from the old system to the new one without breaking anything visible? Whether the data was actually accurate to begin with is rarely part of the scope.

Common Quality Issues

Working on donor databases has exposed me to the issues they face. The first is entity duplication that isn’t obvious: the same donor may exist as two or three separate records because a name was entered differently over the years, an address changed, or a phone number and email were updated in one system but never reconciled with another. These issues are not caught using SQL or running a Python script. The problem is sneaky and usually only caught when those specific records are reviewed for business purposes.

The second issue is a more serious one that many nonprofits are cautious about. It is deceased data. Sending a solicitation request to a deceased donor would look very disrespectful, and many databases need to be mindful of this. There is a schema architecture in place to handle deceased data, but the real question is whether it is accurate.

Neither of these problems gets fixed by simply moving data faster or more accurately. Both require treating the migration as more than a transfer. This article explores four recommendations for leveraging AI and machine learning to improve data quality, especially during migration.

Recommendation #1: Probabilistic Matching for Entity Duplicates, Scored by Confidence

Exact-match rules operate on raw string equality and miss donors fragmented across nickname variants, maiden names, or transposed fields. Instead, we can deploy embedding-based semantic matching. This model solves duplication problems at the representation level: a sentence encoder maps each name, address, or contact field into a dense vector, trained so that semantically equivalent entities land close together in embedding space. “Jon Doe” and “Jonathan D.” resolve as near-neighbors by vector proximity, not lexical overlap.

At scale, this requires an approximate nearest-neighbor index (e.g., FAISS or HNSW) and a blocking step. We can deploy coarse candidate generation on a cheap key, such as ZIP code, to keep pairwise comparisons tractable. The resulting similarity score should be treated as an empirical confidence level. That confidence score determines whether a match is resolved automatically or flagged for a human reviewer to confirm and merge. 

Recommendation #2: Probabilistic Deceased-Match Scoring Instead of a Binary Flag

Most CRMs already have an “IsDeceased” column, but it’s typically a static Boolean with no visible source or confidence. Rather than replacing the column, we migrate it as-is and layer a model on top of it. The model is a supervised classifier (possibly just a simple gradient-boosted tree or logistic regression) that can score each record using a small set of engineered features:

• Whether the existing “IsDeceased” value matches a third-party deceased-suppression source like the SSA Death Master File
• Donor/Customer age
• Recency of last activity relative to that age

A donor who is 85 with no gift, email open, or contact since 2010 carries a very different risk profile than a 40-year-old with the same gap, and a feature-based model captures that interaction directly rather than relying on any single signal in isolation.

The model’s output is a confidence score attached to each record’s existing “IsDeceased” value, not a replacement for it: high-confidence records carry their current “IsDeceased” value forward into the new system unchanged, while low-confidence records are flagged for a human reviewer, who investigates potentially through direct outreach to the family or household and updates “IsDeceased” in the new system based on what they find.

Recommendation #3: NLP Extraction from Employee Notes to Surface Signals that Structured Fields Miss

Advancement CRMs rely heavily on free-text contact reports and call notes, which often contain the earliest, most reliable signal of a status change, a death, a job change, a relationship change, buried in prose that never makes it into structured fields. We can run an NLP/LLM pass over historical notes during migration to extract these signals and route them as suggested updates, rather than letting years of frontline intelligence sit unused.

This is a bounded extraction task rather than open-ended summarization: the model is looking for a small, defined set of event types, and each candidate update should carry a confidence score and a citation back to the source note so a reviewer can confirm it before it touches the structured schema.

Recommendation #4: ML-Based Giving-Pattern Anomaly Detection to Validate Proposed Merges

Before finalizing a match from recommendation 1, we can model each record’s giving trajectory, frequency, amount, campaign responsiveness, channel, etc. and use this data to check whether the combined history reads as one coherent donor or two different behaviors stitched together. This can help us catch false-positive merges that identity resolution alone would mistakenly approve, since name and address similarity can’t distinguish between two people who happen to share both.

This functions as a second, independent model sitting downstream of the embedding-based matching in recommendation 1. One model resolves identity, the other validates behavior, and a proposed merge clears both before it’s finalized.

The Opportunity to Clean Your Database

None of this requires exotic infrastructure. It requires a decision, made before your migration starts, that entity resolution is part of its actual scope, not an assumed side effect of moving data from one system to another, and not a cleanup phase to schedule “after go-live,” which in practice rarely arrives once the deadline that justified the project has passed.

Every organization running a CRM migration this year has, whether it plans to use it or not, the one window it will get for a long time to apply AI to its dirtiest, highest-stakes data. The only question is whether that window gets used to move the problem forward or finally resolve it.