How to Leave a Legacy Matching Vendor Without Losing Match History (2026)

TL;DR: Preserve match history as a governed decision ledger, not as a dump of old entity IDs. Export source record identities, rule versions, evidence, overrides and effective dates. Run the old and new resolvers in parallel, reconcile material differences, then cut over with lineage, rollback and downstream mappings intact.

Book a Demo or Try Tilores Studio (Free).

On this page

1. What must be preserved?
2. How do you capture match history?
3. How should old and new decisions be mapped?
4. How do you test the replacement?
5. What does a controlled cutover look like?
6. How does Tilores fit the migration?
7. What evidence does governance need?
8. When is the migration complete?
9. Frequently asked questions

What must be preserved when you replace a matching vendor?

Preserve the evidence needed to explain both the old decision and the transition to the new one. A successful migration does not require the replacement engine to reproduce every legacy entity exactly. It requires the bank to identify which relationships changed, why they changed, who approved the change and which downstream references must follow it.

Start by separating three identities. A stable source record ID identifies an input inside a declared source namespace. For comparison, the data snapshots must be frozen, timestamped and hashed. A legacy entity ID identifies a grouping produced by the old resolver at a particular time. A business identifier belongs to an account, case, payment or other object that must not be rewritten merely because customer records are regrouped.

The minimum history ledger for a defensible migration

History element	What to retain	Why it matters
Source identity	Source system, source record ID and ingestion time	Lets both engines evaluate the same input population
Legacy entity state	Entity ID, member records and effective interval	Reconstructs what downstream users saw at a given time
Decision evidence	Rules, scores, compared fields and blocking path where available	Explains why records were linked or kept apart
Configuration	Normalisation, indexes, rule versions, thresholds and reference data	Connects an outcome to the decision policy that created it
Human intervention	Override, reviewer, reason, timestamp and scope	Prevents reviewed decisions from disappearing in bulk replay
Consumer references	Systems and objects that store an entity ID	Shows where aliases or remapping are required
Screening context	Sanctions, PEP and adverse media list versions and review outcomes	Keeps compliance decisions attached to the identity state used at the time

Do not confuse an exportable entity table with match history. A snapshot shows the grouping at one moment. History also needs the decision policy, effective time, source lineage and subsequent merges, splits or overrides.

How do you capture match history before the legacy contract ends?

Capture history before changing rules, identifiers or source mappings. The safest extraction is frozen, timestamped, hashed, repeatable and reconciled against the legacy service while access and subject matter expertise are still available.

1. Freeze the scope. Name the source systems, record population, extraction time and legacy configuration used for the baseline.
2. Export raw source records. Preserve source namespaces and record IDs. Hash each extract and record its row count.
3. Export resolved membership. Record every legacy entity and its member records, including entities with only one member.
4. Export decision evidence. Retain rules, scores, thresholds, candidate-generation paths and manual dispositions where the old platform exposes them.
5. Inventory downstream use. Find every application, report, case store and screening workflow that persists or exchanges a legacy entity ID.
6. Reconcile the package. Confirm that every exported member record exists in the source extract, every referenced rule belongs to the frozen configuration and every downstream identifier has an owner.

Where the old service cannot export part of this history, record the limitation explicitly. Do not manufacture a rule explanation from a score, or infer a reviewer decision from the final grouping. Missing evidence is a migration risk to manage, not a gap to fill with confidence.

How should old and new match decisions be mapped?

Map outcomes through source records, not by forcing legacy entity IDs onto new entities. The old and new systems may use different clustering behaviour, tie-breaks or update order. Source record membership is the common comparison layer.

Create an old-to-new mapping with four result types: unchanged, merge, split and mixed. An unchanged result has the same source membership. A merge maps several old groups into one new group. A split maps one old group into several new groups. A mixed result combines both patterns and needs case-level review.

Keep the legacy entity ID as an alias with an effective interval and resolution status. Consumers that only need the current view can resolve the alias to the current canonical entity. Audit, complaints, screening and historical analytics may need the entity state that was effective when the original decision occurred.

This distinction matters because entity IDs are not eternal business keys. Re-ingesting the same record will not restore the previous entity ID. Design the migration contract around stable source record IDs, frozen, timestamped and hashed baseline snapshots, alias mappings and time-aware lineage instead.

How do you test a replacement without preserving legacy errors?

Use the old output as a comparison baseline, not as unquestioned truth. A replacement that copies every historical decision can preserve false merges, missed matches and undocumented overrides. A replacement that ignores history can break customer journeys and erase prior review work.

Build a labelled evaluation set from several strata: high-value customers, densely connected entities, prior manual reviews, known false positives, known false negatives, recent source changes and records used in sanctions, PEP and adverse media screening. Add random samples so the test does not consist only of exceptional cases.

Run both systems on the same frozen data. Compare pair decisions, entity membership and downstream effects. For each material delta, classify the reason as configuration translation, data preparation, method difference, update-order effect, missing legacy evidence or a likely correction. The review team should approve the class and consequence, not merely the percentage agreement.

The Basel Committee describes end-to-end data lineage as important for confirming data quality. That makes lineage a practical acceptance criterion: a reviewer should be able to move from a changed entity back to its source records, transformation version, rule evidence and approval.

External lists change independently of the resolver. OpenSanctions brings official sanctions lists and PEP data into one dataset ecosystem. Record the exact list version used in each replay, and preserve adverse media provider versions separately, so a list update is not mistaken for a matching-engine difference.

