Check duplicate customers before a data migration

Before migrating data, establish which records represent the same customer. A matching company name is a search clue, not sufficient evidence of identity. A new address may belong to an existing customer; two companies with the same name may remain separate customers.

Microsoft Dataverse distinguishes potential duplicates from subsequently merging them. Which fields trigger a match depends on the configured rules. Similarity search therefore does not replace your business decision about the mapping.

Distinguish three records with verified identities

This example is entirely fictional. All three source records use the name Beispiel Technik GmbH. Their organisation references have already been verified for this example; they are not official identifiers. The move of the organisation at the old Nordweg address to Parkweg has also been confirmed. The table sets out expected migration decisions, not results of an executed import.

The first two rows stay separate despite the same name. The first and third belong together despite different addresses. In the example, Parkweg 6 becomes the current address for customer K-900. This must not silently change a previous delivery address on an existing order.

Record evidence and unresolved cases before import

Have the mapping checked against suitable identity evidence accepted within the project. Reliable references and traceable master-data documentation may support it. The identifiers in the table represent the result of that check. They must not simply be derived from the similar name.

Without reliable evidence, the mapping stays unresolved. Record possible matches, the reason for clarification and the responsible role. Creating a new record needs a confirmed decision about the customer; it must not bypass missing identity checks. Merging can also affect related records, so check the particular product function before using it.

Keep using the confirmed mapping

Store the source-to-target link so a later transfer recognises the same record. In our design, (sourceSystem, sourceId) is the unique source reference. It is linked to the confirmed target identifier. The field names describe our example, not the Dataverse API.

Dataverse documents alternate keys built from a unique combination of column values. Establish which keys and restrictions your systems actually support during the technical assessment. A mapping list alone does not enforce uniqueness in the target.

Check repetition and relationships as well

Transfer the example data into a suitable test environment first. Check the two separate target customers, the shared mapping for the organisation that moved and its current address. Then submit the same source references again: no additional customer should be created.

Also check which target customer the transferred orders refer to and whether historical document addresses remain intact. If a confirmed mapping changes later, assess its effects on existing links separately.

Sources

• Microsoft — Detect duplicate records and merge

• Microsoft — Define alternate keys