Legacy Mainframe Modernisation: What to Do When the Original Engineers Are Gone

There's a specific kind of dread that IT managers and CTOs know well: the legacy system that runs a critical part of the business, built decades ago by engineers who have since retired, and nobody left in the organisation fully understands how it works. It runs. It does its job. But nobody wants to touch it, because if something breaks, there's no one who knows how to fix it.

This isn't a niche problem. Across Australia, government departments, manufacturers, utilities, and financial institutions are running mission-critical systems on mainframes, AS/400 platforms, and COBOL codebases that were built in the 1980s and 1990s. The systems work, but the institutional knowledge of how they work has walked out the door.

The Fear Factor

The reason these systems don't get modernised isn't technical — it's fear. The business logic embedded in a 30-year-old COBOL program wasn't documented when it was written, and the only people who understood it are gone. A traditional modernisation approach would require someone to manually read and understand every line of code, map every business rule, and then rebuild it from scratch. That's expensive, risky, and slow.

So instead, organisations do nothing. They keep the mainframe running, pay increasingly expensive maintenance contracts, and hope nothing breaks. Every year, the risk grows — the hardware gets older, the support contracts get more expensive, and the pool of people who understand these technologies shrinks further.

How AI Changes the Equation

AI-powered code analysis fundamentally changes what's possible with legacy modernisation. Instead of requiring a human to manually read and interpret thousands of lines of COBOL or RPG code, AI can analyse the entire codebase and extract the business logic, data flows, dependencies, and processing rules embedded within it.

This doesn't mean the AI magically understands the business context — you still need domain experts to validate the findings. But it compresses what was previously a twelve-month documentation exercise into weeks. The AI identifies every decision branch, every calculation, every data transformation, and maps them into a structured format that humans can review and verify.

Two Paths Forward

Once the legacy system's business logic is mapped, there are two approaches to modernisation.

The first is incremental modernisation: wrapping the legacy system in modern APIs so that other systems (including AI) can interact with it. The mainframe keeps running, but it's no longer isolated. New applications can read from and write to it through modern interfaces. This is lower risk and can be done while the system continues operating.

The second is full migration: rebuilding the system's functionality on a modern platform (PostgreSQL, cloud infrastructure, modern application frameworks) using the mapped business logic as the specification. This is higher effort but eliminates the legacy platform entirely.

Most organisations start with the first approach and move to the second over time, which reduces risk and spreads cost.

What Systems Can Be Modernised This Way?

This approach works with IBM mainframes, AS/400 and iSeries platforms, COBOL and RPG codebases, FoxPro and dBASE applications, legacy SQL Server environments, proprietary industry-specific software, and custom-built systems with no documentation. If it stores data and processes business logic, it can be analysed, mapped, and modernised.

The Cost of Waiting

Every year you wait, the risk increases. Hardware failures become more likely. Support contracts become more expensive. The pool of available expertise shrinks. And the longer you wait, the more expensive eventual modernisation becomes, because the system continues to accumulate complexity.

The first step is always a discovery audit — a structured assessment of the legacy system that maps its scope, complexity, and the most practical modernisation path. This gives you a clear picture of what you're dealing with and what it will take to address it, before committing to a full project.