A midmarket manufacturer discovered that their IBM i developer, with decades of system knowledge, was nearing retirement and facing sudden health challenges. Leadership assumed they would have a 2-7 year window for modernization, but things were changing quickly.

When they looked closely, they realized the developer might not be able to carry the business through that transition. Documentation was sparse, and critical scripts existed only in the developer’s memory.

The systems kept running until something needed to change, and no one understood it well enough to change it safely.

This is becoming increasingly common in the IBM i space.

IBM i runs the core operations of more than 120,000 businesses worldwide, including manufacturing lines, distribution networks, and financial systems, with a reliability record that most platforms can’t match. Organizations stay with IBM i because it works.

The challenge isn’t the platform. It’s what happens when the people who know it best — and the business knowledge that surrounds it — start to leave.

In Fortra’s 2026 IBM i Marketplace Survey of 320 IBM i users, skills shortage ranked as the number one concern for 69% of respondents, displacing cybersecurity from the top position it had held for 9 consecutive years.

This confirms what IBM i practitioners have observed on the ground: the retirement wave is here.

The demographic picture is unambiguous.

A 2025 Procern analysis found that over 72% of IBM i developers are over 50, with 35.8% already 60 or older. Approximately 30% of senior RPG developers have retired over the past 10-15 years, and most who remain are between 60 and 70.

The replacement math is equally stark: the IBM i installed base comprises approximately 120,000 customer sites with an average of 3.2 staff per site, with roughly 384,000 professionals in total. Projected retirements run at approximately 18,000 per year, compared with a current replacement rate of approximately 3,600 per year. That is a 5:1 gap between departures and qualified replacements.

The RPG job market reflects this arithmetic directly. At any given time, there are approximately 30 unique IBM i RPG full-time positions open nationwide, compared to more than 4,000 for C# and Java.

The platform’s learning curve is real but not prohibitive. IBM i’s former Chief Architect notes that teaching an experienced developer IBM i is relatively straightforward. The challenge isn’t that IBM i is hard to learn. It’s that institutional knowledge about your specific environment can only come from the people who built and ran it — developers and the business analysts who configured it alike.

The IBM i skills shortage is real, but that’s not the risk. The actual risk is the accumulated institutional knowledge of how your specific system runs, which is lost when your developers — and the business owners who understand why the system works the way it does — retire.

The organizations that navigate this successfully recognize early enough that the problem is knowledge transfer, not hiring, and act while the knowledge is still capturable.

Why This Is Harder Than It Looks

The standard organizational response to the retirement wave rests on two assumptions: we can hire a replacement, and we have time to plan a transition. Both assumptions are more fragile than they appear. Three complications define why.

1. Skills and Institutional Knowledge are Different Problems

Training programs produce people who can write RPG IV in free form. The 400 School, imPower Technologies, Manta Technologies, and a growing set of university programs are producing new IBM i-literate developers. 

IBM i’s former Chief Architect, Steve Will, stated that teaching an experienced computer professional on IBM i is relatively straightforward. This is true.

It is also irrelevant to the operational risk. A developer trained on RPG IV does not inherit 20 years of custom business logic, undocumented workarounds, or the institutional memory that depends on a library list set up in 1997. They do not know which three fields in the pricing module cannot be changed without triggering a cascade failure across five downstream programs. They do not know that the year-end close includes a manual step added in 2003 that has never been documented.

Nor does a new developer inherit the business context that a departing analyst holds. A developer can eventually learn what a customized program does. Only the business analyst or functional owner who configured it, negotiated an exception into it, or built a workaround for a specific customer contract knows why it exists — and whether that reason still applies today. That knowledge doesn’t live in code, and no amount of code documentation recovers it once the person who holds it is gone.

The skills gap is solvable. The institutional knowledge gap — both technical and business — is not.

Conflating the two is the single most common failure in how organizations plan for this transition.

2. The Timeline is Shorter Than the Planned Retirement Dates Suggest

Senior IBM i professionals are compensated at roughly $105,000/year, while comparable Microsoft .NET developers command $125,000 or more.

That pay gap means the departure risk is not aligned with the planned retirement. An experienced IBM i developer offered a comparable role at open-technology pay does not wait until their planned retirement date.

And sudden health events can close the window without notice.

This midmarket manufacturer case is not unusual: by the time urgency was recognized, the employee was no longer in a position to participate in the transfer.

The best-case scenario for organizations requires a known retirement date. But for most businesses, departures driven by compensation, health, or unexpected circumstances do not provide a runway — leading to a loss of institutional knowledge without a backup plan.

