Picture a scenario that we at Hexaware encounter regularly across regulated industries. A financial institution has spent decades running its loan servicing, benefit calculations, or claims adjudication on Natural and ADABAS. The application works. The numbers it produces are correct. But the two or three people who genuinely understand why it produces those numbers are approaching retirement — and no document describes what they know. The organization faces a modernization decision not because the system is failing, but because the knowledge that makes it defensible is about to walk out the door.
The question this raises isn’t “how do we modernize?” It’s more unsettling than that: if nobody can fully explain why the system produces the numbers it produces, what exactly are you modernizing?
This is the question most Natural/ADABAS modernization programs avoid — and the one that determines whether a program actually succeeds.
The Market Moment: Why This Conversation Can’t Wait
Natural and ADABAS have underpinned mission-critical operations for more than 50 years. An independent survey found that 98% of ADABAS & Natural customers base their strategic and business-critical applications on the platform. This isn’t a niche legacy problem. It’s core infrastructure across banking, insurance, public sector, and healthcare.
Three developments have turned a long-running strategic question into a structural one.
First, Software AG spun off Adabas & Natural as a standalone business in January 2025, following Silver Lake’s acquisition of Software AG in 2023. For enterprises in regulated industries, ownership changing twice in three years is no longer a footnote. Regulators across major markets now require financial institutions to formally assess and document their exposure to critical technology providers. The EU’s Digital Operational Resilience Act (DORA), the US Federal Reserve, FDIC, and OCC’s 2023 Interagency Guidance on Third-Party Relationships, and Canada’s OSFI Third-Party Risk Management guideline all point in the same direction. That assessment reads differently than it did in 2022 — and someone has to write and sign it.
Second, with Natural/ADABAS now operating as a standalone business under private equity ownership, enterprises face a structural shift in commercial exposure. A focused PE owner of a maintenance-heavy legacy platform typically runs it for cash — which shows up at renewal as a firmer pricing posture and less room to negotiate than a diversified vendor would allow. For Natural/ADABAS customers, where the complexity and cost of migration creates significant lock-in, that dynamic points toward materially higher licensing costs at each renewal cycle. Every year the modernization decision is deferred is another year of exposure to that pressure.
Third, the talent clock is running faster than most roadmaps acknowledge. The developers who understand these systems are approaching retirement. Their replacements show little interest in Natural or mainframe technology. The window for knowledge transfer — never wide — narrows every quarter.
The urgency here isn’t primarily about cost or agility. It’s about governance, provenance, and who is still in the building.
The Real Problem: It’s Not The Code, It’s What The Code Means
Most modernization conversations start with the application. The right place to start is the person.
Natural applications in regulated industries aren’t software in the conventional sense. They’re statute, policy, and decades of institutional memory — compiled. In public-sector benefits systems, every legislative amendment since the late 1970s exists as another conditional branch, written by a developer who has long since retired. In insurance, run-off book logic encodes product terms from policies sold in the 1980s that must still pay correctly in 2045. In banking, interest accrual logic determines the numbers that flow into regulatory submissions.
The law is documented. The implementation of the law is not.
Much of that implementation exists only in the heads of a shrinking pool of specialists. Natural developers are rarer than COBOL specialists, and the language’s density and idiosyncrasies mean the codebase is genuinely difficult to navigate without years of direct experience. Almost none of that experience is documented. The logic lives in people, not in manuals — and when those people retire, it doesn’t transfer. It disappears.
This creates a specific governance problem that code conversion alone doesn’t solve. In banking, the Basel Committee on Banking Supervision’s BCBS 239 standard requires institutions to demonstrate risk data aggregation and lineage — not assert it. If loan logic is undocumented Natural, that lineage can be described in a meeting but not evidenced in an audit. In healthcare, every adjudicated claim is a decision that may need defending in a Centers for Medicare & Medicaid Services (CMS) certification review or False Claims Act inquiry. In transportation, maintenance intervals are safety-certified logic; proving equivalence after any modification isn’t optional — it’s a regulatory requirement.
When someone asks why the system produced a particular number — in court, before a regulator, or in a safety audit — “a person used to know” isn’t a technical limitation. It’s a governance failure.
Why The Most Common Approaches Leave This Gap Open
Four paths dominate the Natural/ADABAS and broader mainframe modernization conversation. Each leaves the core problem unresolved.
The traditional manual modernization path. The long-established approach relies on analysts and developers manually reading the legacy codebase, interviewing subject matter experts, and translating what they find into a modern language and architecture. It is the most thorough path in principle and the most resource-intensive and time-consuming in practice. Critically, it is only as complete as the knowledge transfer that underpins it. Undocumented edge cases, embedded exceptions, and behavioral nuances the SME never articulated, or didn’t know to articulate, survive into the new system undetected. The process depends on the very people it is racing against.
The COTS replacement. For commoditized functions, packaged software offers a credible target. But for run-off insurance books, entitlement calculation in public sector, and timetable logic in rail, there is no package that absorbs the existing rules. Kyndryl’s 2025 State of Mainframe Modernization Survey of 500 senior IT leaders found that only one respondent out of 500 planned to leave the mainframe entirely, with the dominant shift being toward phased, hybrid approaches rather than wholesale exit. Where the complexity sits in business rules rather than architecture, COTS replacement is rarely the right answer.
The automated code conversion path. Automated tools can translate Natural programs into Java, C# or COBOL, reducing manual effort and offering a faster exit strategy from the Natural licensing model. The converted code runs. Tests pass. But legacy code conversion translates syntax, not meaning. The business rules, calculation logic, and embedded exceptions that made the legacy system defensible arrive in the new language exactly as undocumented as they were in the old one. An auditor asking why the modernized system produced a particular number gets the same answer they would have gotten before: a person, or a guess. The governance gap doesn’t close. It migrates.
The AI-led modernization path. The most recent evolution in the space, AI-led modernization promises to compress timelines further — using large language models to assist comprehension, accelerate code generation, and reduce manual effort. IBM Research (arXiv:2504.10548) found that in COBOL-to-Java translation, LLM-generated code “cannot be trusted to correctly translate the original code,” making manual validation a necessary but labor-intensive step. The same principle applies across legacy migration contexts. Gartner has warned that nearly 70% of AI-driven mainframe modernization projects are expected to fail, largely due to overreliance on generic generative AI models that produce inconsistent and non-certifiable outputs — a finding cited by multiple modernization vendors active in this space. Speed of conversion is not the constraint. Proof of equivalence is.
The gap all four options share: none of them produces a document — for the auditor, the regulator, the safety authority, or the court — that explains why the system behaves as it does.
What Any Credible Approach Must Do
The distinction that matters isn’t between legacy system modernization approaches. It’s between vendors who convert code and those who first understand what the code means.
Any approach that takes both knowledge and proof seriously has to meet three tests before it earns confidence in a regulated environment.
- It must build a genuine understanding of what the legacy system actually does — at the level of business rules, calculation logic, and embedded exceptions — before touching a line of code.
- It must establish, with real production data rather than synthetic test cases, that the modernized system produces the same output for every input the legacy system would have accepted.
- And it must create a machine-readable record of what the logic does and how equivalence was established — the document that answers the auditor, not a person who happens to still remember.
These aren’t project milestones. They’re the outputs that make modernization defensible to a board, a regulator, and a safety authority. Without them, conversion and modernization are the same word.
How Hexaware Addresses Each of Those Gaps
Hexaware encounters the opening scenario — systems that work, knowledge that’s leaving, modernization decisions that keep getting deferred — as a recurring pattern across banking, insurance, public sector, and healthcare. The honest answer to the central question this blog raises is not that anyone can retroactively trace a legacy number to the rule that produced it. In most Natural/ADABAS environments today, that trail simply doesn’t exist in writing. What Hexaware does is ensure it doesn’t disappear entirely — and that in the modernized system, it exists by design.
The knowledge that’s leaving can be captured before it goes. The first stage of every Hexaware Natural/ADABAS engagement is comprehension, not conversion. Zerovity™, Hexaware’s AI delivery layer, parses Natural programs and Adabas schemas to build a knowledge graph that maps control flows, business rules, data lineage, and dependencies — the same information a retiring subject matter expert carries, made systematic and searchable. That knowledge graph is the substrate for the business blueprint, the test scenarios, and the transformation guardrails that follow. It turns tacit knowledge into structured, transferable documentation before it walks out the door.
The business blueprint is the audit artifact. Zerovity™ formalizes what the application does into a business blueprint: domain rules, calculation scenarios, inputs, outputs, integrations, and the decisions about what to preserve, what to retire, and what to redesign. This is the document the preceding sections described — the evidence trail that answers the court, the regulator, or the accreditor. It exists because the comprehension phase produced it, not as a retrospective exercise.
Equivalence is proved with real production data, not just test suites. Zerovity™’s agentic test transformation captures existing test scenarios and real production records, then runs them through legacy and modernized code simultaneously. Cutover happens only once outputs match. In Hexaware’s airline modernization engagement — a crew scheduling and payroll platform built on decades of hardcoded Natural subroutines and Adabas data — the team captured thousands of real pairing and layover records and ran them through the new microservices. They moved to production only once results matched legacy output exactly. That is functional parity proof, not a QA milestone.
The approach is seam by seam, not all or nothing. Hexaware’s model works one bounded slice at a time — one process, one epic, one domain — each going through comprehension, blueprinting, transformation, and parity proof before the next begins. The airline engagement illustrates why this matters: two earlier attempts — a clean-slate scheduling rebuild and a naive relational migration of Adabas data — both failed because they didn’t capture the edge-case logic embedded in the legacy code before attempting the change. The approach that worked wrapped legacy logic with modern APIs while the mainframe kept processing safely, moving epic by epic with full regression coverage at each step.
The measurable outcomes. Hexaware’s Natural/ADABAS modernization programs have delivered up to 50% total cost of ownership reduction and a 60% reduction in SME dependency — the latter being precisely the metric that matters when the people who understand the system are approaching retirement and no document captures what they know.
To return to the question the opening raised: what exactly are you modernizing? For any legacy application modernization done properly, the answer is the knowledge first — before it leaves — and the behavior second, with proof that nothing was lost in the translation.
The people who hold your Natural/ADABAS logic won’t be available forever. Talk to Hexaware about capturing that knowledge before it leaves, and see what your estate actually does.
