What 18 million accounts taught us about mainframe migration

Rewriting decades of COBOL is the visible work, so it is where estimates go. The risk sits somewhere quieter: the ledger itself. Balances are the one thing a bank cannot approximate, and every rule that touches them — rounding, value dating, reversal order — has usually been encoded twice, once in the code and once in the habits of the people who operate it. We spent the first six weeks writing no production code at all, only extracting those rules into executable tests. Everything after that had something to be measured against.

The new ledger ran in shadow for four months. Every posting hit both systems, and a reconciliation job compared them account by account, overnight, and filed each difference as a defect. The first night produced roughly eleven thousand mismatches. Nearly all of them turned out to be one bug: a rounding rule applied at a different point in the transaction. That is the value of a dual run — it converts vague migration anxiety into a defect count that goes down each week, and it gives you an honest answer to "are we ready yet".

The switch itself took nine minutes. Because both systems had been writing for months, the cutover was not a data migration — it was a change of which system answered reads. We moved traffic in stages, kept the mainframe warm and writable for a further three weeks, and never needed it. The result was 40% lower run cost and roughly six times the throughput headroom, but the number worth repeating internally is the other one: no maintenance window, and no customer told to come back on Monday.