Imagine inheriting a mainframe environment with no reliable documentation, no accurate system model, and no access to the original IMS data-access layer. Sound familiar? That was exactly the situation we faced in one of our recent projects.
We had COBOL. And that was about it.
The business still relied on the system every day, yet most of its critical knowledge was buried deep within programs, copybooks, JCL, files, screens, and database calls that few people had examined in years. To make matters even more challenging, this was a business-critical module that would need to support the organization for years to come. A “do nothing” approach was simply not an option.
Management recognized that the risks associated with limited system knowledge were no longer sustainable and engaged our team to stabilize the application, reduce operational uncertainty, and make it manageable again.
Before we could modernize the system, we first had to understand it.
To tackle this challenge, we turned to Carbon.modernize, our methodology built on CROZ’s hands-on experience.
Carbon.modernize combines deterministic mainframe preprocessing with AI-assisted analysis techniques to deliver a deep, comprehensive understanding of legacy systems. By uncovering software flows, dependencies, and embedded business logic, it provides complete visibility into the application landscape while significantly reducing manual analysis effort through automation and knowledge reuse.
What followed was a journey of discovery, one that transformed a collection of disconnected legacy artifacts into a clear, navigable map of the system.
Step 1: Rebuilding the Story from Code
We quickly learned that reading one COBOL program at a time would not work.
Logic jumped through GO TO chains, shared working storage, multiple entry points, and long paragraph sequences that didn’t look anything like a business process. One operation might start in one program, validate in another, hit the database in a third, and finish somewhere else entirely.
The first job for Carbon.modernize was to bring order to this chaos.
It collected everything it could see, programs, copybooks, jobs, database operations, files, screens, and shared data structures, and stitched them into a connected system view instead of a pile of isolated source files.
Even without the original IMS access layer, Carbon.modernize could infer how the database was used by following keys, record access, status checks, and later data usage in the code.
Slowly, a picture emerged: Not just what the code said, but what the system actually did.
In one core process, a single IMS call was surrounded by dozens of flags, counters, and GO TO branches. At first glance, it looked like defensive error handling with some retry logic. Only after Carbon.modernize linked the surrounding paragraphs, the calling jobs, and the later data usage did the real meaning become clear: The code was enforcing a strict update window on a specific set of agreements, silently rejecting changes outside that window. Without that reconstruction, we would have either reproduced unnecessary complexity or broken a subtle business rule.
Step 2: Separating Business from Noise
Once we could follow the flows, a second problem appeared: Most of the code was not business logic.
It was technical scaffolding, record movements, platform-specific flags, navigation through IMS, defensive checks, and error handling. Somewhere inside all that sat the real rules that mattered to the business.
Carbon.modernize treated this as a sorting job:
- What is true business behavior that must survive modernization?
- What is technical behavior that still matters (consistency, order, recovery)?
- What is just legacy implementation detail we should not copy?
Care for an example? There was a nightly file job that appeared to simply consolidate data. The flow and data analysis by Carbon.modernize showed that a small branch inside that job was actually driving a critical notification process for a specific customer segment. That insight turned a “background job” into a visible requirement, ensured a proper design in the new system, and prevented a silent loss of business behavior.
A long chain of paragraphs walking through IMS records might boil down to a simple sentence: “Find the agreement, make sure it can be changed, and decide what to do next.”
That sentence is what we want in the new system, not the old mechanics that happened to implement it.
Step 3: Using AI Without Losing Control
At this point, AI could have easily become a dangerous shortcut.
Throwing a large COBOL program at a generic model and asking “explain the business logic” sounds attractive, but it ignores jobs, copybooks, interfaces, and data context that sit outside that file.
Carbon.modernize took a different approach.
Standard analysis tools and generic AI models tend to treat each program, job, or file in isolation. They can highlight syntax, detect patterns, or propose refactorings, but they rarely understand how a specific IMS call, a flag, or a paragraph chain fits into the wider business context. Our custom approach starts from a deterministic system map and then uses task-specific agents on top of that context. That combination is what allows it to answer questions such as “is this rule business-critical or just technical scaffolding?” and “what exactly happens if this path is removed?” questions that conventional tools cannot reliably address at scale.
A deterministic preprocessing layer first prepared the facts: structures, flows, dependencies, data operations.
On top of that, task-specific AI agents did focused jobs, explain a program, reconstruct a logical flow, identify business objects, or review generated artefacts.
When metadata was not enough, they went back to the raw source and verified their conclusions instead of guessing.
The result was not “AI’s opinion about the code”, but repeatable, reviewable analysis grounded in the original evidence.
Step 4: Designing the New System Instead of Translating the Old One
Once we understood the behavior, the temptation was obvious: Translate COBOL to a new language and declare victory.
We did the opposite:
The target system remained in place; the real work was cleaning up the job flows and program structure around it. The only migration step was moving the data-access layer from IMS to Db2.
Carbon.modernize artefacts defined what had to be preserved, operations, decisions, inputs, outputs, data effects, and externally visible behavior.
Then we designed the target system around that:
- Paragraph chains became clear service operations
- Shared working storage became explicit request/response models
- IMS navigation became structured repository queries
The old system dictated behavior, not shape. That gave us room to fix decades of accumulated complexity instead of re-creating it line by line.
Step 5: Proving That We Got It Right
There was no complete specification to test against, so we built one from the system itself.
Carbon.modernize created a traceable chain:
legacy source → logical behavior → requirements → new implementation → tests
Where both systems could run, we executed the same scenarios and compared decisions, outputs, messages, and data changes. When something didn’t match, traceability pointed us straight back to the original evidence and the new code implementing it.
Testing stopped being a final gate and became part of a continuous correction loop.
What Carbon.modernize Really Changed
In the end, Carbon.modernize did more than “explain COBOL”.
It allowed us to modernize a system where:
- Documentation was unreliable,
- The database access environment was missing,
- And business behavior was buried under technical noise.
What made Carbon.modernize particularly valuable was its flexibility. Rather than being a rigid, preconfigured tool, it is a methodology supported by dynamically generated AI-assisted assets. This allowed us to adapt quickly to the unique characteristics of the system, often addressing new challenges within the same day.
As a result, modernization became more than a large-scale translation exercise. It became a controlled, evidence-based process: understand, separate, redesign, and validate.
And for once, we had something rare in large legacy programs: A traceable line from what the old system really did to what the new system is now required to deliver.
This context-aware approach is what sets Carbon.modernize apart. Instead of mechanically translating legacy code and behaviors, it focuses on identifying and preserving true business functionality while separating it from outdated technical implementation details.
