Archive First, Then Switch Off Legacy Systems
BMO Harris archived 4.3 TB and saves $5 million a year. Application decommissioning starts with the archive, not with the switch-off date.
Alexander Kiel
Business Analyst · Banking & Wealth Management
21.02.2026 · 6 MIN READ · DATA MIGRATION
ON THIS PAGE
1. List What Must Be Kept
2. Decide What to Delete
3. Choose a Lasting Format
4. Prove Completeness
5. Keep Data Accessible
6. Decommission the Application in Steps
Sample case: BMO Harris Bank
In short
FAQ
Old systems are expensive to keep alive. The US Government Accountability Office reports that federal agencies spend more than $100 billion a year on IT, of which about 80% goes to operating and maintaining existing systems, including legacy systems up to 51 years old.
Banks know the pattern after every merger. When Deutsche Bank moved Postbank customers onto a single platform, delays meant the old systems stayed running at a cost to the bank, with savings of €300 million expected only from 2025. Yet application decommissioning cannot start with the switch-off. In Germany, banks must keep accounting vouchers for ten years, even after the general period for other companies was cut to eight.
The data has to outlive the system that created it. Can your bank still answer an auditor's question about a system that was switched off five years ago?
STEP 1
List What Must Be Kept
Start with an inventory of every data object in the legacy system: accounts, transactions, documents, client communication, logs and reports. For each object, record the legal basis and the retention period. The periods differ widely by type of data and by country.
MiFID II requires firms to keep records of client communications for five years and, if the authority requests it, up to seven years. Tax and accounting rules often require ten. Some contracts and pension records must be kept for decades.
✓
List every data object and document type in the system
✓
Assign the legal basis and retention period to each
✓
Record the start event for each period, such as account closure
Do you know the longest retention period hidden in your legacy system?
Keep in mind: The retention period usually starts when a relationship or contract ends, not when the record was created. Closed accounts can still have years to run.
STEP 2
Decide What to Delete
Archiving everything is not a safe default. Under the GDPR, personal data may be kept for no longer than is necessary for the purposes for which it is processed. Data whose retention period has expired should be deleted before the archive is built, not carried into it.
Check for legal holds before deleting anything. Data linked to litigation, investigations or regulatory requests must be kept until the hold is lifted. Document every deletion decision, so that it can be explained to an auditor later.
✓
Identify data whose retention period has already expired
✓
Check legal holds with Legal and Compliance
✓
Document each deletion with date, scope and approval
How much of your legacy data is kept only because nobody decided to delete it?
Keep in mind: Deleting data after it has been archived is harder than before. Clean up first, then archive what remains.
STEP 3
Choose a Lasting Format
The archive must remain readable long after the original software is gone. Store data in open, well-documented formats that do not depend on a single vendor or application. The Library of Congress assesses digital formats against factors such as disclosure, adoption, transparency and external dependencies.
Keep the structure with the data. Tables need their field descriptions, code lists and relationships. Documents need their metadata, such as client number, date and document type. Without this context, archived data becomes a collection of files nobody can interpret.
✓
Use open formats for tables, documents and reports
✓
Archive the data model, code lists and field descriptions
✓
Avoid formats that need the legacy application to be read
Could someone outside the project read your archive in ten years without the old system?
Keep in mind: A proprietary archive format can become the next legacy system. Moving out of it later costs another migration.
STEP 4
Prove Completeness
Before a system is switched off, prove that the archive contains everything it should. Compare record counts, balances and totals between the source and the archive for each data object. Use checksums for documents and files. Reconcile every difference, not only the large ones.
Ask the business to test the archive with real questions: a client statement from six years ago, a transaction history or a closed loan file. The answers should match what the legacy system shows today. Record the results and have them signed off by the data owners. My article on keeping a decision log everyone trusts shows how to record such sign-offs.
✓
Reconcile counts, balances and totals for every data object
✓
Run test queries with business users before sign-off
✓
Keep the reconciliation results as part of the audit trail
Who in your bank signs off that the archive is complete?
Keep in mind: Once the system is off, a missing record cannot be retrieved. Every gap must be closed before, not after.
STEP 5
Keep Data Accessible
An archive is only useful if people can find what they need. Auditors, tax authorities and regulators expect timely answers. Clients have the right under the GDPR to obtain a copy of the personal data undergoing processing, which includes data held in an archive.
Define the typical requests and make sure the archive can answer them: search by client, account, date and document type. Rebuild the most important reports, so users see familiar layouts. Restrict access by role and log every query, as the archive contains sensitive client data.
✓
Define standard search and retrieval requests per user group
✓
Rebuild key reports from the legacy system in the archive
✓
Set role-based access and log every retrieval
How long would it take your team to answer a client's data request from the archive?
Keep in mind: Archives also expire. Plan the automatic deletion of records at the end of each retention period from the start.
STEP 6
Decommission the Application in Steps
Do not switch off a legacy system in one move. First set it to read-only and let users work with the archive in parallel. Then remove user access, keep the system available to a small team for a fixed period and only then shut down servers, licences and support contracts.
Each step needs a clear exit criterion and a date. When we decommissioned 17 legacy applications, small data discrepancies from system issues had to be fixed before the reconciliation matched and an application could be switched off. Many organisations keep legacy systems running for years because no one sets a firm end. My article on migrating, archiving or deleting legacy data shows how to decide what happens to each system's data. GAO found in 2019 that eight of the ten agencies running critical legacy systems had missing or incomplete plans to modernise them.
✓
Move to read-only and run the archive in parallel
✓
Set exit criteria and a date for each step
✓
Cancel licences, support and hosting once the system is off
Is there a date in your plan when the legacy system is finally switched off?
Keep in mind: Contracts for licences and support often have long notice periods. Check them early, or the savings arrive a year late.
About Bit Rot (or How to Preserve Digital Information) | Vint Cerf (Chief Internet Evangelist @ Google)
SAMPLE CASE
BMO Harris Bank
BMO Harris Bank, a subsidiary of Bank of Montreal with more than 600 branches in nine US states, went through several mergers after acquiring M&I Bank. Many of the applications it inherited ran in read-only mode mainly to provide access to their data. The bank faced data retention requirements ranging from 7 to 40 years.
In 2012, it set up a data retention and decommissioning programme covering more than 100 applications. One target was a finance application with general ledger, accounts receivable and fixed asset modules, which cost more than $285,000 a month to keep running. The archive had to keep a full audit trail, reproduce the original reports and store data in a standards-based format.
The bank archived 4.3 terabytes of data and decommissioned 16 applications within seven years. It reports savings of $5 million per year, a project duration of three months and a payback period of twelve months.
Key takeaway: BMO Harris did not switch off its old applications until the data was archived, searchable and compliant. The archive made the savings possible without creating a compliance gap.
"We are nonchalantly throwing all of our data into what could become an information black hole without realizing it."
In Short
Application decommissioning saves money only once the data the system holds is safe. The archive is not an afterthought of a migration or merger but the condition for ending it.
Banks that list retention duties, delete what may go, choose lasting formats, prove completeness and keep data accessible can switch off old systems with confidence. The result is lower cost and a clean answer to every auditor's question.
Frequently Asked Questions
What is the difference between a backup and an archive?
A backup is a copy of a live system, made to restore it after a failure. It depends on the original software and is usually kept for weeks or months. An archive holds data for its full retention period, independently of the original system, with search, access controls and deletion rules. Backups of a decommissioned system are no substitute for a proper archive.
How long must banks keep data after application decommissioning?
The retention period depends on the data, not on the system. In Germany, banks must keep accounting vouchers for ten years. MiFID II requires client communication records for five to seven years. Other records can require far longer. The switch-off date does not change these periods, so the archive must always cover the longest one that applies.
Can legacy data simply be migrated to the new system instead?
Sometimes, but it is often not the best choice. Moving decades of closed accounts into a new core banking system adds cost, complexity and data quality issues. Many banks migrate only active data and archive the rest. The archive keeps historical records accessible and compliant while the new system stays lean. The right split depends on how often the historical data is used.
TAGS
ABOUT THE AUTHOR
Alexander Kiel
Business Analyst for process optimisation, data migration, business integration and project support in banking and wealth management. Lean Six Sigma Green Belt and Certified Scrum Master. Former private banking front office, with front-to-back experience from client advisory to data and systems.
KEEP READING
Related Articles
DATA MIGRATION
5 SEP 2026 · 8 MIN READ
Delta Migration After the Initial Load
How banks move the changes made after the initial load: fix the start point, capture every change including deletes, apply them in order, reconcile each delta and drain the last one.
DATA MIGRATION
13 JUN 2026 · 8 MIN READ
Migrate, Archive or Delete Legacy Data
How banks decide what happens to legacy data in a platform change: sort it by status, set the history depth, archive what must be kept, delete the rest and record each decision.
DATA MIGRATION
16 MAY 2026 · 8 MIN READ
Reference Data in a Bank Migration
How banks move reference data to a new platform: list the domains, pick one golden source, load it before positions, check identifiers, confirm settlement instructions and keep owners.