Legacy Data Migration and What Your Bank Should Archive

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.

Alexander Kiel

Business Analyst · Banking & Wealth Management

13.06.2026 · 8 MIN READ · DATA MIGRATION

ON THIS PAGE

1. Sort Legacy Data by Status

2. Set How Much History Moves

3. Archive What You Must Keep

4. Delete Data With No Purpose Left

5. Prove Each Deletion Is Complete

6. Record Each Decision With Its Owner

Sample case: Morgan Stanley

In short

FAQ

Every legacy data migration forces a choice for each data set: move it to the new platform, archive it or delete it. Erasure is now a focus of supervisors. In a coordinated action, 32 data protection authorities across Europe examined how organisations erase personal data. Some controllers stated that data from backups is only deleted when it is automatically overwritten by another back-up.

Banks are no exception. In 2022, the Danish data protection authority found that Danske Bank could not document in more than 400 systems that rules for deletion had been set. These systems process personal data of several million people. The authority recommended a fine of DKK 10 million.

A platform change is the cheapest moment to make these decisions. After cutover, every record left behind needs an owner and a reason. Does your bank know which legacy data must move, which must be kept and which may go?

Illustrative decision matrix for legacy data in a bank migration, showing which data objects are migrated, archived or deleted, with dormant accounts highlighted as data that must migrate

STEP 1

Sort Legacy Data by Status

Start with an inventory of every data object in the old system: clients, accounts, positions, transactions, documents and logs. Split each one by status: active, closed within its retention period, closed beyond it and dormant. Count the records in each group. The counts show how large the archive and the deletion list will be.

Dormant accounts need care. They look like history but remain a liability to the client. In Luxembourg, banks must consign assets after 10 years for bank accounts and safe-deposit boxes, but only after unfruitful research to identify the account owner. Until then, the account belongs on the new platform. My article on data migration strategy shows how this scope feeds the overall plan.

✓

Count the records per data object and status

✓

Treat dormant accounts as active for the migration

✓

Flag closed records whose retention period has expired

How many of your bank's accounts are dormant and who decides where they go?

Keep in mind: A closed account can still hold open items such as fees, tax refunds or unclaimed securities. Check before you archive it.

STEP 2

Set How Much History Moves

The new platform needs enough history to run the business: current positions, open orders and the transactions behind this year's client reports. It rarely needs decades of closed bookings. Each extra year adds mapping, testing and reconciliation work. Agree a cut-off date for each data object with the business, Compliance and Tax. In my last decommissioning project, legal retention periods set how much history we kept; those periods vary by country.

Some history has a hidden purpose. Under German tax law, when securities move to another depot, the old paying agent must communicate the acquisition data to the new one. If the acquisition data are not proven, tax is withheld on 30% of the proceeds. Cost basis must therefore move with the positions. Everything else should pass the GDPR test of data limited to what is necessary.

✓

Agree a cut-off date for each data object

✓

Migrate acquisition costs together with every open position

✓

Keep the history behind this year's client reports

Which reports must your new platform produce for the year in which you migrate?

Keep in mind: Annual client and tax reports often need the whole year's transactions. A cut-off in the middle of the year can break them.

STEP 3

Archive What You Must Keep

Data that must be kept but is rarely used belongs in an archive, not on the new platform. That covers closed accounts within their retention period, old transactions and documents. The archive needs search, access rights and a deletion date for each record. Plan it before cutover, so the old system can be switched off on time.

Tax rules shape the format. The German GoBD treat the shutdown of a legacy system and a data migration as a system change. They also rule out reducing existing machine evaluability, for example by converting the file format. A PDF print of a transaction table is not enough. My article on application decommissioning shows how to build and test the archive.

✓

Move closed records within their retention period to the archive

✓

Keep tax-relevant data in a machine-readable format

✓

Give every archived record a deletion date

Can your tax auditors still query legacy transactions after the old system is switched off?

Keep in mind: An archive is not a second production system. If users need the data every day, it belongs on the new platform.

STEP 4

Delete Data With No Purpose Left

Data whose retention period has expired should not move anywhere. Migrating it adds cost and carries the old risk into the new platform. Archiving it only postpones the decision. Build a deletion list from the inventory, check it with Legal for open litigation and regulatory requests, then delete before the final migration run.

The GDPR sets the principle. Personal data may be kept for no longer than is necessary for the purposes for which they are processed. Clients can demand erasure where the personal data are no longer necessary in relation to the purposes for which they were collected. A migration that copies such data into a new system repeats the problem there.

