Do not solve a migration failure by simply turning duplicate rules off. Duplicate controls often block a legitimate data load because the incoming file and the target CRM disagree about identity, formatting, matching fields, or merge history. The safer approach is to inventory the rules, normalize the source data, define an exception process, load in controlled waves, and reconcile every result. That protects both the migration timeline and the data-quality controls the business will need after go-live.
Duplicate rules exist for a reason. They prevent teams from creating multiple versions of the same customer, prospect, company, or case. During a CRM migration, however, those controls can become a source of confusing errors. A record looks legitimate in the source file, but the load is blocked because the target system sees a similar email address, name, phone number, or external ID.
The wrong response is to remove every protection and run the load again. That can create a larger cleanup problem, damage trust in the new CRM, and make reconciliation much harder. The right response is to understand what the rule is protecting, determine whether the incoming record is truly new or should update an existing record, and establish a controlled exception path.
This guide uses Salesforce terminology because its duplicate and matching rules make the issue easy to see, but the operating principles apply to most CRM migrations.
A duplicate rule determines what the system should do when a matching rule detects a potential duplicate. A matching rule defines the comparison logic: for example, exact email, fuzzy company name, normalized phone number, or a combination of fields. In Salesforce Data Loader, an error such as “Use one of these records?” indicates that an active duplicate or matching rule is preventing the insert.
That does not mean the rule is wrong. It means the incoming data and the target data have reached a decision point. Common causes include:
The migration team’s job is to classify those conditions rather than treating them all as technical errors.
| Control | What it protects | Migration-safe response |
|---|---|---|
| Matching rule | Identifies likely duplicates based on selected fields and logic. | Document its fields, matching behavior, and known false-positive patterns before loading. |
| Duplicate rule set to block | Prevents creation or update when a potential duplicate is found. | Route matches to an exception queue; do not disable it globally without an approved, time-bound plan. |
| Duplicate rule set to allow and report | Allows operations while recording possible duplicates for review. | Use only when the reviewed risk is acceptable and a post-load reconciliation owner exists. |
| External ID / upsert key | Links source rows to the intended target record. | Validate uniqueness and retention of the key before the first production load. |
| Validation rules and required fields | Protect data completeness and process integrity. | Decide whether to remediate source data, use approved migration-only logic, or exclude the record from the wave. |
The matrix should be reviewed by both the CRM administrator and the business owner for the object being migrated. A change that is technically safe can still create an operational problem if sales, service, or marketing relies on the affected fields immediately after launch.
Before importing, measure duplicates inside the source extract. Look for repeated emails, phone numbers, external IDs, account numbers, names with spacing or punctuation differences, and rows with blank matching fields. The aim is not perfect data. The aim is to know which conditions are common enough to need a rule.
List active matching rules, duplicate rules, validation rules, flows, triggers, and integrations that touch the object. Record whether each control blocks, warns, updates data, sends notifications, or creates related records. A migration can appear to fail on a duplicate rule while a downstream automation is also altering the data.
Choose the order of evidence used to identify an existing record. A stable external ID may be strongest. A verified email may be useful for some records but unsuitable for shared inboxes. Names and addresses can support review but are rarely strong enough on their own. Write down which combinations qualify for automatic update, manual review, or new-record creation.
Apply approved transformations consistently: trim spaces, standardize capitalization where appropriate, separate first and last names, normalize phone formats, remove obvious test data, and validate country or state values. Do not overwrite source values without retaining traceability. Preserve the original values in a staging file and document every transformation.
Use a representative sample that includes clean records, known matches, likely duplicates, incomplete records, and different ownership conditions. Reconcile each result. The goal is to discover edge cases before the number of rows makes investigation expensive.
Every blocked or ambiguous record should land in a reviewable list with the source row, target candidate, reason, proposed disposition, and owner. Typical dispositions are: update the existing record, merge records, create as new, correct source data, or defer. This turns migration exceptions into a governed decision process.
After each batch, compare source count, attempted count, inserted count, updated count, rejected count, and unresolved exceptions. Also validate business totals that matter: active customers, eligible contacts, open opportunities, consent states, or other meaningful population measures. A load is not complete because the tool returned “success.” It is complete when the business can explain the difference between the source and the destination.
There are cases where a narrow, time-boxed change is reasonable. For example, a rule may generate predictable false positives because the migration is loading records into a new model. If you choose that path, define the specific object, time window, user or integration account, rule change, approval owner, rollback time, and post-load reconciliation. Never leave a migration exception as an undocumented permanent weakening of your data controls.
In many cases, a staging approach is safer than changing production behavior. Clean and classify data in a controlled location, load only decisions that meet the match hierarchy, and use an exception queue for the rest. This is slower than bypassing every check for one afternoon. It is much faster than resolving thousands of duplicate records after sales and marketing have started using them.
A source system is not the authority on whether a target record exists. Use the target CRM and approved matching logic to decide whether the correct action is insert, update, merge, or review.
Shared addresses, recycled addresses, family or role-based mailboxes, and incomplete source data make email an imperfect identity key. Use it as evidence within an intentional hierarchy, not as an unquestioned universal key.
Once duplicate records enter workflows, lists, assignments, and reports, cleanup is no longer a one-time data task. It becomes an operational disruption. Build cleanup into the load process instead.
Schedule a migration-control review before the next production load. Bring the source-data owner, CRM administrator, integration owner, and business owner for the affected process. Agree on the match hierarchy, exception queue, pilot sample, reconciliation report, and rollback criteria.
For CRM programs that must move data across several systems, Vantage Point can help establish the technical and operating controls that turn a load into a reliable migration. Explore our system integration and data migration services, CRM and marketing automation services, and compliance and security solutions.
Vantage Point helps organizations plan migrations that respect both data quality and delivery timelines. Our senior consultants inventory controls, design mapping and matching rules, manage staged loads, document exceptions, and reconcile results with the people who rely on the data. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If duplicate rules are blocking your CRM migration—or you are worried that disabling them will create a cleanup problem—Vantage Point can help build a practical runbook. Contact Vantage Point for a data-migration assessment or explore our integration and migration services.
Duplicate rules block a data load when an active matching rule identifies an incoming record as a potential match with an existing record. The block is a signal to determine whether the row should update, merge with, or be reviewed against the existing record.
Do not disable duplicate rules as a default response. If a narrow, time-boxed change is approved, document the object, user, rule, reason, rollback time, and reconciliation plan so the exception does not become a permanent data-quality gap.
A stable external ID is often the strongest key when it is present and unique in both systems. Email, phone, name, and address can help with matching, but each has limits and should be used within a documented match hierarchy.
Blocked records should enter an exception queue with the source row, target candidate, reason, proposed disposition, and accountable owner. Common outcomes are update, merge, create as new, correct the source data, or defer for business review.
Compare source, attempted, inserted, updated, rejected, and unresolved-exception counts after every load wave. Also validate business totals that matter, such as active customers, consent states, open records, or other population measures.
Yes. A technical success message only confirms that the tool completed its operation. Business reconciliation is still required to confirm that records, associations, ownership, and key metrics are correct and explainable.