Replacing an AML system is not a normal application migration. The existing platform may contain years of customer records, due-diligence decisions, whitelists, risk ratings, monitoring history, rules, alerts and evidence. A technically successful cutover can still weaken the control if that history or logic is lost.
Start with a control inventory, not a data export
Document what the existing system actually does. Separate customer screening, transaction monitoring, customer risk assessment, ongoing monitoring, investigation, reporting and integrations. For each control, record who owns it, which data it uses, how it is configured and what evidence it produces.
Inventory the rules and settings
Capture matching thresholds, list selections, customer-risk logic, monitoring settings, transaction scenarios, whitelists, escalation rules, user roles and reporting definitions. Do not assume configuration can be translated directly between products; the underlying logic may differ.
Classify historical data
| Data | Migration decision |
|---|---|
| Customer/entity master references | Usually required to preserve linkage and ongoing monitoring. |
| Screening and due-diligence decisions | Assess legal, audit and operational retention needs. |
| Risk assessments | Determine whether historical scores and rationale must be retained or recalculated. |
| Alerts/cases | Decide what remains open, what is migrated and what is archived read-only. |
| Supporting documents | Define secure transfer, retention and access requirements. |
| Configuration/audit history | Preserve enough evidence to explain the old control and the transition. |
Clean the data before migration
A system replacement is an opportunity to resolve duplicate customer identifiers, incomplete fields and inconsistent ownership data. However, cleansing decisions should be controlled and documented. Do not silently “fix” data in a way that makes historical decisions impossible to reproduce.
Re-baseline the control rather than cloning it blindly
A legacy rule may exist because of an old product limitation rather than because it remains the best control. Use the replacement to confirm whether the risk, data and regulatory context still justify the logic. Where a control changes, document why and how the new approach will be tested.
Create a migration governance structure
Assign named owners for customer data, configuration, open investigations, integrations, testing, business readiness and historical evidence. Migration decisions often cross compliance, technology, operations, privacy, records management and procurement; a single project plan without control owners is not enough.
Maintain a migration decision log for items that are transformed rather than copied. Examples include a rule that is retired, a risk factor that is recalibrated, a whitelist that is not migrated, or a historical field that is archived outside the new platform. Record the rationale and approver so the future control state can be explained.
Use parallel testing where the risk justifies it
Run representative customers or transactions through both environments and compare outputs. The goal is not necessarily identical results: different engines may behave differently. The institution needs to understand material differences and determine which behaviour is appropriate.
Define acceptance criteria before testing
- Required customer and entity records are migrated or retrievable.
- Priority scenarios and screening use cases produce understood results.
- Open investigations have an agreed destination.
- Users can reproduce required reports and evidence.
- Integrations are reconciled end to end.
- Access controls and roles are tested.
- Operational staff can perform the new process without undocumented workarounds.
Decide what “equivalent” means
A replacement engine may not produce exactly the same match or alert set as the legacy platform. Define where equivalence is required and where changed behaviour is acceptable. The objective is not to reproduce every historical false positive; it is to preserve or improve the intended control while understanding material differences.
For key controls, agree reconciliation thresholds and escalation routes before testing. If the new system detects materially fewer or more events, require a documented explanation rather than treating the difference as automatically good or bad.
Plan the cutover and rollback
Define the freeze window, final data delta, ownership of production checks, incident escalation and rollback criteria. For controls that operate continuously, the institution should know exactly which system is authoritative at each point in the cutover.
Do not decommission the old system too early
Historical evidence may need to remain accessible even if the legacy system stops processing new activity. Decide whether data will be migrated, archived or retained in read-only form and confirm how auditors or investigators will retrieve it later.
MemberCheck migration considerations
MemberCheck supports unique client identifiers, due-diligence decisions, ongoing monitoring, reporting and API access across individual and corporate screening workflows. When assessing a migration, map the legacy system’s records and processes to the MemberCheck data and workflow model rather than assuming a one-to-one field conversion.
Use the migration inventory to identify which legacy controls and evidence can move to MemberCheck and which require integration or archival.
