Case study · Financial Services
A payments core rebuilt one capability at a time.
Northwind processes £4bn a year on a platform it could not switch off. We replaced it in place, without a single cutover weekend.
- 18-month programme
- Zero unplanned downtime
- £4bn annual volume
- Sector
- Payments
- Duration
- 18 months
- Squad
- 9 engineers, 1 designer
- Region
- United Kingdom
Overview
The situation
Northwind's payment core had been extended for eleven years by four different vendors. It worked, in the sense that money arrived — but nobody could add a payment method in under two quarters, and the reconciliation break count had become a standing board item.
Two previous replacement attempts had been abandoned. Both had planned a cutover weekend. Both had been cancelled when the risk assessment came back.
Challenge
The challenge
The constraint was absolute: the platform could not stop. It settled merchant funds daily, and a missed settlement window would have been a regulatory event before it was a customer service one.
The second constraint was knowledge. The original team had left years earlier and the documentation described a system that no longer existed.
- No maintenance window longer than 20 minutes was available
- Behaviour had to be reconstructed from the running system, not from documents
- Reconciliation breaks were discovered up to 14 hours after the fact
- Every change required change-advisory-board approval
Approach
What we did
We put a facade in front of the legacy core on day one, so every subsequent migration was a routing decision rather than a release event. Then we moved capabilities across in order of risk, lowest first.
01
Characterise before replacing
Six weeks capturing production traffic and building a characterisation test suite from it. The suite described what the system actually did — including four behaviours the business did not know it relied on.
02
Install the facade
A routing layer in front of the core, initially passing every request through untouched. Once it was proven neutral, it became the mechanism for every migration that followed.
03
Build the ledger
A double-entry ledger as the new source of truth, running in shadow mode against the legacy system for three months until the two agreed to the cent on every transaction.
04
Migrate by capability
Refunds first — low volume, high tolerance. Then disbursements, then authorisation. Each moved behind a flag with instant rollback, and each ran dual-write until reconciliation was clean for thirty days.
05
Reconcile continuously
The nightly batch was replaced by streaming reconciliation. Breaks surfaced within four minutes instead of fourteen hours, which changed them from investigations into corrections.
06
Decommission
Dependency analysis proved nothing still called the legacy core. It was archived and switched off in month seventeen — the first of the three attempts to reach that step.
Results
The outcome
Northwind now adds a payment method in weeks. The reconciliation item came off the board agenda in month nine, and the platform absorbed its first peak trading period without a war room.
Cutover weekends
Migration ran entirely behind flags
Break detection
Down from up to 14 hours
Faster payment-method onboarding
Two quarters to under three weeks
Availability maintained
Across the full 18-month programme
“Two vendors told us it needed a cutover weekend and we cancelled both projects. BinaryScaler told us it did not, and then proved it every fortnight for eighteen months.”
Industries
Technologies
Published 14 April 2026
More work
Other systems we have shipped
Have a problem shaped like this one?
Bring us the constraint your last partner called impossible. We will tell you on the call whether we believe it.