“John Smith,” “J. Smith,” and “Smith, John (Unit 4B)” can be three database rows and one person. “ABC Plumbing,” “A.B.C. Plumbing LLC,” and “ABC Plumbing — Emergency Line” can be three vendor profiles and one company.
Years of staff changes, acquisitions, inconsistent data-entry rules, and system limitations create identity drift. The rows are individually valid, so a conventional migration moves them exactly as it finds them.
That is the problem. A technically faithful copy can reproduce an operationally false view of the customer’s residents, vendors, and history.
Duplicate records fracture the history around them
A duplicate is rarely just an extra name in a dropdown. Each profile accumulates relationships: leases, ledger entries, work orders, screening results, documents, tax details, phone numbers, and prior addresses.
Every source row can arrive while the real-world identity remains incomplete.
A property manager viewing only the active profile may miss late fees stored against an older resident ID. An accounts-payable team may have vendor activity split across multiple tax records. A maintenance team may lose the connection between an active resident and prior work orders.
Exact matching cannot resolve real identities
Exact matching finds identical strings. Entity resolution evaluates whether different records refer to the same real-world person or organization. It combines multiple signals rather than trusting one field.
| Method | Evidence used | What it catches | Main risk |
|---|---|---|---|
| Exact match | Identical name, email, ID, or phone | Literal duplicates | Misses formatting changes, aliases, and typos |
| Fuzzy name match | String similarity and name normalization | Initials, transpositions, punctuation, spelling drift | Can merge different people with common names |
| Multi-signal matching | Name plus contacts, address, unit, stable identifiers, and dates | Records supported by several independent clues | Requires weighting and conflict rules |
| Relationship-aware resolution | Linked leases, bank details, emergency contacts, properties, and work orders | Identity continuity across connected records | Shared household or business data can create false confidence |
A match score is not permission to merge
AI and fuzzy matching are useful for finding candidate pairs that a person would never review manually. They should not collapse records based on similarity alone.
Two residents can share a name and address. A family can share a phone number. Vendors can share a service address while remaining separate legal entities. Even exact identifiers may be unreliable when a source system contains copied placeholder values.
A reliable process uses confidence tiers:
- Strong evidence: approved deterministic rules can consolidate records when stable identifiers and supporting context agree.
- Possible match: a reviewer sees the proposed pair, supporting signals, conflicting fields, and downstream relationships.
- Conflict: records remain separate until the discrepancy is resolved.
The merge plan must include every dependent record
Choosing a surviving resident or vendor ID is only the beginning. The migration must decide what happens to every relationship attached to the duplicate records.
For a resident, that can include leases, charges, payments, deposits, work orders, communications, screening results, documents, household members, and historical unit assignments. For a vendor, it can include invoices, payments, properties served, tax information, insurance documents, contracts, and contact channels.
The merge should preserve source IDs and produce a crosswalk showing which source profile contributed each target relationship. If two records contain conflicting legal names, tax IDs, balances, or lease terms, the pipeline should hold the consolidation rather than choose the most recent value automatically.
Golden records need lineage
A “golden record” is useful only if the team can explain how it was assembled. The final record should show:
- All source IDs included in the consolidation.
- The evidence used to identify the match.
- Which field value survived and why.
- Which related records were reassigned.
- Which conflicts required review or a customer decision.
- Who approved the merge and when.
This turns deduplication from an irreversible cleanup script into a reviewable migration decision.
Deduplicate before the target becomes the system of record
Cleaning identities after go-live is harder. The target may limit bulk merges, new activity may already be accumulating against duplicate profiles, and integrations may have copied the bad IDs downstream.
Staging resolution before load gives the team a controlled place to normalize values, generate candidate groups, inspect conflicts, and test relationship counts. The target receives approved records and a complete mapping from legacy IDs to target IDs.
A clean start should not erase ambiguity
The goal is not to produce the smallest possible resident or vendor list. Aggressive consolidation can be more damaging than leaving a duplicate in place. The goal is to identify likely duplicates, apply approved deterministic rules where evidence is strong, and make uncertain cases visible.
Elvity’s PropTech data onboarding platform profiles source identities, normalizes comparison fields, groups candidate duplicates, preserves relationship context, and records the evidence behind approved merge decisions. AI narrows the review queue; it does not make ambiguous identities disappear.
A new PMS should start with a clearer view of the customer’s business—not a cleaner-looking list built on unsafe assumptions.
Resolve identities before they reach the target
See how Elvity finds candidate duplicates, preserves relationship history, and keeps every merge decision reviewable.