Data Migration Strategy for a Bank Platform Change

Data Migration Strategy for a New Bank Platform

How banks build a data migration strategy for a new platform: set the scope, choose big bang or phased, map and clean, rehearse, reconcile and plan the cutover.

Alexander Kiel

Business Analyst · Banking & Wealth Management

21.03.2026 · 8 MIN READ · DATA MIGRATION

ON THIS PAGE

1. Define What Moves and What Stays

2. Pick a Data Migration Strategy

3. Map and Clean the Source Data

4. Rehearse Until the Timing Holds

5. Reconcile and Sign Off Each Load

6. Plan the Cutover and the Fallback

Sample case: PNC

In short

FAQ

A data migration strategy decides what data moves to a new platform, in what order and how the bank proves it arrived. In a study of 1,471 IT projects, Bent Flyvbjerg and Alexander Budzier found that one in six was a black swan, with a cost overrun of 200% on average and a schedule overrun of almost 70%.

Banks know the cost of a failed move. In April 2018, TSB migrated the data of its approximately 5.2 million customers to a new platform over one weekend. The data arrived, but the platform failed. TSB did not return to a BAU position until 10 December 2018. It was fined £29,750,000 by the FCA and £18,900,000 by the PRA.

Most of the risk is set long before the migration weekend: in the scope, the approach, the rehearsals and the point of no return. Does your bank know which of these decisions are already fixed and who made them?

Comparison of big bang and phased data migration for a bank platform change by cutover, timeline, interfaces, fallback and best fit, with the fallback row highlighted as the deciding question

STEP 1

Define What Moves and What Stays

Start with the scope. List every data domain that must move: clients, accounts, portfolios, positions, cash balances, standing orders, static data and transaction history. For each domain, decide whether it moves in full, moves as a summary or stays in an archive. History is the hardest call. Ten years of transactions slow every trial run, while too little leaves advisers and auditors without answers.

Legal rules set the floor. Under the German Commercial Code, banks must keep accounting vouchers for ten years. The GDPR expects personal data to be adequate, relevant and limited to what is necessary for its purpose. My article on application decommissioning shows how to archive data that must be kept and switch off later.

✓

List every data domain with its source system

✓

Decide per domain whether to migrate, summarise or archive

✓

Agree the depth of transaction history with Compliance

Which data in your bank must move on day one and which only needs to be retrievable?

Keep in mind: Retention rules depend on the country and the type of record. Check them with Legal before you fix the scope.

STEP 2

Pick a Data Migration Strategy

There are two basic approaches. A big bang migration moves all clients in one cutover weekend. A phased migration moves them in waves, by product, booking centre or client segment. Big bang avoids months of running two platforms side by side. Phased migration limits the damage of a single failure but needs temporary interfaces and longer parallel operations.

The choice also decides whether you can go back. TSB opted for a predominantly single event data migration. The FCA later noted that a ‘roll-back’ plan was not possible for TSB in these circumstances. The original target date of November 2017 had been set two and a half years previously. Fix the approach first and the date second.

✓

Compare big bang and phased options on risk, cost and time

✓

List the interim interfaces a phased approach would need

✓

Record the decision, the reasons and who approved it

Could your bank cope with a failed migration weekend if every client moved at once?

Keep in mind: A phased plan is not automatically safer. Every interim interface between old and new platforms is a new source of breaks.

STEP 3

Map and Clean the Source Data

Map every target field to a source field and agree a rule for each one: direct copy, transformation, default value or manual entry. Run data quality checks on the source early, such as duplicate clients, missing tax residency, outdated addresses or closed accounts that still hold balances. Fix these errors in the old system before the first trial.

The Basel Committee urges banks to ensure sound data quality as the basis for digitalisation projects. Its principles also expect a bank to capture and aggregate all material risk data across the banking group. My article on the data quality framework shows how to name an owner and a golden source for each critical field.

✓

Map each target field to a source field and a rule

✓

Have business owners sign off the mapping per domain

✓

Clean known errors in the source before the first trial

Who in your bank confirms that a mapped field means the same thing in both systems?

Keep in mind: Cleansing inside the migration tool hides the problem. The error returns if the old process keeps producing it.

STEP 4

Rehearse Until the Timing Holds

Run trial migrations with full data volumes, each one closer to the real cutover. Early trials test the mapping and the load. Later dress rehearsals run the whole sequence inside the time window of the migration weekend, including reconciliation and business checks. Set the go-live date only when the rehearsals meet the exit criteria agreed in advance. In the decommissioning I worked on, each legacy application needed its own extraction program; it usually took two or three UAT runs before the live run.

