← ALL INSIGHTS
CASE STUDY — Global Banking Group · BANKING · CORE PLATFORM ENGINEERING

Global Banking Group: Legacy Core Modernization.

A core banking platform cannot be paused. Payments clear, balances update, and the controls a regulator inspects are expected to hold on the day of a migration exactly as they do on any other day. Modernizing a system like that means changing it while it runs, and proving at every step that nothing moved that should not have.

BY Alan, Strategy Editor | August 6, 2026 · AUGUST 6, 2026
ZERO DOWNTIME DURING MIGRATION
LEGACY CORE MODERNIZED · TRANSACTION PROCESSING UNINTERRUPTED
STRICT COMPLIANCE HELD THROUGHOUT
01 — THE PROBLEM

A system nobody is allowed to stop

Legacy core modernization starts from a system nobody is allowed to stop. The transaction path carries live money, and the rules encoded in it have accumulated over the life of the platform, often in code whose original authors have moved on. Documentation describes intent; the code describes behaviour, and the two have drifted. So the starting constraint is not technical ambition. Every change has to be made against a running platform, under the same controls the regulator already inspects, with no window in which the service is simply unavailable.
02 — BEFORE ANYTHING IS BUILT

Observed behaviour becomes the specification

Research-led, not assumption-led. We establish what the current system actually does rather than what it was designed to do: the live transaction flows, the batch windows they depend on, the downstream consumers, the reconciliation points, the error paths that only appear under load. Observed behaviour becomes the specification. In parallel we agree the compliance position — which controls apply, what evidence an auditor will ask for, who signs off each stage — before any code changes. If a flow cannot be described precisely enough to be verified, it is not ready to move.
03 — SEQUENCING THE MIGRATION

One flow at a time, behind a switch

Nothing moves in one step. The core is decomposed into flows that can be cut over independently, and each takes the same route: build the replacement, run it in shadow against production traffic, compare its output against the legacy system record by record, then route live volume to it. Traffic shifts gradually and the old path stays warm behind a switch, so reverting is a routing decision rather than a recovery exercise. Cutovers happen with the service up. That is what zero downtime requires — not a longer maintenance window, but never needing one.
04 — WHAT IS HANDED OVER

The capability to keep going without us

Outcome-owned, not hours-owned. The deliverable is not only the migrated flows. It is the comparison harness that proved parity, the routing and rollback controls, runbooks for the failure modes found along the way, the reconciliation checks that keep running afterwards, and the audit evidence produced as the work ran rather than assembled at the end. We work alongside your engineers throughout, so the people operating the platform afterwards are the people who moved it. Modernization that depends on the team who did it is not finished.

Have a core system you
cannot switch off?

Talk to the teamAgentic AI service →
FAQ

About this engagement

How can a core system be migrated without downtime? By never needing a window. Flows move one at a time behind a routing switch, with the replacement running in shadow against live traffic first and its output compared against the legacy record before any customer sees it. Cutover is a change of route, not a restart, and the previous path stays available until the new one has held under real volume. Downtime is avoided by design rather than by scheduling.
How do you handle logic that exists only in the legacy code? We treat observed behaviour as the specification. Production traffic and historical records are used to characterise what each flow actually produces, including the edge cases documentation omits. The replacement is then tested against that record rather than against an idealised description. Where the existing behaviour turns out to be wrong, we surface it as a decision for your team rather than silently reproducing it or silently correcting it.
How is compliance kept intact during the migration? The control position is agreed before build, not reconstructed afterwards. We identify which controls apply to each flow, what evidence demonstrates they still hold, and who approves each cutover. That evidence — parity comparisons, approvals, rollback tests — is generated as a by-product of the work, so the audit trail exists at the moment of the change. Strict compliance is easier to hold when nothing has to be retrofitted.
What happens if a migrated flow behaves unexpectedly in production? It is routed back. Because the legacy path stays live behind a switch until a flow has proven itself, reversal is a configuration change with a known blast radius, tested before it is needed. Monitoring compares the two paths continuously rather than at cutover only, so divergence is visible early. The question we answer before every cutover is how we would undo it.
What does your team leave behind? The migrated flows, the harness that proved they match, the routing and rollback controls, runbooks for the failure modes found along the way, and the reconciliation checks that keep running. We work with your team from problem definition through implementation, so the capability to operate and extend the platform stays in-house. If the work only holds while we are present, it has not been handed over.