This guide is for organisations already operating sanctions-screening software and replacing or materially changing that system. If the question is which product to buy, start with how to choose sanctions-screening software.
The migration question is different:
Can we move from the incumbent control to the approved target state without losing screening coverage, monitoring continuity, investigation context or evidence?
FCA supervisory findings provide UK-regulated examples of why this matters: historic vendor settings may persist without adequate challenge, transfers between systems can introduce data errors, and failed legacy integrations can leave activity unscreened.1 These are supervisory findings, not a universal migration method.
Treat the switch as a control change
A new platform can pass a procurement proof of concept and still fail after deployment because the organisation mapped the wrong fields, omitted a population, changed matching behaviour unintentionally, lost monitoring enrolments or could no longer reconstruct older decisions. The migration must therefore cover the compliance control, data and configuration, operations and evidence, and technical continuity—not just application deployment.
For firms within FCA SYSC 8 scope, outsourcing rules retain responsibility with the firm and address oversight, access, continuity and termination.2 That is a scoped UK regulatory example, not a rule for every organisation worldwide.
Establish the approved current-state baseline
Document what the incumbent system actually does before designing the transfer. Do not infer current state from the contract or a generic vendor description.
Record:
- applicable screening perimeter and approved official sources;
- customers, companies, owners, counterparties or other populations entering the control;
- onboarding, payment, change and re-screening events;
- persistent subject identifiers and the systems that own them;
- fields sent to screening and transformations applied before matching;
- matching configuration, exclusions and decision states;
- API, batch, portal, queue and monitoring dependencies;
- evidence retained for screening runs and investigations.
Use the practical sanctions-screening guide if the underlying scope itself needs reassessment. The migration guide assumes the organisation has an accountable owner for that legal and operational perimeter.
Build a legacy-to-target control map
Map each current-state element to an approved target-state treatment. “Supported by both vendors” is not enough: equivalent labels or threshold numbers can produce different behaviour.
| Control element | Migration decision | Evidence before cutover |
|---|---|---|
| Sources and programmes | Map incumbent records and update paths to current target sources | Source inventory, identifiers, versions and update test |
| Subject records | Preserve stable internal IDs and define field transformations | Export counts, rejected records and field-level reconciliation |
| Matching configuration | Approve non-equivalent settings rather than copying numbers | Baseline, target configuration and representative comparison |
| Prior non-match decisions | Revalidate, migrate where supported, archive or deliberately retire | Decision rule, owner, sample review and exception record |
| Open alerts and cases | Complete in the incumbent, recreate in the target or retain with controlled access | Case inventory, status reconciliation and retrieval test |
| Monitoring enrolments | Account for every subject and relevant source in the target | Before-and-after population and source reconciliation |
| Interfaces and queues | Map producers, consumers, errors, retries and reconciliation | End-to-end test and named failure owner |
| Historical evidence | Retain or export enough context to reconstruct past activity | Retrieval test, retention basis and post-termination access plan |
Stable internal identifiers matter. A mutable name string is not a safe join key for connecting an exported subject to its monitoring status, prior decisions and case history.
Do not copy old decisions blindly
A previous false-positive decision or suppression was made using particular source data, identifiers, matching behaviour and reviewer evidence. A replacement engine may cluster records differently, expose different identifiers or use another decision model.
Choose an approved treatment for each decision class: revalidate, migrate where the target supports an equivalent controlled state, retain as historical evidence, or retire with a documented reason. Detailed suppression and threshold design remains with the guide to reducing sanctions-screening false positives.
Open investigations need an explicit owner. Do not let a case disappear because the incumbent stops accepting work before the target is ready. Decide whether each case will be completed in the old system, recreated in the new workflow or retained read-only under the organisation's approved evidence plan.
Protect ongoing monitoring through cutover
Reconcile the monitored population, persistent IDs, enabled sources and last successful screening point. Record the final successful incumbent event and first successful target event, account for source changes between them, define how failed or duplicate records will be reconciled and name who can pause cutover when counts do not agree.
Ongoing monitoring is a target-state capability, not proof that the transition was complete.
Test migration acceptance and unexplained differences
Use production-representative data and known expected cases to test sources, mapping, matching, routing, monitoring enrolment, error handling and retained evidence. The production-control testing section explains the wider testing job; the migration plan should concentrate on old-to-new differences.
Compare results by class rather than hiding them inside one overall “accuracy” percentage:
- expected candidates returned or missed;
- clean or known non-matches that create new review work;
- records rejected, truncated or transformed differently;
- prior decisions that no longer apply cleanly;
- monitored subjects or sources missing from either side;
- alerts and cases routed to the wrong queue;
- evidence that cannot be reconstructed.
A parallel run can help expose differences where it is proportionate and technically meaningful, but it is not universally required and needs no arbitrary fixed duration. Investigate unexplained deltas: the objective is not to force both systems to produce identical output.
Control cutover, rollback and incidents
Define acceptance authority, unresolved exceptions, cutover sequence and the last point at which rollback remains safe. Assign owners for integration failures, source-feed issues, rejected records, monitoring gaps, queue failures and evidence problems.
A useful cutover record identifies:
- the approved configuration and source state;
- reconciled subject and monitoring counts;
- open exceptions and compensating controls;
- the final incumbent and first target processing points;
- accountable approval, timestamp and rollback criteria;
- post-cutover checks and any required backfill.
Do not promise zero downtime when the real control objective is detectable, reconciled continuity.
Close the incumbent without losing evidence
Before termination, confirm what can be exported, in which format, until when and with which supporting metadata. Test access to historical screening runs, cases, attachments and rationale after the operational cutover.
Retention depends on applicable legal, regulatory, contractual and internal requirements. There is no universal sanctions-screening retention period. Record where evidence will remain, who can retrieve it, how open investigations will be supported, and what deletion or return evidence is contractually required.
The alert-investigation guide explains the evidence needed to connect a candidate to identity, ownership/control analysis and final action. Migration must preserve that separation; importing a status label alone is not enough.
Where Checklynx fits
After defining the target state and acceptance criteria, assess whether Checklynx sanctions screening fits the approved migration plan. Checklynx supports screening through portal, CSV/batch and real-time API workflows, with configured monitoring, case review and audit evidence.
Checklynx provides migration planning and implementation assistance at no additional charge. The work is scoped to the incumbent system, available exports, required integrations and the agreed implementation plan.
Those capabilities do not mean Checklynx automatically converts every incumbent export, reproduces another engine's behaviour, imports every historical case or guarantees uninterrupted migration. The customer remains responsible for its perimeter, data mapping, acceptance, legal analysis and authorised decisions.
Frequently asked questions
How is switching sanctions-screening software different from selecting a vendor?
Selection defines and evaluates the future solution. Migration controls the move from an existing production system to that approved target without losing populations, monitoring, decisions or evidence. The jobs should link to each other but not duplicate each other.
Should old and new sanctions-screening systems run in parallel?
Parallel running can be useful where it is proportionate and the outputs can be reconciled meaningfully. It is not a universal regulatory requirement, and identical results should not be expected from non-equivalent engines. Define the purpose, acceptance criteria, exception ownership and stopping condition.
Can previous false-positive decisions be imported into the new system?
Possibly, if the target supports an equivalent controlled state and the decision remains defensible against the relevant source, identity evidence and matching context. Do not copy suppressions blindly. Revalidate, migrate, archive or retire each class under an approved rule.
What happens to open sanctions alerts during migration?
Assign every open alert or case a destination before cutover: complete it in the incumbent, recreate it in the target where supported, or retain it with controlled access and an accountable owner. Reconcile the inventory after the move.
Does a successful migration validate the sanctions programme?
No. Migration acceptance can show that defined populations, sources, integrations and workflows moved as intended. It does not prove identity, ownership/control, legal nexus, licensing, reporting or every final sanctions decision.
Official sources
Footnotes
-
Financial Conduct Authority, Sanctions systems and controls: our firms, our findings, UK supervisory findings covering system configuration, data transfer, integration, testing and vendor challenge, published 28 May 2026, accessed 10 September 2026. ↩
-
Financial Conduct Authority, SYSC 8.1: General outsourcing requirements, rules and guidance for firms within the applicable FCA scope covering retained responsibility, oversight, access, continuity and termination, accessed 10 September 2026. ↩