The IBM i platform has been running enterprise workloads since 1988. Many of the codebases still in production today were written before the developers who wrote them retired. The RPG talent pool that supports them is aging out faster than universities are training replacements. The applications themselves are stable, but the people who understand them are not getting any younger, and the documentation often does not exist in any form a new hire could use.

That is the IBM i talent cliff. Every enterprise IT leader who runs RPG knows it is coming. The question is what to do about it before it arrives.

This guide is for CTOs, VPs of Engineering, and IT Directors at banks, insurance carriers, manufacturers, and other enterprises with IBM i in production. It covers what modernization actually means in 2026, why the old answers (full rewrite, lift-and-shift, gradual rewrite by hand) have all failed at scale, and what the current generation of AI-driven tooling makes possible.

The Talent Cliff Is Not a Future Problem

The average tenure of an RPG developer in a typical IBM i shop is well past 25 years. The youngest cohort entering the field is small. Universities do not teach RPG. The path into the discipline runs through retiring engineers who can mentor, and those engineers are leaving.

This produces three concurrent operational risks:

1. Tribal knowledge loss. Critical business logic lives in the heads of two or three engineers who know what an application does, why it does it, and what depends on it. When those engineers leave, the documentation is whatever they leave behind.
2. Change paralysis. Without confidence in the dependency graph, teams stop making changes. Bugs get worked around. Features get postponed. The application calcifies.
3. Audit and compliance exposure. Regulators ask questions that require traceability. If no one can explain what a program does or what other programs call it, compliance gets harder every year.

None of these risks resolve themselves. Each year they get harder to fix because each year more institutional memory walks out the door.

What Modernization Actually Means in 2026

“Modernization” used to mean one of three things. None of them worked well.

Option 1: The full rewrite

Tear down the RPG application, rewrite it on a modern stack, run them in parallel until the new one matches behavior, then switch over. The theoretical clean break.

The actual outcome on enterprise codebases: the rewrite team underestimates the scope by a factor of two to four. The parallel period stretches from 12 months to 36. Business logic that lived in undocumented places gets discovered the hard way. The original team continues to maintain the legacy system while the new team builds. Costs run into the eight figures. Half of these projects fail to cut over at all.

Option 2: Lift and shift

Move the IBM i workload to a cloud-hosted IBM i or virtualized infrastructure without changing the code. The application keeps running, the infrastructure gets cheaper to operate.

This solves the hosting problem. It does not solve the talent cliff, because the RPG still needs RPG developers. It does not solve the documentation problem. It does not solve the change paralysis. It just relocates the same risks to a different data center.

Option 3: Gradual hand rewrite

Take the RPG application piece by piece, rewrite each program in a modern language, integrate gradually. Theoretically the safest path.

In practice this is the slowest of the three options and the one most likely to stall. Hand rewriting requires the developers doing it to fully understand the original program, which often means stopping to interview the retired engineer who wrote it 30 years ago. Velocity is measured in programs per month, not per week. The backlog grows faster than the team can clear it.

What Changed: Deterministic Context for AI

The shift in 2026 is not that AI can write code. AI has been writing code for several years. The shift is that AI applied to enterprise codebases without ground-truth context produces unreliable output that no compliance officer will sign off on.

What is actually new is the layer of proprietary ingestion that runs before the AI. The current generation of IBM i modernization tooling works in two stages:

Stage 1: Deterministic ingestion. The tool reads the IBM i source code, builds an interconnection graph of every program, file, copy member, and dependency, flags unresolved references, and generates plain-English descriptions of what each program does. This is not AI. It is parser work plus dependency analysis. The output is structured, verifiable context.

Stage 2: AI on top of that context. The AI model (Claude, OpenAI, Gemini, or a model running locally on customer infrastructure) operates with the source code, the dependency graph, and the deterministic descriptions all in scope. The AI is not guessing what a program does. It is being told what the program does and what depends on it, and asked to answer questions or produce modernized output.

This is the difference between a chatbot guessing about your codebase and a system that understands your codebase. The same models, the same prompts, different results because the input is different.

What Modern Tooling Should Do

An IBM i modernization tool worth evaluating in 2026 should do the following:

