The short answer
Resolve migration duplicates by assigning every source record a stable identity, comparing type-specific evidence, classifying the pair as same, related, different, or unresolved, and preserving a crosswalk from every source ID to the target disposition. Never merge solely on name, email, address, or a similarity score.
Key takeaways
- Exact field matches can still represent different entities.
- Keep relationship and identity as separate decisions.
- Preserve source IDs and the merge/split rationale.
Generate candidates without making the decision
Candidate rules can use normalized names, addresses, contact details, tax or provider tokens, unit relationships, bank tokens, vendor documentation, or source-system links according to data sensitivity and policy. Restrict access to sensitive identifiers and avoid copying them into general migration notes.
A fuzzy match or automated score may prioritize review, but it should not silently combine records with financial, tenancy, access, or communication histories.
Use type-specific evidence and four outcomes
Compare the facts that define the record type. A property needs governed address and ownership relationships; a unit needs property and unit identity; a vendor needs business identity and service relationship; a person may have several legitimate roles or contact records.
| Outcome | Meaning | Target disposition |
|---|---|---|
| Same identity | Evidence supports one real-world object | One target ID; all source IDs crosswalked |
| Related identities | Records are connected but must remain distinct | Separate target IDs plus explicit relationship |
| Different identities | Similarity is coincidental or insufficient | Keep separate; suppress repeated candidate if justified |
| Unresolved | Evidence is missing or conflicting | Hold merge; assign owner and operational safeguard |
Review what a merge would combine
Before executing, compare balances, leases, payments, documents, work orders, communication preferences, permissions, tax records, and vendor/payment destinations as relevant. Decide how field conflicts and child records will be retained, and test the target’s ability to undo or correct the merge.
After migration, sample crosswalks and search for orphaned child records or one source ID mapped to several active targets. Preserve the rationale and reviewer rather than leaving only the final target row.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Every source record has stable ID
☐
Candidate rule and sensitivity controls documented
☐
Record-type identity evidence compared
☐
Same/related/different/unresolved outcome recorded
☐
Downstream histories reviewed before merge
☐
Crosswalk retains all source IDs
☐
Post-import orphan and split checks completed
0 of 7 marked
Edge cases
- One person is both owner and vendor: preserve role-specific records and permissions even if identity is shared.
- A property address changed format: normalization helps matching but does not prove ownership continuity.
- Two vendors share a payment destination: investigate; do not merge from bank token alone.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
Continue the workflow
PMS migration rejected-record registerPMS migration acceptance criteriaPMS migration delta capture after the source freezeRevision history
2026-09-18
Initial Phase 3 operational article with a distinct decision artifact, failure states, source-scope notes, and AI-assisted technical review.