The Conversation Every Bank Has Wrong

I have been in the room for more than forty core banking migration discussions. They almost always open the same way: a shortlist of vendors printed on A3, a timeline anchored to a board commitment, and a question — Temenos or Finastra? On-premise or SaaS? Three-year programme or five?

Nobody in the room is asking: what does our data actually look like, and what will it cost to move it?

That omission is why the majority of these programmes fail — not at the technology layer, but at the data migration layer, six months after vendor selection, when the first ETL run comes back with 40% record mismatches and nobody can explain why.

The vendor-first approach to core banking migration is not just a sequencing mistake. It is a structural misread of where the risk actually lives.

Where the Risk Actually Lives

Ask a CTO what keeps them up at night during a core banking migration. The answer is usually "cutover risk" — the fear of a failed go-live weekend. That fear is understandable. But it is focused on the wrong part of the programme.

Cutover risk is a symptom. The root cause is data model incompatibility, and it compounds throughout the programme every time it is not resolved early.

Here is what happens in a typical vendor-first migration:

  1. Bank selects vendor after an 18-month RFP process
  2. Vendor's implementation team begins data migration discovery
  3. Implementation team discovers the legacy data is structurally incompatible with the target system
  4. A data remediation workstream is created — typically staffed with 3–5 engineers assigned for 6+ months
  5. Programme timeline extends. Budget inflates. Executive patience exhausts.

By the time the data problem surfaces, the bank has committed to a vendor contract, sunk 18 months of programme overhead, and lost the option to make a different architectural choice. The data problem was always going to be there. It was just discovered too late to change anything.

What "Archaeologically Structured" Actually Means

When I use the phrase archaeologically structured to describe legacy banking data, I am being precise.

A 25-year-old core banking system has not just accumulated data — it has accumulated decisions. Every product change, every regulatory update, every acquisition, every emergency fix that "will be cleaned up later" has left a geological layer in the data model.

A single customer record in a legacy core might contain:

No modern core banking system — Temenos, Thought Machine, Mambu, Oracle FLEXCUBE — was designed to ingest data in this form. Every one of them expects a clean, normalised input schema. The gap between the legacy structure and the target schema is the actual migration problem. And it cannot be solved by the vendor. It can only be solved by the bank.

This is the data archaeology work. Mapping what you actually have to what the target system expects. It is slow, unglamorous, and almost always underestimated.

The Correct Sequence

The teams that execute core banking migrations successfully do it in an order that looks counterintuitive from the outside:

Step 1: Model the target data state

Before any vendor is selected, define what your data should look like at migration completion. Build the target schema. Agree on the canonical customer record. Define how transaction history will be represented. Establish the data quality standards the migrated data must meet.

This is not a technical exercise — it is a business exercise that happens to have technical outputs. The decisions made here determine everything downstream: which vendor can accept your data with the least friction, how long ETL development will take, and what your cutover risk actually is.

Step 2: Audit the source data

Map the legacy data against the target schema. Every mismatch is a migration risk. Some mismatches are simple transformations (date format conversion, currency code normalisation). Others are structural (denormalised records that must be split, encoded fields that must be parsed and reparsed, orphaned records with no valid foreign key).

The audit produces a migration complexity score for each entity type. Customer records: high complexity, 6-month remediation estimate. Transaction history: medium complexity, 2-month work. Product definitions: low complexity, 3-week work. These estimates become the migration programme timeline.

Step 3: Build the ETL

Write the extract, transform, and load pipeline against the target schema you defined in Step 1, drawing on the complexity scores from Step 2. Run it against a production data sample — not a test slice. Legacy data has edge cases that test data was never designed to expose.

The ETL is not done when it runs without errors. It is done when the output passes data quality validation at a rate above your acceptance threshold — typically 99.9%+ for core banking data where errors have regulatory consequences.

Step 4: Choose the vendor that handles your ETL best

Now — and only now — go to market with a vendor shortlist. But the RFP questions have changed. Instead of asking vendors to demo their product, ask them to demonstrate how their onboarding and migration tooling handles the specific data structures you have already mapped.

The vendor selection criterion is no longer "which platform has the best product roadmap?" It is "which vendor's migration tooling and professional services team can absorb our specific ETL with the least friction?"

This reframing changes the evaluation entirely. A vendor whose platform looks superior on a feature matrix but whose implementation team has never worked with denormalised legacy data at your scale is a higher-risk choice than a vendor whose migration track record matches your data profile exactly.

What the 6-Month Data Model Phase Actually Saves

The data modelling phase looks like waste. A programme with a 3-year timeline and a 6-month data modelling phase feels slow before anything has started. That is the objection I hear most often from programme sponsors who want to show progress.

But consider what the alternative costs:

The 6-month data modelling investment does not just reduce risk. It compresses the total programme timeline by eliminating the discovery work that would otherwise happen under pressure, at the worst possible moment.

ISO 20022 Is Compressing the Timeline

If the above argument for sequence discipline sounds theoretical, ISO 20022 makes it urgent.

The Bank of England's CHAPS migration to ISO 20022 is complete. SWIFT's cross-border migration continues to roll out through 2026. For UK and European banks with cross-border payment flows, ISO 20022 compliance is not a future concern — it is a current operational requirement.

The structural change ISO 20022 introduces is mandatory rich data: Legal Entity Identifiers, structured address formats, purpose codes, remittance information in a defined XML schema. For banks migrating core systems in parallel with ISO 20022 adoption, the data model decisions interact in ways that are difficult to unpick if they are made independently.

A core banking migration programme that does not model the target data state with ISO 20022 compliance built in from the start will face a retrofit. Retrofitting payment data structures to a new standard on a partially-migrated core is the kind of problem that adds 18 months to a programme and does not appear in the original business case.

The correct sequence — model target data first, including ISO 20022 compliance requirements — is not just prudent. For any bank with a cross-border book, it is the only sequence that avoids double-handling.

How Spectral Partners Approaches This

Our core banking migration work starts at Step 1 — the data model. Not vendor evaluation. Not roadmap design. Not programme governance.

The reason is simple: we have seen what happens when programme planning precedes data modelling. The data model work will happen regardless. The question is whether it happens on a schedule the bank controls, or on a schedule imposed by implementation failure.

We work with the bank's data and engineering teams to produce a migration complexity assessment before any vendor contract is signed. The assessment includes:

The output is a programme plan with realistic timelines grounded in actual data complexity — not the optimistic assumptions that vendors and programme teams tend to adopt when no one has done the archaeology yet.

The Migration That Lands On Time

In 30 years of core banking work, the pattern in successful migrations is consistent: the teams that invested in understanding their data before choosing their vendor had programmes that hit their milestones. The teams that chose vendors first spent the middle third of their programme doing the data work they should have done at the start — except now under contract pressure, with a fixed go-live date, and no room to re-sequence.

The vendor decision is reversible, at cost. The data is not. It is what it is, and the earlier you understand it, the more options you have.

Need an honest data migration assessment before your vendor RFP? Talk to Raj.

Raj has 30 years of core banking migration experience across UK building societies, regional banks, and challenger institutions. He leads core banking advisory at Aicura Consulting.