Core financial logic that still works—and can no longer be changed.
Banks, insurers, pension funds and risk firms run ledgers, policy engines and long-term product calculations on systems written decades ago in RPG, COBOL or EGL.
We read that code, prove what it computes, and move it to a platform your own developers can keep changing—without changing the numbers it produces.
- A product change that needs a specialist who is retiring
- A regulator’s question that takes a week to answer
- An API the core system cannot expose safely
- A pricing rule nobody is willing to touch
- A dependency map that exists only in one person’s head
None of this is a failure of the old system. It is what happens when the people who wrote it move on.
Which platform, exactly
Financial institutions say “legacy” and mean two entirely different machines. The distinction matters, because the languages, the tooling, the migration risks and the people are different in each case.
IBM i
Midrange · not a mainframe
- Operating system
- IBM i, formerly OS/400 and i5/OS
- Hardware
- IBM Power servers
- Lineage
- System/38 → AS/400 → iSeries → IBM Power
- Languages we meet
- RPG (RPG III, RPG IV, ILE, free-form), CL, ILE COBOL, code generated by Synon / CA 2E
IBM Z
Mainframe
- Operating system
- z/OS
- Hardware
- IBM Z, z/Architecture
- Lineage
- System/360 → System/390 → IBM Z
- Languages we meet
- COBOL, PL/I, JCL, Assembler, with CICS, IMS and Db2 for z/OS around them
IBM i is not a mainframe. It is IBM’s integrated midrange operating system, running on IBM Power servers—a different architecture, a different operating system and a different product family from IBM Z running z/OS. Vendors who blur the two usually have not worked on either.
EGL sits across both. It is a fourth-generation language you do not deploy directly: you generate COBOL or Java from it, for IBM Z or for IBM i. That makes an EGL estate a migration of the generator’s output as much as of the source, and it is worth saying so before anyone scopes the work.
The logic is the asset, not the code
Credit-risk models, pension calculations, insurance product rules, long-term securities tracking: these were built once, corrected over decades against real cases, and are now the most accurate description of how the business actually works. The code is the only place that description survives in full.
A migration that loses the logic has failed, however modern the result looks. Everything we do is arranged around not losing it.
That is why we parse the real source rather than the documentation, and why every increment is validated against the behavior of the original before it replaces anything. The method is set out in Migration Blueprint and Migration CodeCraft.
Why it gets harder every year
Regulatory pressure, fast-moving markets, rising security threats and customers who expect digital services all push in the same direction, and the estate sets the ceiling on how fast you can answer any of them. Meanwhile the constraint that decides most timelines is not technical.
- Skills are now the top-ranked concern on IBM i. In the 2026 IBM i Marketplace Survey, 69% of the 315 respondents named IBM i skills their leading concern, up from 60% a year earlier—the first time in nine years that skills displaced cybersecurity at the top of the list.
- Public-sector risk frameworks already treat it as a formal risk. The UK government’s Legacy IT Risk Assessment Framework scores every legacy system on seven likelihood criteria, and “Lack of Knowledge and Skills” is one of them, alongside end of vendor support and known security vulnerabilities.
- The gap compounds quietly. Every year the system grows, the number of people who understand it falls, and the migration you postpone becomes the migration you have to do under pressure and without the people who could have advised on it.
What modernization changes
Maintenance gets cheaper
Post-migration the code has been cleaned, the dead branches are gone and the structure is one a current developer can read. That reduces both maintenance cost and complexity.
Changes become possible again
New products, new rules and new channels stop being infrastructure projects. Adding a feature, or retiring an old one, becomes an ordinary change on an ordinary codebase.
Integration stops being the blocker
A modern runtime exposes the core through interfaces the rest of the business can consume, including cloud services you cannot reach from the old platform.
Security follows the mainstream
Older components are often unpatchable because the vendor no longer maintains them. On a supported stack, patching is routine rather than a project.
Hiring gets easier
The pool of Java and Python developers is a different order of magnitude from the pool of RPG developers, and it is growing rather than shrinking. That changes who you can hire and what you can pay them to do.
Your team can read the system
The output is code your own developers would have written, in your target architecture. No proprietary intermediate representation, no supplier you cannot leave.
Sources worth reading before you decide
-
Guidance on the Legacy IT Risk Assessment Framework
A scoring method for rating legacy systems on likelihood and impact, so the riskiest ones can be identified and prioritized rather than argued about. Written for UK government departments, but the seven likelihood criteria and six impact criteria transfer directly to a bank or an insurer.
-
Danske Bank drives competitive differentiation in banking
IBM’s own case study on Danske Bank’s mainframe development practice: 50% faster to market and 60% faster development cycles, across roughly a thousand active mainframe developers. Worth reading for what it is—a tooling and process story on z/OS, not a migration off the platform—and as a reminder that Danske Bank is a z/OS shop, not an IBM i one.
-
Danske Bank halves large-scale migration timeline with hyperautomation on AWS
The other half of the same bank’s story: 16,600 servers and 1,000+ workloads, with runbooks generated in seconds rather than weeks. A useful picture of what automation does to a migration schedule at scale.
Where we fit
- We build the tooling, not just the project. Parsers, transpilers and language engines are our own product line, so a migration here is tooling built for your codebase rather than a room of consultants reading code by hand.
- RPG and IBM i are where we are deepest. Our RPG Language Engine has been exercised on more than 30 million lines of production RPG. See RPG & IBM i modernization for what that covers.
- Python and Java are both live targets. If Python is where you are heading, Ready-to-go RPG to Python migration is the packaged path; RPG to Java is the other.
- The estate comes first. We will not quote a migration we have not measured. That is what the Blueprint is for.
Start with what the code actually says.
Tell us the platform, the languages and what is pushing the timing. We will tell you plainly what we would do, what it would cost, and whether the migration is worth doing at all right now.
