Ron Rabinowitz, CEO of OpenLegacy, on Making Legacy Systems AI-Ready

I have built my career within large global enterprises, including 15 years at Procter & Gamble, giving me firsthand experience with the challenges of legacy technology debt and its impact on business agility. Our management team also brings deep expertise in IBM and other legacy systems.

Today, standing still is no longer an option. AI and agent-driven workflows require immediate access to core data and business logic. When this logic remains locked in legacy systems, organizations cannot keep pace with AI demands. At OpenLegacy, our goal is to provide enterprises with a secure path to modernize and access their legacy systems, enabling them to compete in an AI-driven market without compromising business continuity.

Previous cycles, such as SOA, cloud adoption, and digital transformation, followed a familiar pattern: a new technology emerges, consulting support grows, and over time, urgency settles into a manageable roadmap. Organizations could adapt and plan, often with a multi-year timeline.

AI is different because it does not wait for your roadmap. The pressure now comes from internal business units, not external vendors or analysts. For example, finance teams may want to automate reconciliation if they can access real-time mainframe data, while risk teams may need immediate transaction data for modeling. Customers increasingly expect the same AI-powered, real-time experiences they receive from digital-native companies. They expect faster responses, personalized services, and seamless interactions, regardless of where the underlying data resides. This creates a sense of urgency: every month without a solution increases the risk of falling behind competitors that have already modernized and are delivering on these expectations.

From the inside, this shift feels different because it is no longer just a technology project; it is a business constraint. Often, those most familiar with the mainframe and its design decisions are excluded from key discussions. This is as much a cultural issue as a technical one, and it cannot be resolved simply by purchasing new software.

In the early phases, coexistence means legacy and cloud-native services running side by side in a single, governed environment—not a disruptive "big bang" cutover. In practice, the organization exposes its legacy systems as modern APIs and moves business processes into AWS-native services one at a time, delivering value with each step rather than waiting years for a finish line.

This approach is especially important as enterprises prepare their data and logic for AI. Even before major workloads are migrated, the legacy core becomes accessible to cloud-native and AI applications. Operations continue on the system of record, allowing organizations to innovate immediately without relying on a single migration event.

The most common first step is to expose a core inquiry transaction, such as customer account data, policy status, or claims history, that typically receives many daily requests through batch processes or manual workarounds.

For example, a large insurer may have agents checking policy status via a decades-old terminal emulator connected to a CICS transaction that holds the authoritative data. However, their new customer portal and chatbot cannot access this transaction, and the data team relies on nightly exports that are always outdated.

The initial step is to wrap the CICS transaction as a REST API, which usually takes days of configuration instead of months of development. The mainframe program stays unchanged. A documented, governed interface is now available for modern systems. Within weeks, the customer portal can show real-time policy status. The chatbot can answer status questions directly. The data team can access on-demand data feeds instead of waiting for batch processing.

This step is significant not for its scale but because it shows the value of modernization to stakeholders beyond IT. Business leaders see tangible results. The conversation shifts from "we're modernizing the mainframe" to "the mainframe is now part of our digital and AI capabilities." This visibility often increases support for the program.

The incremental path carries real risks, most of which are related to discipline and momentum rather than technical challenges.

The first risk is integration sprawl. Handling each increment as a separate, point-to-point solution can result in numerous custom integrations that are difficult to manage, effectively recreating legacy complexity. The second risk is loss of momentum; after initial successes, organizations may become complacent in a hybrid state, incurring ongoing costs without a clear end goal. The third risk is governance: a hybrid environment requires clear ownership of data, security, and the system of record from the outset to maintain accountability.

These risks do not justify avoiding the incremental path; rather, they highlight the need for a disciplined approach. We address them by automatically generating integration assets, sequencing work according to a defined target architecture, and treating the hybrid period as a transition with a clear destination. When managed properly, the incremental path presents less risk than a big-bang approach. If handled carelessly, it only postpones existing issues.

The clearest early warning sign is when the integration layer is no longer viewed as a bridge but as the final solution. Statements such as "we've got APIs now, the business has what it needs" indicate that the migration program has stalled. The mainframe continues to run core processes, the API layer merely masks it, and there is no active effort to move workloads. A migration that's perceived as "complete enough" becomes a source of engineers for other priorities. Once that starts happening, the program rarely recovers its original pace.

A third sign is the loss of a clear decommissioning plan. Every migration program should specify what will be turned off and when. If this answer becomes vague, it often signals that the organization no longer expects to fully decommission the mainframe, thereby reducing urgency across the program.

Restoring momentum typically requires executive intervention rather than a technical fix. Leadership must reaffirm that mainframe cost-reduction or decommissioning targets remain valid and on schedule, then re-sequence the migration accordingly. The primary challenge is often organizational commitment, not technical execution.

Complexity spikes the moment integration is treated as a series of ad-hoc manual patches. Bridging two systems by hand is manageable; doing it across dozens of modules becomes an operational liability.

The shift teams need to make is from bridging the old to designing the target. Instead of building disposable connectors, you use AI-driven analysis and OpenLegacy alongside AWS Transform to deeply understand the existing system and design the cloud-native, AI-first end state up front. The integration assets you generate along the way aren't throwaways; they're the building blocks of that future architecture. The toolchain absorbs the underlying complexity, so the middle layer becomes a structured path to the target rather than an accumulating tax.

Once core transactional logic is exposed through clean, structured APIs, it becomes directly accessible. Agent-driven workflows can trigger business processes natively, eliminating the need for screen-scraping workarounds. Therefore, the gap does not lie in execution.

The gap lies in context and semantics. Mainframe code often lacks modern documentation, and outdated variable names may indicate what a rule does but not its purpose. We address this by applying AI analysis during ingestion, reading the source code, and automatically generating well-documented, context-rich metadata for each API.

After that, it's up to the customer how to handle the logic: keep it on the mainframe, move it to the cloud as is, or redesign it for a modern setup. We provide the visibility and connectivity, and they make the decisions. This is how decades of locked-up transactional history become something AI can actually use.

In reality, most teams make this decision too quickly and often default to preservation because it feels safer. However, preserving logic that is not understood does not reduce risk; it merely shifts it. The uncertainty moves from COBOL to Java, and the advantage of a proven mainframe environment is lost.

The key question is whether you have behavioral evidence, not just documentation or code comments. If you can run both the old and new systems with the same inputs and compare outputs, you can confidently preserve and migrate the logic, as you have a method to detect any differences. In this case, understanding the original intent is less critical if empirical equivalence can be verified.

If behavioral equivalence cannot be established due to environmental factors, stateful logic, or inaccessible data, it is important to reassess whether the business rule implemented by this logic is still relevant. Often, the logic may reflect outdated regulatory requirements, obsolete products, or workarounds for systems that have since been replaced.

Migration is an opportunity to address these questions, but only if teams are willing to pause and examine them, rather than using "we can't explain it" as justification to carry logic forward unchanged.