Connected work
Two records with the same company name are not always duplicates
Define what identifies the business record before merging information during a migration.
An import finds two company names that look identical. One is a separate branch; the other is an older spelling of the same organisation. Treating both cases as a simple duplicate can damage the history staff rely on.
Identify the thing being represented
For a fictional Estonian supplier, distinguish a legal customer, a delivery location, a contact person and an opportunity to do work. They may share a name without being interchangeable records. Ask the team what each existing identifier means and which system owns it.
Do not merge on a name alone. Spaces, punctuation and spelling can vary, while the same display name may legitimately belong to different records. A sensible matching proposal still needs a review path for uncertainty.
Make proposed merges inspectable
Show the source records, the reason for the proposed match and the consequences for linked work. A reviewer should see whether addresses, notes or active requests would be combined. Keep an unresolved case visible rather than selecting a plausible answer silently.
W3C's table guidance helps present relationships and headers clearly in that review. It does not supply the business's identity rules; those come from understanding the actual records.
Check the history after a test import
Find a fictional delivery, an older request and a current contact using the proposed new records. Confirm that each still points to the intended organisation or location. Count deliberate splits and merges separately instead of expecting every row count to remain unchanged.
A data connection or migration project should include these decisions and a way to reconcile the result. A clean import report is useful only when the team can still explain its business history.
Further reading: W3C guidance on clear data relationships.