Getting off the legacy core banking system: big bang, phased migration or hollowing out the core

A bank has run on the same core system for twenty years or so. It keeps the accounts, calculates interest and fees, produces the accounting entries, feeds regulatory reporting and runs, every night, the batch that lets the next day begin. Dozens of applications have been attached to it over time: channels, lending, cards, risk, compliance. Many of them read its database directly. Fewer and fewer people know it in detail, and every regulatory change costs more to implement than the one before.

The decision to replace it is eventually taken. The programme then organises itself around one question: which package should we choose? Tenders go out, vendors run their demonstrations, comparison grids fill up. The question of how to move from the old system to the new one is left for later, to a “migration” phase imagined as a technical step.

The choice of exit strategy commits the bank more than the choice of target package. It decides how long the bank will live with two systems, what it will stop changing in the meantime, and when the risk will be concentrated. Two banks that pick the same package can go through entirely different programmes depending on how they get off the old one.

What the core actually does

Before choosing a strategy, a bank needs to know what it is leaving. A core banking system is not one function. It is a stack of functions that ended up sharing the same database and the same calendar.

Account keeping. Balances, transactions, value dates. This is the function everyone associates with the core, and it carries the heaviest responsibility: a wrong balance is an incident the customer sees.

The party master. Customers, their relationships, their identification and know-your-customer data. It is usually read by every other application, and rarely through an interface designed for the purpose.

The product catalogue and pricing. The terms of each product, the rate grids, the exceptions negotiated customer by customer. Some of these rules exist only in configuration or in code.

Calculations. Interest, overdraft charges, commissions, fees, with their day-count conventions and the special cases accumulated over the years.

End-of-day processing. Closings, due dates, direct debits, bulk updates. It sets the rhythm of the whole bank, and many peripheral applications are timed around it.

Accounting entries and reporting feeds. Every transaction produces entries according to an accounting scheme the system applies; regulatory reporting, risk and management control are fed from its extracts.

This breakdown is not a theoretical exercise. It determines what can be separated. A bank whose peripheral applications all read the core database does not have the same options as one where those accesses go through identified interfaces. It is the same reading as the business capability map, applied to a single system: you cannot replace what you have not broken down.

Three ways out

Replacement programmes vary a great deal in detail, but almost all of them follow one of three strategies, or a combination.

Switch everything at once

The new system is built and configured alongside the old one. When it is ready, all customers, accounts, products and balances are migrated in a single operation, usually over a weekend or a low-activity period. On Monday, the bank runs on the new system.

The advantage is real: there are never two systems of record at the same time. No customer with some accounts on one side and some on the other, no synchronisation to maintain, a single reconciliation to get right.

So are the demands. The change freeze first: throughout the build, every change made to the old system has to be carried over to the new one, or refused. Regulation does not wait, and neither do business units. The longer the build, the more the target moves. Rehearsals next: a single cutover only succeeds after several full dry-run migrations, timed and reconciled. Rollback last: it is planned in every cutover plan, but it is only realistic for a few hours. Once transactions have been posted on the new system, going back means replaying them on the old one, which few banks know how to do.

The risk is concentrated on one date. That is both the strength and the weakness of this strategy.

Migrate in waves

The cutover is broken up. By product: savings first, then loans, then current accounts. By population: new customers on the new system, the existing book later. By entity or by country, for a group. Each wave is a smaller cutover, and the bank can learn from one before the next.

The risk is spread, but coexistence has a cost that plans almost always underestimate. For the whole length of the programme, the bank has two systems of record. A customer can have a current account in one and a loan in the other. The bank must then produce a consolidated view, a consistent statement, limits calculated across all of the customer’s exposures, a single know-your-customer record. End-of-day processing runs twice and the two runs have to be sequenced. Accounting receives entries from two sources.

The “new customers first” split deserves a particular warning. It looks like the simplest, because no data needs to be migrated at the start. But it never makes the old system shrink: the existing book stays whole, and it holds the oldest products, the most unusual cases, the contracts hardest to take over. The last wave is always the hardest, and it is the one people are tempted to postpone.

Empty the core before replacing it

The third strategy does not start with the core. It starts with what surrounds it. First, an interface layer is put between the core and its consumers, so that channels and peripheral applications stop reading its database. Then, one by one, the functions that can live elsewhere are taken out: the party master, the product catalogue and pricing, the channels, payments. The core is gradually reduced to what only it can do — account keeping, calculations, accounting. Replacing it, at the end, means replacing a smaller and better isolated system.

This strategy needs an upfront investment in the interface layer, which produces no visible benefit for the business for a while. With every function taken out, it also raises the question of which source is authoritative: during the transition, which holds the true version of a customer’s address, the new master or the core that still needs it for its own processing? Finally, it creates a particular risk: a reduced, well-isolated core that keeps working can look good enough. The final replacement is then postponed indefinitely.

What actually decides between the three

None of these strategies is right in general. The choice depends on a few characteristics of the bank that can be examined before a single vendor is consulted.

How separable the core is. If peripheral applications access the core database directly, neither phased migration nor hollowing out is possible as things stand: those dependencies have to be cut first. That work is often the first real phase of the programme, whatever strategy follows. It is what the article on the interface contract describes: as long as an interface has neither owner nor definition, what sits behind it cannot be changed.

