Turning off an old banking system is not simply a technology upgrade. The platform may contain official records, feed other processes, support customer service and preserve evidence the bank must still be able to retrieve.
The bank maps what the system actually does
Teams identify the products, accounts, interfaces, reports, users, controls and end-of-day jobs that depend on the system. An application that appears inactive may still supply a reconciliation, regulatory report, archive lookup or downstream data feed.
Ownership matters because technology staff may understand the platform while business, operations, finance, legal and risk teams understand the records and obligations it supports. A complete inventory links both views before a retirement date is approved.
Data is classified before it is moved or archived
The bank decides which data must enter the replacement system, which can remain in a controlled archive and which may be disposed of under approved retention rules. Definitions, history, relationships and source identifiers should remain understandable after the original application is gone.
Migration rules translate fields and formats between systems. Data lineage and exception records explain how values changed, while privacy, legal-hold and record-retention requirements govern what may be removed and what must remain accessible.
Reconciliation proves more than a successful file transfer
Control totals, balances, record counts and representative account histories are compared before and after migration. Teams test calculations, statements, fees, interest, reporting and interfaces so a value that arrived in the new database is also being interpreted correctly.
Exceptions are researched and resolved with evidence. Material differences should not be hidden inside a broad tolerance, and reconciliation should cover the customer, accounting and operational views that rely on the data.
Cutover includes continuity and a bounded fallback
A bank may run systems in parallel, migrate by product or use a controlled cutover window. Readiness criteria define who can approve the change, which open defects are acceptable and how customers, employees and third parties will be supported.
A rollback or contingency plan needs a clear decision point and reliable data. Leaving two systems writable for too long can create conflicting records, so fallback arrangements should be tested, time-bound and designed around one authoritative source at each stage.
Decommissioning removes access without erasing accountability
After validation, the bank disables interfaces, scheduled jobs, user access, service accounts, certificates and vendor connections. Hardware and storage are sanitized or disposed of according to the sensitivity of the data and the approved method.
Archived information still needs tested retrieval, access controls and an owner. Final evidence records approvals, reconciliations, unresolved obligations and the retirement of licenses and infrastructure so the old system does not remain an unmonitored security or cost exposure.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.