Programme  ·  Legacy modernisation

L2M

Core applications, modernised
and verified against real data.

Large Legacy Modernization · AI agents inside a governed project · results compared on real data

Tell us about your project The path

The problem

Keeping legacy applications costs more every year, and risks more.

Many core applications — COBOL on the mainframe, older Java, Delphi, or languages few people still write — have carried the business for decades. Leaving them untouched costs more each year and carries growing operational risk.

01

Rising costs — MIPS consumption, licences and support for end-of-life platforms

02

Skills that are hard to replace — the business rules are known to a handful of specialists

03

Slow to change — adding APIs, digital channels and cloud services takes complex work

04

Compliance requirements — operational risk, traceability and audit need documented systems

For many banks the question is not whether to modernise, but how to do it without stopping the business, while the cost of keeping things as they are keeps climbing.

Where these projects get hard

Converting the code is only part of the job.

Claims about reduced effort usually refer to writing the code, not to the whole project. The real difficulty of modernisation tends to surface elsewhere.

AreaWhat makes it hard
Documentation out of dateWhat the system actually does is described only in the code
Business rules in layersLogic added over the years, dead code and duplication
Interfaces and dependenciesHost, dynamic CALLs, overnight batch chains and integration with the ledgers
Testing and proving equivalenceProving the new application produces the same results as the existing one

Which is why it takes method, governance, stakeholder involvement and a structured plan for testing and release. AI agents speed the work up; controlling the result stays with the project.

How it works

Rebuild the knowledge of the system before rewriting it.

L2M uses AI agents inside a governed project. Instead of translating the code line by line, it reconstructs the business rules, puts them to the client’s own experts for validation, and builds a new application in Java or .NET that follows the bank’s standards.

AI agents and specialiststhe agents analyse, rewrite and test the code; the specialists validate the critical steps
Equivalence verifiedbatch or online, the new application’s results are compared with the existing ones on the same data
Works with your AI toolsthe process works with the main enterprise AI tools, including the ones you already use
Project methodgovernance, risk and releases handled with a method built over thirty years of projects

The path

The phases, from analysis to release.

The path covers the whole modernisation cycle, not just the code conversion: it starts with an assessment of the existing application and ends with the controlled decommissioning of the legacy system.

01

Assessment — an inventory of programs, JCL, copybooks and interfaces; a 6R matrix; the complexity of each program checked by a second AI agent; a rough estimate with a minimum and a maximum. Go/no-go decision: the choice is made before the project budget is committed.

02

Analysis, design and set-up — business rules reconstructed from the code and validated by the client’s experts, a map of the application contexts, identification of personal data for GDPR. Target architecture, non-functional requirements, release plan, environments, CI/CD and quality gates.

03

Modernisation with AI agents — one first function, migrated by hand, sets the architecture and the standards. Then, function by function, the agents analyse, generate and test the code, compare it with the original program and correct it until the results match; quality gates and specialist validation come before the merge. It then extends in batches.

04

Testing, certification and data migration — end-to-end regression tests, performance in the batch windows, security tests, parallel run and UAT with formal business sign-off. Data migration with field-by-field mapping, ETL, cleansing and reconciliation through checksums and balancing.

05

Release and decommissioning — go-live against go/no-go criteria, smoke tests and close watch over the first runs. Controlled decommissioning of the legacy system, compliant archiving, a final account of the savings, post-release support and knowledge transfer.

At every phase the final decision rests with the specialists: the agents raise productivity, human control keeps unexpected results in check.

The verification

Equivalence is proved by comparing results.

The new application is compared with the original system: given the same input, the results have to match.

Batch · record by record

The original COBOL program as the reference

The original program is run on GnuCOBOL, outside the bank’s environment, against the same input files and tables. The results are compared record by record.

The comparison environment is set up once and reused for every program.

Online · transaction by transaction

The screens become APIs and web forms

Fields, validations, messages and navigation from each screen are carried into APIs and web forms. Equivalence is proved on the business transaction: the same data displayed, the same messages, the same writes to the database.

End-to-end testing and UAT with formal business sign-off follow.

Comparison testsfor every function migrated
Verification criteria definedby type of change
Regression tests and parallel runacross the whole system

Projects delivered

The method applied in banking projects.

The method has been applied in banking projects still running: two cases different in technology and scope, handled the same way.

Banking group · core batch on the mainframe

Migration of 202 COBOL batch programs on DB2

Critical chains and the 3270 interface moved to Java, Oracle and Angular. The scope was rationalised with business and IT; one manually migrated program served as the reference and the COBOL run on GnuCOBOL as an independent benchmark, then the work extended in batches.

50 → 36front-end functions after the scope review
−50%of project effort, against the traditional method

Banking client · cheque collection procedure

From Delphi to Java, with the documentation rebuilt

Knowledge no longer available was reconstructed from the code into functional and technical documentation, certified by the client. On that basis the agents rewrote the back-end in Java and a new web front-end was built.

90%test coverage, no vulnerabilities found
Aheadof plan, with limited manual work

Frequently asked questions

The questions we are asked
most about L2M.

Any other questions?
No. The process works with the main enterprise AI tools, including the ones the bank already uses. What Add Value brings is the method that governs how they are used inside the project.
Through the assessment: inventory, 6R matrix, the complexity of each program, and a rough estimate with a minimum and a maximum. It closes with a go/no-go decision, before the project budget is committed.
It depends on the project. In the mainframe batch case the bank’s environment was involved only for installation and acceptance, because the original program used for comparison ran externally on GnuCOBOL.
The client’s own experts. The agents reconstruct the rules from the code and produce the documentation, but signing them off is the client’s, and it is the precondition for everything that follows.

Keep exploring

The other Add Value products

Modernise the core system, and prove the results.