The ability to freeze. A single cutover assumes the bank accepts making almost no changes to its core system during the build. That means looking at the regulatory calendar and the commercial ambitions for the years concerned. If the freeze cannot hold, the single-cutover strategy turns into permanent double development, the worst combination of all.

How much risk, and in what form. Some organisations prefer a high risk on a known date, prepared and rehearsed, to a lower risk spread over several years. Others do not. Supervisors are interested in this too: depending on the jurisdiction, a change of core system may have to be presented to them, with the cutover plan and the continuity arrangements. The regulatory and operational context weighs directly on the architecture of the programme here.

Data quality. A single cutover requires all data to be taken over at once and reconciled to the cent. Migration in waves lets the bank learn on a first scope and correct before the next. A bank whose party master holds many duplicates or incomplete records would rather not discover it on cutover weekend.

Availability of skills. The longer coexistence lasts, the longer the bank must keep the people who know the old system and train those who will run the new one. In a market where those skills are scarce, programme length is also a staffing constraint.

How standard the bank wants to become. Replacing a highly specific core with a package means giving up some of the accumulated particularities, or reproducing them at great cost. The trade-off between standard and bespoke comes up function by function here, and it shapes the strategy: it is easier to adopt a product’s standard rules for a wave of new customers than for a book of old contracts.

If you hollow out: in what order

Hollowing out is often the best fit for banks whose core is tightly coupled to its surroundings, because it starts by reducing that coupling. It does, however, need a deliberate order of exit.

One simple principle usually guides that order: take out first what is read by many and changed by few, and last what carries balances.

Channels and access to the core come first. As long as online banking, branches and partners call the core directly, every function taken out forces changes to them. Once they go through an interface layer, what sits behind it can change without them seeing it.

The party master and the product catalogue follow. They are read by almost every application and changed by a limited number of processes. Taking them out makes them consistent across the bank, and prepares the migration of accounts: a customer already present in the new master is easier to move.

Payments and peripheral processing can then be moved, provided the bank knows how they fit with end-of-day processing.

Account keeping, calculations and accounting leave last, together. They are too closely tied to be separated safely: a balance, the interest it earns and the entry that records it must stay consistent at all times. This last step is the one that most resembles a single cutover, but on a far smaller scope than at the start.

At each step, the question of which source is authoritative must be settled explicitly. When a party master is taken out, the core often keeps a copy for its own processing. Someone has to decide which one is authoritative, in which direction updates flow, and what happens when they diverge. A transition in which both are authoritative depending on the case is the most common source of incidents that are hard to explain.

Reconciliation, whatever the strategy

The three strategies share one point that plans often address too late: at every cutover, the bank will have to show that the new system says the same thing as the old one. Not approximately, but account by account.

That demonstration covers several things: balances, outstanding amounts, accrued interest, loan schedules, accounting positions. It means running both systems on the same transactions for a period and comparing. Above all, it means defining in advance what an acceptable difference is. Two systems that do not apply exactly the same day-count convention, or do not round at the same moment, will produce legitimate differences. If they have not been qualified beforehand, each one becomes an alert to investigate during the tensest period of the programme.

Accounting is where everything meets. During coexistence, entries come from two systems, with two accounting schemes that must produce the same accounts. Regulatory reporting, built on feeds designed around the old core, has to be fed by both without a break. A programme that does not address those feeds from the outset discovers late that accounting, more than the core itself, sets the pace of the cutover.

The shared trap: the exit that never ends

Each strategy has its own way of stopping halfway.

The single cutover is postponed once, then twice. Meanwhile, the old system keeps changing, because the freeze did not hold, and the gap to be taken over grows. Migration in waves moves the simple products and leaves the last wave on the old system, with no deadline. Hollowing out moves the peripheral functions, and the reduced core, now stable and well isolated, no longer finds a sponsor for its replacement.

In all three cases, the bank ends up in an intermediate state that was never designed to last. This is the situation described in the article on architecture roadmaps: transformation always stops somewhere, and it had better stop in a liveable state. For a core system, that means each step must be operable over the long term if the next one does not come: tooled coexistence, automated reconciliation, a clearly assigned authoritative source for each piece of data.

Two disciplines limit this risk. The first is to write down, at the moment the strategy is chosen, the conditions for retiring the old system: when it stops being changed, when it becomes read-only, what must be true for it to be switched off. The second is to record the assumptions behind the choice of strategy — that the freeze will hold, that the skills will be available, that the data is good enough — in a decision register, so the bank knows when the choice must be reconsidered. A strategy chosen because the freeze looked sustainable must be re-examined on the day the freeze gives way, not two years later.

Then there is funding. An exit programme spans several budget years, and every annual trade-off can quietly undo it by funding a change to the old system rather than a step of the exit. That is what the article on the project portfolio shows: the real roadmap can be read in what gets funded.

The question to ask before choosing a package

Choosing a new core system remains an important decision. But it is made better once the bank already knows how it intends to get off the old one, because the exit strategy changes what it expects from the package: its ability to coexist with the old system, to take over data in waves, to expose its functions through interfaces, to own the party master or, on the contrary, to leave it elsewhere.

Before launching the tender, a bank benefits from being able to answer a few simple questions. Which applications read the core database directly today? How long can it accept not changing it? Which data will be authoritative for each customer during the transition? And if the programme stopped halfway, what state would it be in? The answer to that last question says more than any comparison grid about which strategy the bank can really afford.