Modernisation  · 

Modernising the core without stopping the bank: equivalence has to be proved

Converting the code is only part of modernisation: rebuilding the application knowledge and proving equivalence matter just as much.

Core applications — COBOL on the mainframe, older Java, Delphi or niche languages — have carried the business for decades. Leaving them untouched costs more every year: MIPS and licences climbing, skills walking out of the organisation, digital channels that struggle to connect, traceability that is hard to produce when an audit asks for it.

Promises about reduced effort concern writing the code, which is the smaller part of the problem. Projects stall elsewhere: obsolete documentation, business rules buried under layers of changes and dead branches, hidden dependencies between batch chains and ledgers, and above all the difficulty of proving that the new system does exactly what the old one did.

The approach that holds puts AI inside a governed project: the agents analyse, generate and test, while people validate the critical steps. The knowledge is reconstructed from the code and signed off by the experts before anyone rewrites a line, and one pilot function migrated by hand sets the architecture and the standards for all the rest.

Equivalence is not declared, it is measured. It means checking that the new application, given the same input, produces the same results as the old one and follows the same business rules. That applies both to the automatic processing (batch) and to what users do online. In batch the original program, run outside the production environment, acts as the oracle: same inputs, outputs compared record by record. Online it is proved on the business transaction, with test cases squared against the functional analysis and UAT with sign-off. It is the only way to switch off the legacy on a documented decision rather than an act of faith.

All the news Let’s talk