✓

Build the deletion list from the status inventory

✓

Check legal holds with Legal and Compliance first

✓

Delete before the final migration run, not after

How much of your legacy data is kept today only because nobody decided otherwise?

Keep in mind: Retention periods differ by country and data type. Confirm them with Legal before you delete anything.

STEP 5

Prove Each Deletion Is Complete

Deleting a table in the old system is not the end. Copies sit in backups, test environments, file shares, reports and the hardware itself. A migration creates more of them, because every rehearsal loads real data somewhere. List every copy, delete or sanitise it and keep evidence of what was done, when and by whom.

Test copies need rules. Under DORA, non-production environments should only store anonymised, pseudonymised, or randomised production data. Hardware needs the same care. NIST describes media sanitisation as a process that renders access to target data on the media infeasible. Wiping servers and drives is a task for specialists, not for a removals firm.

✓

List backups, test copies and file extracts for each system

✓

Use anonymised data in rehearsals wherever possible

✓

Keep a certificate for every sanitised device

Could your bank show an auditor where every copy of its rehearsal data went?

Keep in mind: Backups often run on their own retention cycle. Align it with the deletion plan, or deleted data survives for years.

STEP 6

Record Each Decision With Its Owner

Write every decision into one matrix: data object, status, decision, legal basis, retention period, owner and date. Have the data owners, Compliance and the data protection officer sign it. The matrix becomes the scope of the migration, the input for the archive and the proof that deletions were approved.

Regulators expect this evidence. The GDPR calls this accountability: the controller must be able to demonstrate compliance with its principles. Records of processing should state, where possible, the envisaged time limits for erasure. In the Danske Bank case, the gap was missing documentation. My article on the decision log shows how to keep such decisions traceable.

✓

Record each decision with its legal basis and owner

✓

Get sign-off from Compliance and the data protection officer

✓

Update the matrix after every migration rehearsal

Who in your bank signs off that a legacy data set may be deleted?

Keep in mind: A matrix that nobody updates after the rehearsals gives auditors the wrong picture. Keep it current until switch-off.

Delete | Viktor Mayer-Schönberger (Professor of Internet Governance and Regulation @ Oxford Internet Institute)

SAMPLE CASE

Morgan Stanley

In 2016, Morgan Stanley closed two data centres of its wealth management business. The OCC later found a failure to exercise proper oversight of the 2016 decommissioning of two Wealth Management business data centers. On several occasions, the firm hired a moving and storage company with no experience or expertise in data destruction services.

The moving company sold to a third party thousands of MSSB devices, some of which held customer data. They were eventually resold on an internet auction site without removal of such customer PII. During a later server refresh, 42 servers, all potentially containing unencrypted customer PII, went missing.

On 8 October 2020, the OCC assessed a $60 million civil money penalty against two Morgan Stanley banks. In September 2022, the SEC charged Morgan Stanley Smith Barney over the data of approximately 15 million customers. The firm agreed to pay a $35 million penalty.

Key takeaway: Deletion is part of the migration, not an afterthought. Before legacy systems are switched off, decide who wipes every server, backup and drive, check the result and keep the proof for regulators.

"MSSB’s failures in this case are astonishing."

Gurbir S. Grewal (Director of the Enforcement Division @ SEC)

In Short

Legacy data migration works best as one decision per data object: migrate what the business uses, archive what the law requires and delete what has no purpose left. Sort the data by status, set the history depth, prove every deletion and record each decision with its owner.

The result is a lean new platform, an archive that answers auditors and an old system that can be switched off without leaving client data behind.

Frequently Asked Questions

What is legacy data migration?

Legacy data migration moves data from an old system to a new platform when the old system is replaced or switched off. In a bank, it covers clients, accounts, positions, transactions and documents. It is not only a technical copy. For each data set, the bank decides whether to migrate it, archive it or delete it, based on business use and retention rules.

What is the difference between data archiving and data migration?

Data migration moves data into a new production system, where users work with it every day. Data archiving moves data that must be kept but is rarely used into a separate store with search, access rights and deletion dates. Migrated data stays fully editable. Archived data is read-only and kept only until its retention period ends, then deleted.

What is data disposition?

Data disposition is the decision about what happens to data at the end of its active use: keep it, archive it, transfer it or destroy it. In a migration, it is recorded for each data object with its legal basis, owner and date. Good disposition also covers copies in backups, test environments and old hardware, not only the main system.