3. AI Documentation Tools Address the Symptom, Not the Cause

IBM’s Project Bob 2.0, which reached general availability in summer 2026, is a genuine advance for IBM i development. It can explain a section of legacy RPG code, generate code from natural language, and convert fixed-format RPG III to free-format RPG IV. 

These are useful capabilities.

But they are not a knowledge-transfer solution. 

IBM positions Bob as a developer productivity tool to help individual developers understand, document, and generate code at the program level. It is not designed to map institutional knowledge across an entire environment.

The knowledge that causes operational failures when a developer leaves is precisely what Bob cannot capture. RPG’s implicit features (the RPG cycle, data areas, and file-level conditioning) remain challenging for current AI models to interpret reliably, particularly in the oldest RPG II and III codebases, where the risk of institutional knowledge loss is highest.

AI tools are a useful supplement to knowledge transfer. They are not a substitute for it, and organizations that wait for AI to solve this problem are taking on more risk than the technology currently justifies.

Why Migration Doesn’t Solve This — It Relocates It

Faced with an aging workforce and a documentation gap, the instinct is to treat the platform itself as the problem: migrate off IBM i entirely, hire from a deeper talent pool, and let the knowledge-concentration issue disappear with the old system.

It doesn’t disappear. It moves.

A migration off IBM i still requires someone to translate 20 years of undocumented business logic into the new environment, and the only people who can do that translation accurately are the same knowledge holders this document is about. Migrating before that knowledge is captured doesn’t reduce the risk; it adds a hard deadline. 

Every workaround, every undocumented year-end step, every “don’t touch those three fields” constraint has to be identified and correctly reimplemented under project pressure by a team that, by definition, doesn’t yet understand the system it’s replacing.

The reliability math cuts the other way, too. IBM i runs the core operations of more than 120,000 businesses precisely because it is stable, low-maintenance, and rarely the source of unplanned downtime.

A migration trades a known, working system for a multi-year project with its own failure modes — cutover risk, data-integrity risk, and a new platform’s learning curve stacked on top of the knowledge-transfer problem, not instead of it.

None of this means IBM i should be untouchable. Modernization — free-form RPG, API layers, and documented code — is part of the long-term answer and is covered later in this guide. But, modernization done after knowledge is captured is a controlled improvement. 

Migration undertaken instead of knowledge capture, on a compressed timeline, driven by workforce anxiety rather than a documented plan, is how organizations trade one form of institutional-knowledge risk for a worse one — with a large project budget attached.

The platform was never the risk. The undocumented knowledge — technical and business alike — is. 

Fixing the underlying problem is the same first step whether an organization keeps its current environment largely as-is or modernizes it in place: capture what’s in people’s heads before it leaves with them.

The Risk Framework

Most IBM i organizations facing this transition are not uniformly exposed. Risk concentrates in six specific dimensions. Understanding which dimensions are active in your environment is the prerequisite for knowing where to direct effort.

Knowledge Concentration

Definition: The degree to which one or two individuals hold critical operational knowledge without adequate redundancy. The average IBM i shop has approximately three programmers. In a three-person team, if one person carries the majority of institutional knowledge, the team that remains after a departure is structurally different.

Observable indicators: One developer who knows the full application layer better than anyone else; batch jobs that require intervention only that person can provide; system recovery procedures that have never been tested without them present.

Operational consequence: When the knowledge holder is unavailable, systems fail in ways that no one else can diagnose. Batch jobs run unpredictably. Integrations break. Year-end processes require steps nobody documented. The first incident after the departure reveals the full scope of the dependency.

Code Documentation Coverage

Definition: Whether your application layer’s business logic exists in the system or only in people’s heads. Seventy percent of IBM i shops rely on homegrown applications built over decades. The 2024 Fortra IBM i Marketplace Survey found that this figure has remained stable, indicating that documentation debt from the original development period has accumulated alongside the retirement risk.

Observable indicators: RPG programs without inline comments or external specifications; batch job sequences with no documented dependencies; pricing or inventory logic with no business rules documentation; CL programs and data queues whose purpose is not formally recorded anywhere.

Operational consequence: When a process fails, the team has no reliable way to diagnose it. Billing cycles stall. The month-end close has undocumented manual steps. New developers discover program dependencies only through production failures.

Modification Drift