• Parse multiple RPG dialects. Fixed-format RPG, free-format RPG, RPGLE, RPG IV. Real enterprise codebases mix them.
• Build the dependency graph. Every program, file, copy member, service program, called program, and trigger relationship mapped. This is the structural foundation of every other capability.
• Generate plain-English descriptions. For each program, a description of what it does, what data it touches, what it calls, and what calls it. These descriptions are what allow new engineers to onboard without a retired RPG developer to interview.
• Show readiness status. Programs where the parser is confident, programs where it flagged unresolved references, programs that need human review. Not every program is ready for AI handling; the tool should be honest about which ones are.
• Scope impact of proposed changes. Before you change a field, file, or program, the tool should show you everything else that depends on it. This is what allows safe change to resume.
• Output to multiple targets. Modern RPG (free-format), Python, Java, or another modern language. The right target depends on the customer’s broader stack and strategy.
• Run air-gapped. For regulated industries, the AI models need to run on customer infrastructure with nothing leaving the network. Model-agnostic architecture matters.

The tool that does these things turns “modernize the IBM i” from a multi-year, eight-figure rewrite into a tractable engineering project that can start producing value in weeks rather than years.

What an Initial Assessment Engagement Looks Like

The strongest entry point for an IBM i modernization initiative is not commitment to a full rewrite. It is an assessment engagement.

The deliverable from a properly scoped assessment is a complete inventory of the codebase: every program named and described, every dependency mapped, every unresolved reference flagged, and a written report describing what it would take to modernize. This is the document that the CTO presents to the board. It is the document that drives the budget conversation. It is the document that turns “we should modernize the IBM i eventually” into “here is the scope, here is the sequence, here is the risk, here is the cost.”

An assessment can complete in weeks rather than months because the deterministic ingestion is fast. The AI-generated descriptions and modernization recommendations follow. The output is a real plan, not a sales document.

What to Look for in a Vendor

Vendors in this space split into three categories:

1. Consulting firms that do IBM i modernization as a service. Fresche Solutions is the long-established example. Strong domain expertise, expensive, slow, manual.
2. Platform vendors with broader portfolios. Precisely is the example. Strong data integrity tooling, broader than IBM i alone. May not be the deepest in pure modernization.
3. AI-first modernization tools. The new category. AS/Forward from Golden Path Digital is in this category. So are emerging competitors like Ozgar. IBM has its own AI-driven tooling. The differentiation is in how each one handles the context-and-orchestration layer between the source code and the AI model.

The questions worth asking any vendor in this space:

• How does the tool handle dependency resolution before the AI sees the code?
• Can it run air-gapped on customer infrastructure?
• Which RPG dialects does the parser support?
• What output targets are available (Python, free-format RPG, Java, other)?
• What is the model-backend strategy (Claude, OpenAI, Gemini, local)?
• Is there an assessment-only engagement option, or only full modernization?

Why This Matters Now

The talent cliff was a 10-year problem when the industry first started talking about it. That was 10 years ago. The runway is shorter now. The shops that started modernization in 2018 are well into the work. The shops that have not started are running on borrowed time measured in retirements.

The good news is that the tooling available in 2026 is meaningfully better than what existed in 2020. Deterministic ingestion plus AI handling did not exist as a productized category five years ago. It does now. The economics of modernization have shifted from prohibitive to tractable.

Golden Path Digital and AS/Forward

Golden Path Digital is the software company behind AS/Forward, an IBM i modernization tool built on the deterministic-context-plus-AI architecture described above. AS/Forward parses 6 RPG dialects, builds the full dependency graph, generates plain-English program descriptions, and runs air-gapped on customer infrastructure with model-agnostic backends. The platform is the subject of 1 US patent pending. It is currently in evaluation with IBM i consulting firms and enterprise IT teams in banking, insurance, and manufacturing.

The assessment engagement is the recommended entry point for any enterprise considering modernization. The output is a complete inventory of the codebase plus a written plan, delivered in weeks rather than the months a traditional discovery would take.

What to Do Next

If your enterprise runs IBM i in production and the talent cliff is on your roadmap, the next step is a conversation. Golden Path Digital offers initial assessments to enterprise IT teams evaluating modernization options. The conversation is free. The output is an honest read on your specific environment and what a path forward looks like.

Visit goldenpathdigital.com/as-forward/ for product details, or reach out via the contact form to schedule a discovery call.

Golden Path Digital is an enterprise software and AI modernization company headquartered in Hot Springs Village, Arkansas. AS/Forward modernizes IBM i and RPG codebases. Laravel Ascend automates Laravel application upgrades. QuantaPath AI delivers HIPAA-compliant CRM and workflow automation. Serving enterprises nationwide with US-based delivery and air-gapped deployment options. 1 US patent pending.