The Keepers of the Mainframe: Who’s up Next?
With the job description of “mainframer” shifting, organizations are urged to prepare for the next generation of technologists
By Craig Mullins
The True Challenge in Modernization Comes Before Conversion
The difficult part is deciding what to convert, and why. The ABC Method — Analyze, Build, Convert — structures modernization as an intelligence problem before an engineering problem. The industry has been slow to accept this. Discussions about AI and mainframe modernization have focused on a primary topic: code conversion. This framing treats conversion as the hardest part of modernization, the bottleneck AI was built to break. It is the most common misconception among leaders approving these projects, and it explains why many of them stall.
Before AI, teams approached this largely by feel. Architects interviewed developers, read source code, traced call stacks by hand, and made educated guesses about which applications were worth the investment. The process took months and still left gaps. Knowledge lived in the heads of developers who had maintained the same programs for twenty years. Changing that code meant trusting memory over documentation, because the documentation rarely existed.
That helps. A developer facing thousands of lines of undocumented COBOL can get oriented in minutes rather than days. But source code captures only the logic as written. It does not reveal which programs run most often, which fail in production and why, which consume a disproportionate share of maintenance effort, or which developers hold knowledge that no one else has. The intelligence needed for sound modernization decisions lives in runtime behavior, development history, and operational telemetry, and most AI tools cannot reach it.
This gap shapes where AI delivers in modernization, and where human judgment still carries the weight.
The conditions for success are the same across all of them. The input must be clean, scoped, and understood before AI touches it. When teams hand AI a complex, undocumented program without first establishing what it does and how it connects to surrounding systems, the output reflects those gaps faithfully.
Refactoring before conversion is not a new principle. Developers have understood for decades that improving architecture before changing language produces better results than changing language and hoping the architecture follows. AI has raised the stakes by making conversion faster and cheaper, which tempts teams to treat analysis as optional preparation rather than the core of the work. According to the Forrester Consulting Total Economic Impact™ Study of BMC AMI DevX, organizations can complete 3x to 15x more code changes per year — a result of the architectural clarity the analysis phase produces before conversion begins. Projects that reach outcomes like these resist the temptation to skip ahead. They invest in analysis first, treat architecture improvement as a prerequisite, and use AI for conversion only once scope is understood and structure is sound.
Teams begin by building a data-driven picture of their portfolio: identifying which applications carry the most maintenance burden, mapping how programs execute in production, explaining business logic in natural language, and generating formal specifications that define what each program must accomplish. The Build phase improves architecture before any language change, breaking monolithic structures into modular components and removing accumulated technical debt. Conversion then targets the programs where the investment pays off, producing modular, well-documented code that development teams can maintain without inheriting the problems fast AI translation tends to leave behind.
Measuring success at the portfolio level requires looking beyond lines converted. Organizations that treat modernization as a business continuity program track indicators that connect technology investment to organizational resilience: how much of the application portfolio depends on knowledge held by one or two people approaching retirement, how the cost of delivering a change to a critical application shifts as architecture matures, and how quickly the business can respond to new requirements in previously rigid systems. These questions have concrete answers when analysis begins before conversion does.
The stakes around institutional knowledge are specific. Nearly half of enterprises report mainframe expertise approaching retirement. A product development manager at a financial services firm, interviewed for the Forrester Consulting Total Economic Impact™ Study of BMC AMI DevX, put the risk in direct terms: "200 years of knowledge walks out the door with me," they said, describing their urgency to get AI-assisted code explanation in place before retiring. The Forrester study found that organizations with BMC AMI DevX onboarded new developers 50% faster, reducing average onboarding time from nine months to 4.5 months. The institutional knowledge senior developers carry about how applications behave in production, not just what they contain in source, is the asset most at risk. AI can accelerate the preservation and transfer of that knowledge. It cannot decide which knowledge matters most or where to act first.
Conversion speed is measurable and straightforward to demonstrate. The intelligence behind the decision about what to convert is harder to show, and it is what determines whether the investment holds.