Core modernization without the big bang
The graveyard of banking IT is full of three-year replatforming programs. The institutions modernizing successfully are doing it around the edges of the core — deliberately, and in production the whole time.
Every bank we meet has a core-modernization story, and most of them are horror stories: the multi-year program that consumed a technology budget and was quietly cancelled; the vendor migration that doubled in scope; the parallel-run that never ended. The pattern failure is consistent enough to name. Institutions treat the core as a thing to be replaced, when the workable strategy is almost always to treat it as a thing to be surrounded.
The strangler pattern, applied to money
The approach that works borrows an old software idea: build the new system around the old one, route traffic to the new pieces incrementally, and let the legacy core shrink until what remains is small enough to retire — or calm enough to leave alone. In banking terms, that means new product engines, channel layers, and data platforms that sit beside the core, fed by well-defined interfaces, taking over one product line or one journey at a time.
The discipline this demands is not primarily technical. It is the discipline of never being out of production. Every increment ships to real customers, reconciles real money, and can be rolled back. The moment a program’s value is deferred to a future cutover weekend, its risk profile changes category.
Interfaces are the real modernization
The most valuable artifact of a modernization program is rarely the new core. It is the interface layer — the clean, versioned, well-tested API surface through which everything else talks to the systems of record. Once that layer exists, the institution has choices: swap a component, add a partner, launch a channel. Without it, every change is open-heart surgery.
This is also where design earns its seat. An interface layer built only to mirror the legacy core’s data model imports forty years of accidents into the new estate. The teams that get this right model the business domain — accounts, agreements, parties, positions — and make the legacy system conform at the boundary.
The organizational trap
Modernization programs fail organizationally before they fail technically. The classic structure — a “new bank” team building the future while the “old bank” team keeps the lights on — creates exactly the wrong incentives: the people who understand the core’s behavior have no stake in its replacement, and the people replacing it learn its behavior from documentation that lies.
Mixed teams, rotating ownership, and a single backlog are unglamorous fixes, but we have watched them succeed where org charts full of transformation offices did not.
What to do about it
Choose the smallest product line whose migration would prove the pattern end to end — including reconciliation, regulatory reporting, and rollback. Build the interface layer for that slice as if the whole bank will one day depend on it, because it will. And set the program’s success metric as time-to-first-production-traffic, not percentage-complete against a plan. A modernization that is always live is a program that cannot silently fail.