Definition: The gap between what your vendor’s ERP documentation describes and what your specific installation actually does, after years of customizations, modifications, and integrations layered on top of the base package. This is distinct from Code Documentation Coverage: even a well-documented vendor system can carry undocumented drift because the documentation describes the standard product, not this installation. It is also not purely a code problem. A business analyst or functional owner who configured a workflow, negotiated an exception into the system, or knows why a customization exists in the first place often holds knowledge no developer ever had, and that knowledge doesn’t show up in code documentation no matter how thorough.

Observable indicators: No current inventory of modified vs. standard programs; customizations undocumented at the point they were made; upgrade history where modification conflicts were resolved informally rather than recorded; EDI or integration code that touches the ERP but isn’t part of the vendor’s supported architecture; no clear record of which business requirement or customer exception a given customization was built to satisfy.

Operational consequence: When the knowledge holder leaves, the team inherits a system that looks like the vendor’s product but doesn’t behave like it. Standard troubleshooting steps and vendor documentation are no longer reliable guides because they describe the base product, not this installation. A support call to the vendor, or a new hire following vendor documentation, walks into logic that was quietly overridden years earlier, with no flag anywhere in the system indicating that. Upgrades become high-risk events instead of routine ones: patches or version updates collide with undocumented modifications, and the person who would normally know which custom programs need to be reapplied or retested is no longer there to say so. The failure mode is a program that runs, produces output, and is wrong in a way nobody catches until it hits the general ledger, a customer shipment, or an audit.

Succession Pipeline Health

Definition: Whether your organization has a credible path to maintaining IBM i capability after the current staff departs. The job market does not provide a backstop here. With approximately 30 unique IBM i RPG positions open nationwide at any given time, an organization expecting to screen 5-10 candidates for an opening will typically find one or two. The “we’ll hire a replacement” assumption requires a talent pool that does not exist at the scale demanded by the retirement wave.

Observable indicators: IBM i team average age is 50 or above; no active investment in RPG or IBM i training for existing staff; recent failed attempts to hire for IBM i roles; team sized so that losing one member would immediately affect operational coverage.

Operational consequence: When a departure occurs, planned or otherwise, no viable replacement is available in time. The external market creates the illusion of a solution that cannot materialize within the required timeline or at the required skill level.

Operational Exposure

Definition: Whether knowledge gaps are already creating friction in current operations. When that person is no longer available, managed friction becomes operational failure.

Observable indicators: Deferred work because only one person handles certain processes; hardware failures or recovery procedures that took longer than expected because of knowledge gaps; active integrations (EDI, API feeds, FTP jobs) that no one on the team fully understands end-to-end; production failures in the past two years where resolution was delayed by knowledge unavailability.

Operational consequence: The operational risk that currently presents as friction becomes an acute failure after the departure event. Response times lengthen. Recovery procedures fail. Systems maintained through informal workarounds have no fallback when the workaround’s author is unavailable.

Compliance Posture

Definition: Whether your IBM i environment can satisfy audit and regulatory requirements for business continuity and disaster recovery. This dimension is often underestimated in most IBM i staffing discussions and is likely to have consequences beyond the IT department.

Observable indicators: No testable, current disaster recovery runbook for IBM i that does not depend on one person’s institutional memory; inability to produce SOC compliance evidence; no documented continuity plan that a new operator could execute independently.

Operational consequence: Auditors no longer accept informal knowledge transfer as evidence of continuity planning. Regulators require testable runbooks, SOC evidence, and documented DR procedures. A single-developer IBM i shop cannot, by definition, produce this evidence. The compliance gap created by an unplanned departure is a regulatory exposure with timeline consequences.

What Prepared Organizations are Doing

The organizations that navigate the retirement wave without operational disruption share a common characteristic: they treat knowledge transfer as a time-constrained project with a fixed deadline. Four strategies define their approach.

Map concentration risk before a departure forces the issue.

The foundation is a knowledge concentration audit: for every critical system, identify the primary knowledge holder — developer and business analyst alike — and, if anyone, the backup. Where the answer to the second question is “nobody,” that is a single point of failure. Before departure, the knowledge holders can validate this map; they can confirm which dependencies are as severe as they appear and flag those that are worse.

If done after a departure, the map is incomplete by definition.

The audit output organizations use most effectively is a prioritized list of the five highest-risk single points of failure, ranked by operational impact if that knowledge were to disappear today. That list drives the documentation sprint that follows.

Execute structured knowledge transfer while the window is open.

Structured transfer looks different from informal mentorship. It targets specific knowledge categories rather than general RPG skills. It pairs the knowledge holder with a designated recipient and sets a schedule.