Rehearsals alone do not prove readiness. TSB's board relied on evidence that included nine dress rehearsals. Yet its two data centres were configured inconsistently despite having been specified to be identical. The FCA found that testing only concluded the day before the decision to migrate was taken. Rehearse on an environment that matches production.

✓

Run each trial with full production data volumes

✓

Time every step against the cutover window

✓

Set exit criteria before the first dress rehearsal

How many full rehearsals has your team planned and what must each one prove?

Keep in mind: A rehearsal on an environment that differs from production proves the data, not the platform it lands on.

STEP 5

Reconcile and Sign Off Each Load

Prove that the data arrived complete and correct. Compare record counts, balances, positions and cash per client and per account between the old and new systems. Agree tolerances in advance and record every difference with its cause. Business owners sign off each domain before the go/no-go decision.

The Basel Committee states that risk data should be reconciled with bank’s sources, including accounting data where appropriate. The EU rules on ICT risk under DORA require that the changes are tested and finalised in a controlled manner. They also call for the independence of the functions that approve changes, so the team that runs the migration should not be the only one to approve it.

✓

Reconcile counts, balances and positions per client

✓

Check key fields such as risk profile and tax residency

✓

Record every difference with its cause and owner

Who in your bank signs off that every client and position arrived as expected?

Keep in mind: Totals that match can hide offsetting errors. Reconcile at client and account level, not only at bank level.

STEP 6

Plan the Cutover and the Fallback

Write the cutover plan hour by hour: freeze of the old system, final extract, load, reconciliation, business checks and opening to clients. Set go/no-go points with named decision makers. Define the point of no return and what happens if the bank stops before it. After go-live, plan hypercare with extra support for advisers, operations and client service.

DORA asks for the identification of fall-back procedures and responsibilities for changes that do not succeed. The FCA's review of technology change found that over 90% of reviewed firms are still reliant on legacy infrastructure and applications. My article on the operational readiness check shows what to confirm before each wave goes live.

✓

Write an hour-by-hour cutover plan with named owners

✓

Fix go/no-go points and the point of no return

✓

Staff hypercare for the first weeks after go-live

At what hour of the migration weekend does your bank lose the option to go back?

Keep in mind: A fallback that has never been tested is a hope, not a plan. Rehearse it like the migration itself.

How Big Things Get Done | Bent Flyvbjerg (Villum Kann Rasmussen Professor @ IT University of Copenhagen)

SAMPLE CASE

PNC

PNC completed its acquisition of BBVA USA on 1 June 2021. At closing, it expected the conversion of bank systems and branches to occur in October 2021. That left about four months for the move.

PNC converted the business in one event rather than in waves. It moved 2.6 million customers, 9,000 employees and nearly 600 branches across seven states. The former BBVA USA branches reopened as PNC branches on 12 October 2021. PNC called it the largest conversion in its history.

The bank reported that it had completed conversion of BBVA USA into PNC Bank and that cost saves of $900 million remain on track. Savings of this kind usually depend on running a single platform, so the conversion date also started the business case.

Key takeaway: A big bang migration can work when the target platform, the team and the method are proven. Decide the approach early, then hold the date only while the rehearsals keep supporting it.

"To have achieved this milestone in less than a year is noteworthy."

William S. Demchak (Chairman, President and CEO @ PNC)

In Short

A data migration strategy for a bank platform change rests on six decisions: what moves and what stays, big bang or phased, a signed-off mapping on clean source data, rehearsals that meet agreed exit criteria, reconciliation at client level and a cutover plan with a tested fallback.

The result is a migration weekend without surprises, clients who keep their service and a business case that starts on the planned date.

Frequently Asked Questions

What is a data migration strategy?

A data migration strategy is the set of decisions that guide a move of data from old systems to a new platform. It defines the scope, the approach such as big bang or phased, the order of the moves, the quality rules, the rehearsals and how the data is reconciled and signed off. It is agreed before detailed planning starts.

What is the difference between a data migration strategy and a data migration plan?

The strategy answers what moves, how and why. The plan answers when and by whom. A strategy fixes the scope, the approach and the acceptance rules. The plan turns them into tasks, dates, owners and dependencies, from the first trial run to hypercare. The plan changes often during a project, while the strategy should stay stable once approved.

Who should own a data migration in a bank?

The business should own the data and IT should own the tools. Each data domain needs a business owner who signs off the mapping, the cleansing and the reconciliation result. A migration lead coordinates the work across business, IT and vendors. The go/no-go decision belongs to a steering committee with named members, not to the delivery team alone.