The Space Between Analysis and Transformation

For most of our careers we have worked inside the codebases that quietly run the economy. The COBOL that processes the insurance claim. The RPG that moves the order through the warehouse. Systems that have run correctly for thirty and forty years, and that almost no one fully understands anymore.

Across decades spent inside the IBM i and mainframe world, at platform vendors, at DevOps and integration companies, and in modernization work, we have sat with a lot of teams who wanted to do something with those systems. Move them to the cloud. Expose them through APIs. Refactor them. Or in many cases just keep them running safely while the people who built them retire. Different goals, different industries, different budgets. And almost every one of them stalled at the same place.

We want to describe that place honestly, because we think the industry keeps misdiagnosing it. Then we want to explain the approach we landed on, and why it looks different from most of what is sold as modernization today.

The problem is structural, not technical

When a modernization program stalls, the after action review usually blames one of two things. Either the tooling was not good enough, or the team did not have enough RPG and COBOL talent. In our experience both of those are symptoms. The real problem sits underneath, and it is structural.

A monolithic COBOL or RPG application is not just large. It is entangled. Core business logic is fused directly into the display layer. There are no clean seams and no defined interfaces, just decades of accumulated coupling. Shared indicators and cross module references create dependencies that no documentation captures, because that documentation never had to exist. The people who wrote the code knew how it fit together. That knowledge lived in their heads and in their habits, and it was enough, right up until it was not.

So when a team decides to change one part of the system, the change ripples in ways no one can predict. A field that looks local turns out to feed a calculation three programs away. A subroutine everyone assumed was dead is quietly load bearing. The estimate to safely touch the system balloons, and somewhere in that ballooning the program loses its nerve.

Here is the part that matters. Every path forward runs through the same door. Whether a team wants to optimize the code, refactor it, replatform it, migrate it, or simply maintain it without breaking anything, they first have to understand the structure. That understanding step is where programs stall, and it stalls because doing it by hand does not scale. Even with the original SMEs in the room, you cannot build a modernization program at the size of a real enterprise on top of a dependency map that only exists in a few people's memories.

We know this because for years we did that mapping by hand. We traced the dependencies ourselves, one reference at a time, across real customer environments. It worked, and it did not scale, and it kept hitting the same ceiling. That experience is the entire reason we built what we built.

Why the current playbook falls short

The market has largely split the problem into two camps, and we think there is a gap between them that no one is serving well.

On one side are the analysis platforms. They do genuinely hard and valuable work. They map dependencies, cross reference objects, and group programs into application areas. That analysis is real, and it is the necessary foundation. But analysis stops at a picture. It tells you what the system looks like. It does not change the system into something you can safely act on.

On the other side are the conversion tools. They take the monolith and try to move it straight to a modern language and architecture in one leap. COBOL to Java. RPG to something web native. The ambition is right, but the physics are hard. When you jump from an entangled monolith directly to a modern target, you inherit all of the original coupling and carry it across the boundary. What comes out is technically modern and functionally a mystery, and the effort required to trust it grows until it swamps the project.

So teams are handed a very good map and a very ambitious destination, with nothing that safely gets the code from one to the other. That space, between analysis and transformation, is where we chose to work.

Plausibly correct is not good enough

The obvious question in 2026 is why not point a large language model at the code and let it modularize everything. We spend a lot of time on this question, so let us be direct about it.

The models are good. They are genuinely impressive at producing output that looks right. But looking right and being right are different claims, and for systems that pay claims, move money, and run supply chains, the gap between them is the entire risk. The hard problem with AI on structural transformation was never generation. It is verification. How do you know the output preserved the original logic. How do you prove that nothing was quietly dropped or subtly changed. A model that is confident and wrong is more dangerous than no tool at all, because it fails in ways that pass a casual review.

The phrase we use internally is provably correct, not plausibly correct. We were not willing to build something that produces plausible modernized code and asks the customer to hope.

The approach we landed on

So we built the step in the middle, and we built it to be verifiable from the ground up.

Instead of moving from analysis directly to conversion, we do a structural transformation of the existing code, in the same language. Monolithic RPG becomes modularized RPG. Monolithic COBOL becomes modularized COBOL. Same language out, but now with clean boundaries and every dependency accounted for and made explicit instead of implicit.

The architecture is deliberately not AI first. A deterministic parser, written in Haskell, maps every structural dependency in the code without any AI involvement at all. Haskell matters here because it is a formally verified language, which means the parser itself can be reasoned about and proven correct. The dependency map is not generated by a model and hoped to be complete. It is computed the way a compiler resolves references, deterministically and exhaustively.

AI has exactly one job in the pipeline, and it is the job it is actually good at. It recognizes intent, interpreting what a section of code is meant to do at a business level. It never decides what the code depends on. And after any decomposition, a compiler driven feedback loop validates that the transformation preserved the original logic before anything ships. Neurosymbolic is the technical name for combining those pieces. We did not arrive at it because it was fashionable. We arrived at it because years of doing this work by hand taught us that nothing less rigorous would survive contact with a real enterprise codebase.

The destination stays yours

The reason we are convinced this is the right layer to build is that modularization pays off no matter what a team does next.

If you want to stay on IBM i or the mainframe and simply make the code easier and safer to maintain, cleanly modularized code with defined boundaries gets you there. If you want to expose business processes as APIs, you now have processes with real edges to expose. If you want to convert to a modern language, you can hand a conversion tool well bounded modules instead of a monolith, and convert one business process at a time instead of betting the company on a single cutover. If you want a hybrid, you have the seams to draw the line wherever you need it.

Modularize first, and the destination is the customer's choice. That is not a slogan we reverse engineered. It is the conclusion we kept reaching from the other direction, watching good teams get stuck for want of a step no one was providing.

Where this goes

We are not an analysis platform, and we are not a conversion tool. We are focused on the structural transformation step in between, and on doing it with a level of provable correctness that legacy systems have always deserved and rarely gotten.

The systems we are talking about are not going away. They are too correct and too load bearing for that. What has to change is our ability to see inside them and act on them without depending on a shrinking group of people who remember how they work. That is the problem we have spent our careers on, and it is the one we built this company to solve.

If any of this matches what your team is facing, we would like to hear how you are thinking about it. Reach us at info@prysmaifirm.com.