Skip to content
Arcwright

Nordvik Bank

Core banking migration with zero customer downtime

Nordvik Bank ran 2.4 million retail accounts on a COBOL core written in 1997. We moved every one of them onto an event-sourced ledger on AWS in nine months against a fourteen-month board forecast, and no customer lost access for a single minute.

Client
Nordvik Bank
Sector
Banking
Run
9 months · Jan–Sep 2024
Filed
2024-10-14
Capability
Platform modernisation · Cloud migration · Data engineering · Reliability engineering
Stack
Java 21 · Spring Boot 3 · PostgreSQL 16 · Apache Kafka · Debezium · Temporal · Kubernetes · AWS · Terraform · IBM MQ

Impact

  • 0 min

    Customer-facing downtime across 11 cutover waves

  • 9 months

    Delivered against a 14-month board forecast

  • £2.1M

    Annual mainframe run cost removed

Challenge

Banking
9 months · Jan–Sep 2024

The ledger closed for a four-hour batch window every night, which meant card authorisations ran on balances that could be sixteen hours stale. Only two people in the bank could still change the interest-accrual code, and one of them retired in March. The incumbent supplier had costed a fourteen-month replacement that ended in a weekend big-bang cutover — a two-day freeze on payments for 2.4 million customers. Finanstilsynet, the Norwegian regulator, had refused that plan twice on resilience grounds before Nordvik called us.

Solution

We refused the big bang and built a dual-run instead. Debezium streamed change events off the mainframe into Kafka, a new event-sourced ledger consumed them, and a reconciliation service compared both balances to the øre every fifteen minutes. Once the two ledgers had matched for thirty consecutive days we moved customers across in eleven cohorts of roughly 220,000, smallest first, each one rehearsed against a production-shaped copy with a tested rollback that we exercised for real twice. Temporal ran the cutover workflows so a wave could be paused mid-flight rather than abandoned. The mainframe stayed authoritative until the final wave landed; only then did we reverse the flow and decommission it.

Plates

  • Architecture diagram of the dual-run topology: the COBOL core on the left emits change events through Debezium into Kafka, the new event-sourced ledger consumes them on the right, and a reconciliation service between them compares account balances in both directions.
    Plate 01Dual-run topology, in place from week 6 to week 38.
  • Cutover control board tracking eleven customer cohorts across four columns — rehearsed, cut over, reconciled, closed — with all eleven cards sitting in the closed column.
    Plate 02The cutover board on the morning after wave 11.
  • Reconciliation dashboard showing 2.4 million account balances compared between the legacy and replacement ledgers, with the variance column reading zero for thirty-eight consecutive days.
    Plate 03Thirty-eight days of zero variance was the gate for wave 1.

Testimony

They found three integrations we'd forgotten we depended on. That's the part nobody else did.

Ingrid Sandvik · Group CTO, Nordvik Bank5 out of 5

Adjacent records