#core platform upgrade

Core banking and payment platforms rarely die. That is the whole difficulty. A switch installed in the 1990s will keep authorising transactions long after the people who configured it have collected their pensions. It does not fall over. It just makes everything around it slower.

The tax that appears on no invoice

Legacy platform cost is mostly indirect, which is exactly why it survives budget season.

The direct costs are visible enough. Licences, specialised hardware, contractors who still know the language. Those get scrutinised every year and survive because replacing them looks expensive by comparison.

The indirect costs never appear as a line item. A new product takes eleven months instead of three because the core cannot represent the data model. A partner integration needs a custom file transfer because the platform has no usable API. Compliance reporting requires people reconciling extracts by hand because the system was never built to answer that question.

Each of those lands in someone else's budget. Added together they usually exceed the platform's running cost. Nobody adds them together.

Standards move whether you do or not

Then there is external pressure. Payment messaging standards have shifted toward richer, structured formats. Real-time settlement is now an expectation rather than a premium feature. Regulators increasingly ask for data that older schemas simply do not carry.

A platform that cannot represent structured remittance information or extended party detail does not fail a mandate loudly. It fails quietly, by requiring workarounds: mapping layers, truncation rules, manual exception queues. The workarounds become permanent. Eventually they become the thing that has to be modernised too.

Why big-bang replacement keeps disappointing

The clean answer is to replace the platform outright. Buy or build something modern, migrate, decommission the old one.

Programs like this have a poor record, and not because the technology is hard. They struggle because the old system's behaviour was never fully documented. Twenty years of edge cases live in code nobody has read end to end. Every one of them was a real business requirement once. You find out which ones still matter during a cutover weekend, which is the worst possible time to find out.

They also outlast the organisation's attention span. Sponsors change. Priorities move. A four-year program with nothing visible until year three is a program waiting to be cancelled by someone who was not in the room when it was approved.

Phased, boring, effective

The approach that tends to work is considerably less dramatic. Put an API layer in front of the core so new products stop depending on its internals. Move the capabilities that change most often out first, running old and new in parallel until the new path has earned trust. Instrument everything, because you cannot safely change what you cannot observe.

Most platform modernization services follow some version of that sequence: assess and prioritise, design the target architecture, then migrate capability by capability instead of all at once. Slower on paper. Finishes more often.

The other benefit is optionality. Each phase delivers something usable on its own. If funding shifts or leadership changes, you are left with real improvements rather than a half-migrated estate and an awkward status report.

Start with the knowledge of the current system

If there is one thing worth doing before any of the engineering, it is capturing what the current system actually does. Not what the design documents claim it does. What it does, including the parts that look like bugs and turn out to be deliberate.

That work is tedious and gets no applause, and it is often the difference between a modernization that lands and one that gets written off. The people holding that knowledge are, in most institutions, closer to retirement than to their next promotion.

Ask them now, while asking is still an option.

About Author

Derek Francis