Modularization is the part everyone skips
When the conversation turns to modernizing a mainframe or an IBM i system, it jumps almost immediately to the destination. Cloud. Java. APIs. Getting off the platform. The step that decides whether any of that actually works tends to get passed over, and it is the one we spend most of our time on. Modularization.
Modularization is not a rewrite and it is not a migration. It is taking the business logic that has built up inside these systems over decades and separating it into pieces you can see, understand, and change on their own. In most legacy estates that logic does not sit in neat units. It is spread across programs, woven into the screens, and held together by conventions nobody ever wrote down. On IBM i the rules run through the 5250 display files, the shared indicators, the WORKSTN file, so a pricing rule and the screen it lives behind end up being the same thing. On the mainframe it is BMS maps and CICS. You go to lift one rule out and find it connected to a dozen others you could not see. Pulling that apart cleanly, without changing what any of it does, is the work.
It gets skipped because it is not the exciting part. There is no new platform to point at and nothing new to show for it. So the more common path is to go straight for the destination, usually by having something translate the old code into Java. The teams we talk to who have tried that describe the same result. What comes back is not Java anyone would choose to keep. It runs, but it is a line-by-line transliteration of COBOL, and when the Java developers who would have to own it take a look, they say they would never build it this way. Now there is a second system nobody understands sitting on top of the first one.
There is a quieter problem underneath that. A forty-year-old estate is decades of decisions, most of them undocumented, many made by people who have retired. Some of what looks like a bug is behavior the business built around years ago. When a translation cleans that up, it does not surface in a review. It surfaces later, in a quarter-end run, on a path that fires twice a year, when a number that was right for decades comes out wrong. Which is why the people closest to this code care so much about a difference that is easy to gloss over, the one between something that looks correct and something you can show is correct. On the system that pays the claims or moves the money, only the second one counts. Running some tests is not the same as showing it.
All of that points back to why modularization has to come first, and why it is mostly a structural problem rather than a language one. Before anything moves, you have to know all of it. Every program that calls a rule, every file and field it touches, every indicator it depends on, every bit of state it carried in from whatever ran before. That is structural, not a matter of interpretation, and it is the part people are least comfortable handing to a model, because a model is good at guessing and this is the one place a guess does real damage.
The approach that seems to hold up maps that structure first, deterministically, the way a compiler resolves references, so the starting point is the actual code and not a model's impression of it. The model comes in after that, for the part it is genuinely good at, reading a routine and recognizing what it is for. And every change gets checked against the original before it counts, so nothing ships that cannot be shown to behave the same way. What you end up with is not dramatic. It is the same RPG or COBOL, on the same platform, with the logic finally separated into pieces you can see and a map of how they connect. It is not flashy, but it is the step that makes everything after it possible, whether that is cloud, APIs, a real rewrite later, or just keeping the system safe to change.
We have spent close to thirty years working in these systems, and they have taught us a great deal. Taking that experience and going deep into AI has changed how we think this work should be approached, and we are excited about what we are building now. Thirty years in, the thing we are most sure of is how much there still is to learn, and most of that learning comes from the people who live in this code every day. If you are as interested in this as we are, please reach out.