As part of our Summer 2026 release of Imogen, our mainframe modernization automation platform, we can now incorporate extracted business rules from AWS Transform directly into Imogen. This follows a similar integration with Google Mainframe Assessment Tool (MAT)  in our Spring 2026 release.

In this post, we explain what that integration does — and why verification is non-negotiable when it comes to building critical systems from extracted business rules.

What AWS Transform's BRE does

AWS Transform's Business Rules Extraction (BRE) reads legacy source code and produces a structured, plain-language map of the application, organized from lines of business down through business functions, features, and component-level rules. For planning, scoping, and wave sequencing, this is a real improvement over asking engineers to manually reverse-engineer intent from decades-old code.

‍

‍

The coverage problem

BRE distills the business rules embedded in the code, which is what makes it so useful for planning: it surfaces a representative subset of the conditional logic so teams can scope and sequence the work. But that same selectivity means the implementation details underneath those rules, and the tests needed to confirm they're fully captured, still require separate enumeration. File organization, numeric encoding, subroutine call semantics, and runtime error handling are part of how the program behaves, but because they're not labeled as "business logic," extraction has no reason to surface them.

‍

‍

Passing tests only matters once you know those tests fully capture the behavior that is important to the system. Coverage is only meaningful when you can measure the completeness of this behavior being modeled; otherwise, you're writing a rubric you know you can pass, but may not really test all the edge cases of your live system. 

When teams feed extracted rules into a second LLM pass to generate modern code, the candidate code never runs against the actual behavior of the actual program. If you’re trying to build a new system without full coverage of the live behavior down to the implementation details, you will be building on a system that, while internally consistent, is highly likely to be wrong about things like encoding, file organization, external call semantics, and runtime integration. These elements represent the difference between a smooth cutover and one that will take weeks or months to unpick.

For more technical detail, read our more detailed whitepaper, Mainframe modernization is a verification problem.

‍

‍

What verification against the running system looks like

That’s where Imogen comes in. It’s built on the premise that the only way to confirm behavioral equivalence is to use the live behavior of the original program as the comprehensive  specification. Once a migration plan is in place, Imogen will rapidly recreate an exact behavioral and functional replica in modern code, which makes reimagining far safer and more reliable.

Coverage is meaningful because you’re covering the live behavior of the system, based on testing for all the live behavior of the system. The same input flows to both the original COBOL and the candidate modern code, and their outputs are compared at the byte level. Those inputs are drawn from production-representative data — not hand-crafted test cases — so the comparison reflects actual program behavior across the full range of real-world conditions, not just the scenarios a developer thought to anticipate.

Any divergence surfaces immediately, regardless of whether it involves a rule that was ever labeled as such. The Imogen platform then uses those tests, code, and a combination of LLMs to automatically implement a modern program that matches the behavior down to the important implementation details like precision and rounding.

With the new integration, the business rules that AWS Transform extracts flow directly into Imogen's overview, providing a clear lineage between rules and the  executable verification layer. These rules are mapped to the code implementations which come out of Imogen, giving you a firm footing for your future architecture.

‍

The integration is simple: simply invoke AWS Transform integration in the Imogen user interface.

‍

‍

‍

Unleashing safe reimagination

BRE is valuable for planning, scoping, and giving business and technical teams a common language. It isn't, however, an entirely safe specification to build a production replacement on: rules need additional details to become a high fidelity implementation, along with tests to confirm behavioral equivalence.

Organizations using BRE output as the basis for reimagining a system that still needs to keep running may be deferring the discovery of what was missed to the moment of cutover, when it’s most inconvenient.

The integration of AWS Transform into Imogen means teams can move directly from extraction into Imogen's automated verification workflow. The planning value of BRE and the rigor of continuous behavioral verification are available in the same place: that is what makes reimagination at scale something you can deliver with confidence.

‍

Learn more about Imogen here, or get in touch to see a full demo.