«Convert everything, then see»
Converting what nobody calls any more is wasted work. A usage inventory often cuts a large share of the code.
Modernise legacy without the leap of a full rewrite.
The business system on IBM i (AS/400) or z/OS has run for twenty years and nobody wants to touch it — but it talks to nothing new. Rewriting it all at once is the project that most often fails. There is a middle way: expose what exists as APIs, and convert gradually.
Why the big-bang fails
- Legacy code holds business logic nobody documented any more: rewriting from scratch means reinventing rules whose reason is lost.
- Stopping the old to switch on the new, all in one day, is a risk the business will not accept.
- A «total» automatic conversion produces code that compiles but does not replicate edge cases: parity must be verified, not hoped for.
The gradual way: expose, then convert
First stop being isolated, then replace what is worth replacing.
- Expose legacy programs (RPG/COBOL, ILE service programs) as REST JSON APIs: new software calls them, the old stays in place.
- Map dependencies and measure risk and complexity before converting: start from what pays off, not from what happens to come up.
- Convert sources to modern stacks (Java, C#, Node, Python) with a governed flow, verifying source/target parity.
- Replace one piece at a time, with old and new coexisting behind the same API.
The mistakes that sink projects
«AI converts on its own»
AI speeds things up, but edge-case parity and judgement calls remain to verify: a governed flow, not a button.
«Rewrite first, integrate later»
That order sinks projects. Exposing as APIs first makes the legacy useful now and removes the big-bang pressure.
Have a business system on AS/400 or mainframe that must talk to the rest of the world? Let us look at what can be exposed as APIs now and what is worth converting, with the numbers in hand.
Let’s talkPage updated 23 August 2026.