By David Beisert (ERNI Switzerland)
Every bank, insurer and pension fund has one: a core system that runs every night, calculates every interest rate, contribution and fee, and that nobody in the organisation wants to touch. Not because it doesn’t work. It has worked for thirty years. The problem is that nobody can say exactly how. This article focuses on how how financial institutions can reduce risk via automated testing, business logic separation, and incremental modernisation.
The system nobody dares to touch and the pains everyone recognises
Nobody knows how it works anymore. The people who built it have retired or moved on. The documentation describes a version from fifteen years ago. The business rules are scattered across screens, stored procedures and nightly batches. The only complete specification is the running system itself. When an auditor asks how a particular fee is calculated, the honest answer is: we would have to look.
A handful of people hold it together. Two or three specialists understand the nightly batch. They are booked out for months, some are close to retirement, and everyone knows what happens if they leave. Boards and supervisors know it too. Key-person risk is now firmly on their agenda.
Every change feels like surgery. A new product, a regulatory adjustment, a tariff change: each one means weeks of manual testing, a release window a few times a year and a weekend when nobody sleeps well. Eventually the business stops asking for changes, because it already knows the answer will be ’next year‘.
It has been tried before. Many organisations have a replacement programme in their history that ran over budget and behind schedule, and was eventually stopped. The scars are real. Every new proposal is met with the same question: why should it work this time?
It eats the budget. Industry research such as RS2’s 2025 banking study puts the share of bank IT budgets spent on maintaining legacy systems at up to 70 percent. Money spent keeping the lights on is money not spent on anything new.
The result is a stand-off. The system is too risky to change and too risky to leave alone.
Why so many migrations fail
Most migration programmes start with where to go: which cloud, which vendor, which target date. It is an understandable reflex. A new platform is tangible. It can be budgeted, presented and signed off.
But it skips the real problem. If nobody can describe what the old system does, nobody can prove that the new one does the same. Every step becomes large, every cutover a leap of faith, and the business case depends on a big-bang weekend going right. When it goes wrong, it is rarely the new platform’s fault. It is a rule nobody knew existed.
I have seen this from the inside. For years, I worked on migrating J2EE applications to Spring Boot. The projects that went smoothly were not the ones with the best target technology. They were the ones where the business logic had been pulled apart from the technology before anything moved.
Change the order: record, separate, then migrate
The way out of the stand-off is not a better target platform. It is a different sequence.
- Record what the system does today. Before a single line changes, automated ‚golden master‘ tests capture the current behaviour: given these inputs, the system produces these outputs. For the first time, there is a reference that does not live in someone’s head. It documents behaviour that was never written down.
- Separate the business rules from the technology. Backend systems are hidden behind a facade, so the rules no longer need to know whether they talk to DB2, a CICS host or SWIFT. Step by step, accounts, payments and limits move into a core that talks to the outside world only through defined interfaces. Architects call this hexagonal architecture. In plain terms: keep the rules apart from the plumbing. Once that is done, the rules can be tested automatically: thousands of cases in seconds instead of a test weekend.
- Migrate one service at a time. Following Martin Fowler’s strangler fig pattern, each service is switched over behind the facade while the channels keep running. There is no big bang. Every step is checked against the golden master and can be rolled back.
The order matters. Code that is tied to its platform cannot be tested in isolation, so recording and separating come first. The new platform comes last.
What leadership gets
Control instead of hope. A migration built this way produces evidence at every step: which rules are covered, which services have moved, which behaviour matches the golden master. That is exactly what steering committees, auditors and supervisors ask for.
Knowledge that no longer walks out the door. What used to live in two or three heads now lives in an executable test suite. New team members can change the system without fear, and the key-person risk shrinks with every rule that is covered.
A regulatory story that holds. FINMA Circular 2023/1 requires Swiss banks to identify critical functions, set tolerances for disruption and show that they can restore those functions. The transition period ended on 1 January 2026. In the EU, DORA has applied since January 2025. A core system whose behaviour cannot be tested is hard to reconcile with either framework.
Money that starts working early. The staged approach does not remove maintenance costs overnight, but it starts reducing them from the first step. Value arrives in increments, so the programme can be paused or redirected without writing off what has been done.
The next migration is already coming
There is one more reason to do it this way, and it is easy to overlook. Today’s modern platform is tomorrow’s legacy. The cloud stack chosen now will be the system someone wants to replace in fifteen years.
If the business rules are welded to that stack, the organisation will face the same stand-off again. If they live in a separated, tested core, the next platform change is a project, not a crisis. Separating logic from technology pays off twice: in this migration and in the next one.
Three questions for your executive team
- Do we know which business rules our core system applies, and where they live?
- Could we prove automatically that a changed system behaves exactly as before?
- How many people can explain our nightly batch, and what happens if they leave?
If the answers make you uneasy, you are not alone. And you do not need to start with a platform decision.
Start by making the system understood
The first step can be small: pick one critical function, record its behaviour and see what you learn. It is the cheapest way to turn a system nobody dares to touch into one you can change with confidence.
If your organisation has such a system, our engineering teams can help you find out what it actually does and put a safety net around it before anything moves.
