We converted a real IBM i RPG program from fixed format to free format. Same business logic. Same outputs. Nothing else changed.

Maintainability Index went from 80.25 to 85.70. But that number isn't the most interesting part.

The program had originally been generated by AS/SET — which meant a standard conversion approach wasn't going to work cleanly. AS/SET-generated code has its own patterns, its own conventions, its own quirks baked in by the tool that wrote it, not by a person. Converting it by hand would have meant a human working through all of that manually, line by line.

So instead, we took an open-source RPG conversion tool from JCRCMDS and modified it to recognise AS/SET's patterns.

That's what got us to 99.9% automated. What was left wasn't a rewrite — it was reviewing a small handful of exceptions the tool flagged rather than working through it by hand.

Here's the part that never shows up in a metric: once it was converted, you could actually follow the logic. Not because the logic changed. Because you weren't spending half your attention decoding fixed-format column restrictions while trying to understand what the program actually does.

Next time you open an old RPG program and find yourself re-reading the same ten lines just to work out what they do, that's usually not you. That's the format getting in the way of the logic.

We've seen the inverse of this too. On a separate, real 1,600-line program with 27 subroutines, we ran RPG Metrics and found that complexity wasn't distributed evenly at all. One single subroutine had a cyclomatic complexity of 34. The other 26 were far less complex by comparison.

Most legacy risk isn't spread across the whole program. It's usually hiding in a small fraction of it — and you can't tell which fraction without measuring.

Which raises an uncomfortable question: if you haven't measured, what are your assumptions about where your own risk sits actually based on? For most legacy estates, "we know which programs are the risky ones" is a belief, not a finding.

So next time you're looking at a cyclomatic complexity report, don't just check whether the average looks fine. Check whether one number is doing all the damage.

If you want to see this for yourself, both Maintainability Index and cyclomatic complexity are things you can pull for your own RPG programs with RPG Metrics — you don't need a full modernisation project to get a first read on where your own risk actually sits.

That's the actual reason to measure any of this. You stop treating an entire legacy program as the problem when the real risk might be sitting in one small part of it. Modernisation gets much easier to plan when you can see what genuinely needs attention — and what doesn't.

These examples come from real business applications, so the source and identifying details remain anonymised.

Have you actually measured where the risk sits in your legacy programs — or is it still an assumption?