What does a controlled cutover look like in 2026?

A controlled cutover promotes evidence in stages. It keeps the legacy service available as a reference until the new path, downstream mappings and rollback procedure have all been exercised.

1. Freeze and sign the baseline. Hash the source extract, legacy membership, configuration, overrides and downstream reference inventory.
2. Configure the replacement. Translate intent rather than syntax. Document any legacy rule that cannot be reproduced exactly and the approved alternative.
3. Replay historical data. Load the frozen population using stable source record IDs, then retain the resulting entity membership and decision evidence.
4. Run in parallel. Feed equivalent changes to both systems and reconcile material merge, split and no-match differences.
5. Prove consumer compatibility. Test aliases, current entity lookup, as-of history, deletion, correction, screening, case management and reporting.
6. Cut over a bounded cohort. Move a controlled source, region or workload first. Monitor decision deltas and operational health against explicit stop conditions.
7. Complete and decommission. Promote the new resolver only after rollback has been rehearsed, evidence has been approved and the legacy retention plan has been executed.

Rollback must restore more than application routing. Define which configuration, entity state, alias map, queued changes and consumer checkpoints will be restored. Also define how changes received during rollback will be replayed without duplicating or losing them.

How does Tilores fit a history-preserving migration?

Tilores uses deterministic, fuzzy and probabilistic matching as separate methods. That separation lets a migration team identify whether a changed outcome came from an exact rule, a similarity comparison or a probabilistic decision, then test each method against labelled cases.

Tilores normalises and persists data while retaining originals. Preserve the source record ID and source namespace when ingesting the migration population, then compare new entity membership with the signed legacy baseline. Production consumers query Tilores through GraphQL, not REST.

Rule migration and historical replay are separate operations. Existing data is not updated automatically when new matching rules are added. Applying a new configuration to history therefore requires a controlled re-ingestion of the same records using their original record IDs, with its own scope, reconciliation and approval.

Use the entity event stream to build the transition ledger. Every single data change in Tilores is published via the entity event stream. Consume those events idempotently, retain effective times and map obsolete or changed entities before downstream systems adopt the new identifier.

The wider entity resolution rollout sequence covers source preparation, labelled truth and parallel running. The stable ID design explains why downstream consumers need aliases and lifecycle handling rather than a promise that an entity ID can never change.

What evidence does procurement, risk and audit need?

The migration pack should contain the approved scope, contractual exit dependencies, signed extracts, configuration versions, delta results, reviewer decisions, cutover plan, rollback proof, access changes, retention decisions and final reconciliation. Give each item an owner and immutable identifier.

Whether a particular matching service supports a critical or important function is a bank-specific legal and risk determination. The migration evidence should be usable in that assessment and in any applicable exit-planning review.

US interagency guidance asks banks to plan how an activity would move to another provider or back in-house. It also places termination inside the third-party risk-management lifecycle. A bank should apply the guidance in proportion to its circumstances and supervisory scope.

These sources do not prescribe a particular entity-resolution architecture. They do make continuity, documentation and tested transition important governance concerns. Legal and compliance teams should determine the obligations that apply to the bank and the service.

When is the legacy matching migration complete?

The migration is complete when the bank can explain current and historical identity decisions without querying the retired service. Every legacy entity reference must resolve to a current entity, a time-bound historical state or a documented exception.

Completion also requires downstream owners to accept their mappings, reviewed overrides to be carried forward or deliberately retired, screening workflows to reconcile, access to be removed, retained data to have an owner and rollback to have reached its agreed expiry point.

A lower infrastructure bill or a successful bulk import is not enough. The real acceptance test is whether operations, risk and audit can reconstruct what changed and continue the bank’s work safely after the old platform is unavailable.

Frequently asked questions

Should we copy legacy entity IDs into the new matcher?

No. Preserve legacy entity IDs as aliases and historical references. Use stable source record IDs and frozen, timestamped and hashed baseline snapshots to compare membership, then map each legacy entity to the current entity or documented exception.

Can the new resolver use the old matches as labelled truth?

Only after review. Legacy decisions are valuable evidence, but they may include outdated rules, false links or unexplained manual overrides. Sample and label them before treating them as acceptance truth.

How long should old and new matching systems run in parallel?

Run them until the agreed risk cases and operational cycles have been observed. The period should be set by source frequency, customer impact, screening use and rollback needs, not by a universal number of days.

Will stable source record IDs keep entity IDs unchanged?

No. Stable source record IDs make outcomes traceable, but entity membership and entity IDs can change after merges, splits, deletion or rule changes. Consumers need alias and lifecycle handling.

What should happen to sanctions, PEP and adverse media history?

Keep it linked to the identity state and list version used for the original decision. During replay, distinguish a changed external list from a changed match, and route material differences through the bank’s established review process.

Sources

1. Interagency Guidance on Third-Party Relationships, US Federal Reserve
2. Implementation of the BCBS 239 principles for risk data aggregation and risk reporting, Basel Committee on Banking Supervision
3. OpenSanctions: sanctions and PEP data ecosystem
4. Tilores FAQ: rules, replay and the entity event stream
5. Tilores API documentation
6. What an Entity Resolution Rollout Actually Looks Like in 2026, End to End, Tilores
7. How to Handle Entity Merges, Splits and Stable IDs Downstream (2026), Tilores