The practical form: one documented process per month, starting from the highest-risk item on the concentration audit. The documentation does not need to be comprehensive on the first pass. It needs to answer three questions for each critical process: what it does, what can break it, and the three things that cannot be changed without downstream consequences.

An imperfect written record is recoverable. Knowledge that exists only in one person’s head is not.

Mandatory knowledge-transfer phases in modernization projects follow the same logic: veteran developers document business rules, newer engineers shadow the process, and living documentation is created and maintained from the start. Organizations that run modernization projects without this phase often find they have modernized the code while losing institutional knowledge in the same motion.

Engage ERP Managed Services for IBM i before a departure, not after.

When the people who implemented and configured your ERP environment retire, the configuration knowledge, the customization history, and the workflow expertise don’t have to leave with them. 

Companies running their ERP systems on IBM i often use Infor LX or BPCS, two of the most widely used ERP platforms on IBM i.

ERP Managed Services for IBM i covers the application layer directly — the Infor LX configuration, the RPG programs that run your business workflows, the BPCS customizations that encode years of operational decisions, the job streams that process your production schedule overnight, and the EDI environment that connects your ERP to most trading partners you work with.

EDI knowledge is as vulnerable to retirement as ERP knowledge — and most generalist MSPs have no one who can diagnose a trading-partner transaction failure during an overnight batch run before a ship window closes.

This is not the same as knowledge transfer, nor is it infrastructure management. An ERP managed services partner cannot reconstruct undocumented business logic from scratch, but they can work alongside the internal team while the knowledge holder is still present, learning the environment and building genuine redundancy before the departure event rather than responding to a crisis after it.

The timing matters. Organizations that engage proactively give the managed services team the time to understand the environment alongside the internal team, creating real continuity rather than reactive coverage. Organizations that wait for a retirement notice to evaluate their options are already working against the clock.

The organizational pattern that yields the worst outcomes is waiting for a departure before evaluating managed services options. By that point, the knowledge-transfer window is already closing, and the selection process is happening under deadline pressure.

Build long-term resilience through modernization.

The long-term solution to knowledge concentration is reducing the surface area of knowledge that exists only in one person’s head. Free-format RPG conversion improves code readability for incoming developers. API integration layers reduce single-program dependencies. Documented code using tools like Project Bob, combined with human review and architectural documentation that Bob cannot produce, creates a system that a new developer can reasonably be expected to understand.

The goal is not to eliminate IBM i, and it shouldn’t be. 

The platform still runs core operations for more than 120,000 businesses with a reliability record most environments can’t match, and IBM’s continued investment — Project Bob, Technology Refreshes through 7.6, an active developer ecosystem — reflects a platform with a long runway, not a shrinking one. 

The retirement wave is a knowledge problem sitting on top of a stable system, not a reason to replace the system itself. The modernization goal is to reduce dependence on any single individual’s knowledge. Capture the knowledge, and the platform keeps doing exactly what it’s always done.

Implementation Guide

The following sequence addresses the most critical knowledge-transfer risks first, then builds the organizational infrastructure for ongoing resilience. Each phase assumes the previous phase is underway.

PHASE 1 — Immediate (First 90 Days)

These actions should begin regardless of how far away planned retirements appear. The goal is to capture knowledge that cannot be recovered once the person leaves and to identify the exposures that would produce the most immediate operational damage.

Step 1: Run a knowledge concentration audit

For every critical system process, batch job, integration, and application that touches a revenue or compliance function, identify the primary and backup knowledge holders — including business analysts and functional owners, not just developers. A spreadsheet is sufficient. The output you need: a prioritized list of your five highest-risk single points of failure by operational impact.

Who owns it: IT Director or VP of IT.

What good looks like: a completed map with at least one knowledge-holder interview per high-risk item, validated by the knowledge holder.

Step 2: Interview the highest-risk knowledge holders

Ask directly: What do you know that no one else on the team knows? What are the three things in this system that cannot be changed without breaking something else? What are the undocumented year-end steps? What do you wish you had written down two years ago? 

For business analysts specifically: which customizations exist to satisfy a requirement that may no longer apply, and which are still load-bearing?

This conversation produces the list of documentation targets for Phase 2. It also gives the knowledge holder an explicit opportunity to flag risks that leadership may not be aware of.

Step 3: Document the single highest-risk process

Choose the top item from the audit: typically, the batch job or application module that would cause the most immediate damage if it failed and the primary developer were unavailable. 

Document it: inputs, outputs, dependencies, library lists, job queues, known edge cases, and the things that cannot be changed. One process done well, with the knowledge holder’s validation, is more valuable than ten processes done poorly.

