At the retirement party, there’s a cake, a card everyone signs, a few shared stories, and a farewell email with a subject line like “Thank You for 30 Wonderful Years” circulating across the organization. After decades of service, a respected team member signs off and clears out a desk that had the same nameplate since before half the department was hired. And then, on Monday, everyone goes back to work.
Except something has changed that no one put on the agenda.
This is the Gray Wave — a trend playing out across most long-standing platforms, but one that hits IBM i harder than most. And it shows up first as an HR event: a role to backfill, a headcount to requisition, a transition plan with a two-week overlap. The real challenge runs much deeper.
Over the years, this person not only wrote code but also became a living repository of undocumented business logic, integrations, processing rules, risks, system dependencies, and workarounds. When they leave, that repository doesn’t get backed up — it goes offline. With it, enterprises risk the loss of valuable business insight, institutional knowledge, and problem-solving experience that kept critical IBM i systems running smoothly.
Let’s get a bit deeper.
The Visible Loss
When a senior IBM i developer retires, the first losses are usually easy to identify — hands-on technical expertise organizations can see, measure, and include in a job description. Although experienced IBM i talent is becoming increasingly difficult to find (and the numbers certainly reflect that reality), these capabilities can still be rebuilt over time. However, they’re only the tip of the iceberg.
Here are some of the losses that enterprises easily grasp on the retirement of their most senior IBM i developer:
- System-Level Fluency: An intuitive grasp of IBM i security models, operating system, object structures, jobs, libraries, and interdependent modules required to run a live production environment.
- Multigenerational Technology Proficiency: Working familiarity with C, C++, CL, and Java programs, as well as display, DDS-defined, printer, and SQL files that many organizations still depend on every day.
- Application Development Expertise: Years of experience working with COBOL, RPG, RPGLE, and Synon applications, often refined across multiple language versions over decades of hands-on work.
- Troubleshooting Skills: The ability to analyze job logs, diagnose production issues, debug programs, and resolve database-related problems with minimal disruption to business operations.
These losses are often visible to organizations. At the heart of most myths about the IBM i Gray Wave is a belief that these visible losses are the whole story. In reality, there’s more beneath the surface, and it often goes unnoticed until it becomes a business continuity risk.
The Invisible Loss
The visible losses are relatively easy to spot. A position becomes vacant, technical expertise becomes harder to access, and the search for a replacement begins.
The invisible losses are far more difficult to identify and significantly harder to replace, and this is where the real risk lies.
When an experienced IBM i developer retires, the following intangible assets often leave with them:
1. Tribal Knowledge
IBM i applications are not one-time development initiatives. They evolve over time through enhancements, exceptions, and one-off fixes to accommodate new acquisitions, audits, business needs, customer requests, operational exceptions, and regulatory changes. Often, these changes aren’t fully documented.
As a result, senior developers become the unofficial custodians of not only what the code does, but why it does it. Once they leave, the code stays exactly as it was — it just becomes unexplainable.
2. System Interdependencies?
IBM i environments often consist of interconnected APIs, batch jobs, databases, interfaces, middleware, programs, reports, and third-party integrations that have evolved over many years. Although documentation may explain what individual components do, it rarely captures every dependency between them.
Senior engineers don’t need a wiki to understand how the pieces connect — they are the wiki. They know which applications exchange data, which batch processes trigger specific reports, which integrations quietly depend on a table nobody’s ever touched, and which systems could be affected by a seemingly minor change.
When they leave? doesn’t get filed away. It simply stops existing.
3. Relationship Capital
Every IBM i environment runs on an informal support network — spanning internal colleagues and external partners — that never shows up on an organizational chart.
Veteran developers build trusted relationships with people across compliance, customer service, finance, operations, and vendor departments. They know exactly who to contact when an IBM i-related issue, requirement, or question arises. The person on the other end picks up the phone not because of a support ticket, but because of a relationship built over years.
These associations help keep the system running without missing a beat. When the individual retires, those connections can gradually fade.
4. System History
Every long-running IBM i environment has a few horror stories.
An interface change that affected order processing. A failed upgrade that disrupted reporting. A performance issue that brought month-end operations to a halt.
Experienced IBM i developers remember not only what caused these events, but also how they were resolved.
This historical knowledge helps organizations avoid repeating costly mistakes, identify potential risks early, and make more informed decisions when introducing change. In many cases, it can be the only thing standing between a routine change and a costly error..
5. Invisible Leadership
Not every leader has a formal title.
Senior developers are often the people colleagues turn to for advice, code reviews, knowledge sharing, mentorship, and troubleshooting support. Many decisions carry their fingerprints, even when their sign-off was never officially required, because their judgment was trusted.
When they retire, organizations lose a driving force that helped elevate the entire team.
A Quick Reality Check
If your IBM i systems rely on a few key individuals, the best time to prepare for your next hire is now. Before your senior developers move or retire, try asking your team the following questions:
- Why do your most critical business rules exist?
- How are your IBM i applications, databases, interfaces, jobs, and reports connected?
- Who should be contacted when a production issue impacts business operations?
- Which systems are fragile or likely to fail after a seemingly minor change?
- Who currently serves as the go-to advisor within the team?
If your team paused while answering any of these, your organization may be more exposed to the IBM i Gray Wave than you think.
Future Outlook
Organizations can’t stop their most experienced people from retiring. The good news is that they can control how much walks out the door with them, and that work has to start well before a retirement date is ever announced.
That involves building structured knowledge transfer into everyday operations, documenting what a code does (and why it does it), pairing senior developers with newer team members early, and identifying who’s best positioned to fill that gap internally. Many teams with limited bandwidth can also partner with IBM i experts to help preserve critical knowledge and support continuity while internal teams are rebuilt.
If you’re unsure how to put these steps into practice, consider consulting with a team of IBM Champions for Power Systems to help you prepare for the retirement wave already underway.
Still concerned about the risk? You’re not alone. Join other IBM i-dependent organizations in our upcoming LinkedIn poll and benchmark your preparedness against others facing the same challenge.
