Skip to content

Engineering2025-03-11

What a mainframe migration actually costs

The build is about a third of it. Here is the real shape of a nine-month core banking migration budget, line by line, including the three lines nobody quotes for.

Author
Priya Raghunathan
Published
11 MAR 2025
Read
5 MIN
Ref
B9445F

Every migration proposal we are asked to second-opinion has the same defect. Someone has priced the build and called it the programme. The build is the part you can point at, so it is the part that gets estimated carefully. It is also, in our experience, about a third of what you will spend.

What follows is the actual shape of one programme: Nordvik Bank's retail core, 210,000 lines of COBOL moved off a z/OS estate in nine months with no customer-facing downtime. The figures are shares of a £6.2m total. Your percentages will differ. The categories will not.

Where the money went

LineShareWhat it bought
Application rewrite and test31%640 programs, of which 512 were carried forward
Data migration and reconciliation18%41m accounts, 18 months of transaction history
Parallel running14%11 weeks of dual infrastructure and dual licensing
Integration remediation11%Four undocumented interfaces, one of them file-based
Non-functional work8%Observability, DR, penetration test, remediation
Cutover rehearsals7%Six full rehearsals, one of them a rollback
Regulator engagement5%Evidence pack, two supervisory meetings
Decommission and archive6%Seven-year retention, tape recall, contract exit

Note what is not on this list: a contingency line. Contingency is not a category, it is an admission that one of the categories above is not understood yet. We would rather name which one.

Parallel running is a fixed cost, and it is not small

You do not cut a ledger over and hope. You run both systems, feed both, and compare their outputs daily until the divergence is zero for long enough that the divergence being zero is boring. At Nordvik that was 11 weeks.

The trap is licensing. Mainframe software is typically charged on capacity — a rolling four-hour average of consumed MSUs — so running the legacy system at unchanged volume during parallel means you pay full freight for both platforms simultaneously. You do not save a penny of mainframe cost on cutover day. You save it on decommission day, which is usually four to six months later. Budget the gap.

Reconciliation is a project, not a task

Row counts prove nothing. We reconciled on three axes: balance to the penny, interest accrual to the penny, and 18 months of transaction history line for line. That surfaced 2,300 accounts where the legacy system's rounding on part-month interest disagreed with the target's.

The engineering fix takes an afternoon. The decision takes three weeks, because someone senior has to say out loud whether the new system will reproduce a 1990s rounding bug or correct it, and either answer generates customer communications, a written rationale, and a line in the evidence pack. Price the decision, not the patch.

The knowledge cost

Two people at Nordvik understood the batch schedule. Both were within four years of retirement, and both had been quietly polishing their CVs since the programme was announced — which is the rational response to being told your life's work is being decommissioned.

We now write retention into the plan explicitly: a defined role for the incumbent team as design authority rather than as an obstacle, a retention payment tied to the decommission date rather than the go-live date, and paired discovery sessions recorded and transcribed. It cost roughly 3% of programme value. Losing either of them would have cost far more than that in rediscovery.

What actually moves the number

  • Retire before you rewrite. Static analysis plus 24 months of execution logs showed 18% of Nordvik's programs had not run once. Every one of them would otherwise have been rewritten and tested.
  • Freeze functional scope on day one. Not change control — a freeze. "While we are in there" is the single most expensive phrase in this work.
  • Put the decommission date in the contract. A migration with no decommission date becomes a permanent second system, and you have bought a cost, not removed one.
  • Rehearse more than feels reasonable. Rehearsals are the cheapest hours in the programme. A failed cutover is the most expensive weekend your organisation will ever have.

What "done" costs

Twelve to eighteen months after go-live, the honest total for a core of this size lands between £5m and £8m, and the build is £1.6m to £2.2m of it. If you have been quoted the build and told it is the programme, you have not been given a bad price. You have been given an incomplete one, and the difference will arrive anyway — later, unbudgeted, and in the middle of a parallel run.

Priya Raghunathan, Head of Data Engineering

Written by

Priya Raghunathan

Head of Data Engineering

Moved 340 million patient records for Orrery Health across a live estate with zero reconciliation breaks, then turned the dual-run harness she built for it into the tool we now use on every migration. She specialises in the part everyone underestimates: proving the new system agrees with the old one, row by row, before anybody switches anything off.

Share

Related notes

All notes
  • 01Engineering

    Reading a COBOL codebase you did not write

    The programs are the last thing to read. Start with the job control and the copybooks, because that is where forty years of business rules were actually written down.

    Mainframe5 MIN
  • 02Reliability

    Cutover rehearsals, and why we do six

    A 412-step runbook took 19 hours on its first rehearsal against a 9-hour window. By the sixth it took 6 hours 40. The rehearsals were not practice — each one was designed to fail differently.

    Migration5 MIN
  • 03Engineering

    The integration nobody documented

    Every legacy platform has interfaces that appear in no diagram and no register. Here is how we find them before cutover finds them for us — and why the interface diagram is the last place to look.

    Integration · Discovery4 MIN