Step 4: Test your disaster recovery coverage

Can you produce a tested, current IBM i disaster recovery runbook that a qualified operator could execute without calling the author? If not, that is a compliance exposure today and an operational risk tomorrow. Identify the gaps between your current DR documentation and a runbook that would satisfy an auditor’s request for testable evidence.

PHASE 2 — Near-Term (Next 180 Days)

Phase 2 builds organizational resilience over the next twelve months. The focus shifts from capturing at-risk knowledge to building structures that reduce knowledge concentration over time.

Establish a formal documentation cadence.

Document one critical process each month, beginning with the highest-risk items identified in the Phase 1 audit. Assign ownership, set a monthly review checkpoint, and treat documentation completion as a measurable deliverable. Sustained over twelve months, this reduces exposure more than any single initiative.

VIRTUTEM deploys IBM Bob, IBM’s AI development tool built specifically for IBM i, across its delivery team, accelerating the documentation of undocumented environments and ensuring that the resulting documentation belongs to the client. For organizations beginning a documentation cadence, IBM Bob can generate code explanations and documentation for existing RPG programs in hours rather than weeks, significantly reducing the time required to document each process.

Implement structured mentorship pairing.

Pair the highest-risk knowledge holder — developer or business analyst — with a designated successor or team member. The goal is not general RPG training. The goal is environment-specific knowledge transfer: this system, these dependencies, these edge cases, these business reasons behind them. 

Monthly shadowing sessions on high-risk processes, with the junior team member taking the lead under supervision, is the format that produces measurable results.

Proactively evaluate ERP Managed Services for IBM i.

This is not a binary “outsource everything” decision. The evaluation question is: what would application-layer continuity look like for your specific ERP environment when your senior developer retires, and what does it cost relative to the risk of a reactive engagement after a departure event? Evaluating this before a departure gives you the information, the relationship, and the onboarding time that reactive engagement denies you.

PHASE 3 — Ongoing

Phase 3 addresses the structural conditions that cause the problem to recur. Without this phase, organizations address the current retirement wave and recreate the same concentration risk with the next generation of staff.

Conduct an annual staffing risk review.

Ask your IBM i team — developers and business analysts — each year directly about their three- to five-year plans. Most experienced practitioners will give a straight answer when asked. Update your single point of failure map as team composition changes.

Build IBM i literacy into adjacent roles.

Operations managers, QA staff, and IT generalists who understand IBM i well enough to monitor subsystem status, read job logs, and recognize abnormal conditions reduce reliance on a single person for routine oversight. This buffer prevents routine issues from becoming crises during staff transitions.

Develop a modernization roadmap.

Free-format RPG conversion, API integration documentation, and code-level documentation, using available tools, reduce long-term dependence on any single developer’s accumulated knowledge. The goal is an IBM i environment where institutional knowledge is embedded in the documented system, not in the team members who built it.

About VIRTUTEM

VIRTUTEM provides ERP Managed Services for IBM i, IBM i modernization, and Infor LX upgrade services for mid-to-large manufacturing and distribution enterprises across North America. As an Infor Partner since 2009, VIRTUTEM brings over thirty years of application-layer depth to IBM i ERP environments.

VIRTUTEM’s teams have operated inside IBM i and BPCS/Infor LX environments for decades, including environments where knowledge concentration, deferred documentation, and retiring staff have created precisely the conditions this guide describes. They understand what is at risk because they have watched it fail, and they understand what a stabilization plan looks like because they have built them in environments where the crisis was already underway.

VIRTUTEM deploys IBM Bob alongside a broader suite of AI-assisted development tools across its entire delivery team, combined with a proprietary white-label AI chat platform and AI tooling currently in development for querying IBM i data directly. This means onboarding into undocumented environments happens faster, and the documentation produced belongs to the client.

What that looks like in practice: in one active engagement, a global industrial manufacturer’s BPCS team was deliberately moved onto a concurrent SAP transformation. VIRTUTEM onboarded through structured shadowing over three months, reached independent ticket handling by month three, and became the primary support resource by month five — reducing an open backlog of 150+ tickets with an average age of over 80 days to approximately 30 tickets averaging under 30 days. The engagement has been active for several years and continues today.

For organizations navigating active or impending RPG developer and business analyst transitions, VIRTUTEM provides the ERP application expertise and operational continuity that most managed services providers lack, combined with the modernization capability to reduce long-term knowledge concentration rather than just manage it.

Schedule a complimentary IBM i staffing risk review with VIRTUTEM.