What NHS delivery experience teaches financial services about large-scale data migration

The most expensive data migration mistakes in financial services are not technical failures. They are planning failures. Systems that were never properly documented. Data quality problems discovered too late to fix without delay. Cutover windows that turned out to be far shorter than anyone had modelled. Stakeholders who signed off a migration plan without understanding what it actually involved.

We have run large-scale data migrations inside the NHS for twenty years. The problems financial services organisations encounter are not different in kind from the ones we have seen in healthcare. They are different in the degree to which organisations are willing to confront them early enough to do something about it.

The legacy problem nobody wants to quantify

Most organisations approaching a core system migration have an incomplete picture of what they are actually migrating. Legacy systems accumulate undocumented data relationships over decades. Fields that were deprecated in 1998 still hold values that downstream processes depend on. Reference data that was never formally maintained has been corrected informally by staff who have since left.

The NHS equivalent is a primary care registration system that has been running for thirty years, holding over 60 million patient records across thousands of GP practices, with data quality that reflects three decades of local variation in how practices enter information. Before a single line of migration code is written, you need to know what you actually have.

Before a single line of migration code is written, you need to know what you actually have.

In practice, this means running systematic data profiling against the live source system well before the migration programme formally begins. It means cataloguing not just the schema but the actual distribution of values, the outliers, the nulls, the fields that contain something other than what their names suggest. Financial services organisations that skip this step consistently discover problems at the worst possible moment.

‍

Cutover is not an event. It is a programme.

The most common planning error we see is treating migration cutover as a single event to be scheduled, rather than a phased programme to be designed. In a system serving millions of customers or patients, there is no acceptable window in which the service can simply stop while data moves across. The migration has to run alongside live operations, with parallel running, reconciliation checks and rollback capability at every stage.

On a national demographic migration covering 60 million records, this meant building reconciliation tooling that could compare source and target record by record at scale, automated alerting when counts diverged, and a staged cutover approach that moved cohorts of records progressively rather than attempting a big bang switch. The programme ran for years, not months, and the migration infrastructure was as complex as the target platform itself.

Financial services core banking migrations routinely underestimate the engineering investment required to run migration and live operations simultaneously. The tooling is not an afterthought. It is central to whether the programme succeeds.

Data quality is a business problem, not a technical one

Technical teams can identify data quality issues. They cannot fix them without business engagement. In every large migration we have run, the data quality remediation phase requires significant time from subject matter experts who understand what the data means and what a correct record looks like. That time is rarely budgeted for at the start of a programme.

In healthcare, this means clinical informatics colleagues working alongside engineering teams to define what a valid patient record looks like across a hundred edge cases. In financial services, it means compliance, operations, and risk colleagues doing the equivalent work for customer records, transaction history, and account attributes. If those colleagues are not available, the programme stalls. Building their involvement into the programme plan from day one is not optional.

‍

Governance has to grow with the programme

Large migration programmes change shape as they progress. The risks at month three are not the same risks as at month eighteen. The governance structures that were appropriate for discovery are not adequate for a programme that is running parallel live systems and preparing for cutover.

One of the lessons from NHS delivery that transfers directly to financial services is that governance maturity has to be built deliberately and continuously, not installed at the start and left to run. That means regular risk reviews that actually update the risk register, sprint retrospectives that surface delivery friction before it becomes programme-level risk, and stakeholder communication that keeps senior sponsors informed without burying them in detail.

On programmes where we have taken over mid-delivery, the absence of this discipline is usually visible immediately: no velocity data, no escalation path, epics that have never been sized, and stakeholders who have stopped attending reviews because the reviews stopped being useful. Recovering from this state is possible, but it costs time that most programmes cannot afford.

What this means in practice

The financial services organisations that get large-scale data migration right share a small number of characteristics. They invest in source system discovery before the programme formally begins. They treat migration tooling as a first-class engineering concern. They build business engagement into the programme plan rather than asking for it reactively. And they build governance structures that can adapt as the programme matures.

None of this is complicated in principle. It is hard in practice because it requires sustained attention to unglamorous work at exactly the point when organisations are most tempted to focus on the new platform rather than the problems with the old one. Twenty years of doing this in healthcare has taught us where the pressure to cut corners is strongest and what the cost of giving in to it looks like.

Aire Logic has delivered large-scale data migration and legacy decommissioning programmes across NHS national infrastructure for over twenty years. If you are planning a core system migration and want an honest conversation about what it actually involves, get in touch.

‍