Picture the conversation. Your longest-tenured RPG developer, the one everyone quietly relies on when something in the order management system behaves strangely, mentions retirement plans over the next year or so. It’s not a surprise. Everyone saw it coming eventually.
What usually comes next is a scramble. Someone asks whether the system is documented. The honest answer, more often than not, is: not really.
Not in a way that reflects what the code actually does today, after twenty or thirty years of small adjustments, none of which were written down anywhere except in the program itself.
This is not a rare situation. It is close to the default condition for IBM i organizations right now.
The Retirement Wave Is Not Hypothetical
For the first time in the history of the survey, IBM i skills availability is now the single largest concern reported by IBM i professionals, according to the industry’s most closely watched annual benchmark. That’s not a niche worry buried in the data. It’s the top-ranked concern, ahead of everything else IT leaders were asked about.
It’s easy to treat this as an abstract labor-market trend. Inside any individual organization, it’s much more specific than that. It’s a particular person, with a particular retirement date, who understands a particular piece of business logic that nobody else has ever needed to fully learn, because that person has always been there to explain it.
What "No One Knows What This Code Does" Actually Costs
The cost shows up in a few predictable places, and none of them are hypothetical for organizations living with this today.
Transformation projects stall in discovery, because before anyone can safely transform an application, someone has to establish what it currently does, and that step alone can consume months when there’s no reliable starting point.
New developers and outside resources take far longer than they should to become productive, not because they lack skill, but because they’re starting from zero on a system with no map. Maintenance and support get slower and riskier, because a single undocumented edge case in a program that touches order processing or financial close can turn a routine change into an incident.
None of this is really a documentation problem in the narrow sense. It’s a preservation problem. The knowledge exists. It’s just sitting in exactly one place: a person’s head, with a departure date attached to it.
Why the Obvious Fixes Rarely Hold Up
Most organizations have already tried the intuitive response. A wiki page. A shared drive of runbooks. A hurried knowledge-transfer session scheduled once someone’s departure is confirmed.
The honest limitation of that approach is capacity, not effort.
A team that’s already stretched thin maintaining production systems doesn’t have the bandwidth to manually document a portfolio that may run into the hundreds of programs, each with its own dependencies, data structures, and quiet exceptions. And a two-week handoff period was never going to be enough time for anyone to transfer everything they’ve absorbed over a twenty-year career, no matter how well-intentioned the effort.
The gap isn’t a lack of concern. It’s that manually documenting an estate at this scale, program by program, isn’t something a lean internal team can realistically do on top of everything else they’re responsible for.
The Solution? IBM i Documentation Service
This is the specific problem our IBM i Documentation Service is built to close. It’s a managed engagement where our expert team configures CoderFlow inside a customer’s own environment, runs analysis across their application portfolio at scale, and delivers a structured documentation package the customer’s developers can review, correct, and build on.
The distinction that matters here is how the analysis actually happens. This isn’t a static code scanner reading through source files and guessing at intent.
CoderFlow operates with real access inside the environment: compiling programs, querying DB2 schemas, and inspecting how screens and programs actually behave. The resulting documentation reflects what a system does in practice, including the edge cases and undocumented quirks that a read-through of the source code alone would never surface.
Because the analysis runs across many programs at once rather than one at a time, an engagement can realistically cover an application portfolio at a scale that would take an internal team years to document manually, if they ever got to it at all.
What the Documentation Actually Covers
The output is split into two layers, because the people who need it aren’t all asking the same question.
Technical documentation
captures what a developer needs, a program’s purpose and business function, its key logic paths and decision points, the data structures and files it touches, its dependencies on other programs and services, and the behavioral notes and edge cases that don’t live anywhere except inside the running system.
Business-facing documentation
covers what a program does and how it supports the processes people rely on day to day, useful for anyone who needs to understand a system’s function without reading RPG to do it.
Once delivered, the customer’s own developers review and extend that output, adding context and correcting anything the analysis missed. That review step matters. It’s where tribal knowledge that still exists only in conversation finally gets written down, formalized, and turned into something the organization owns.
Where This Fits Into a Larger Strategy
Documentation on its own is valuable. It’s also, for most organizations, the first real step toward something bigger.
You cannot futurize what you cannot first describe accurately, and futurization, our approach to transforming IBM i applications without discarding the business logic built into them, has always depended on knowing what an environment contains before deciding what to change.
An organization that establishes a reliable, current baseline of its application portfolio is in a fundamentally different position than one still operating on institutional memory and a folder of stale documentation. It can plan a reimagined with confidence instead of discovering surprises six months into the project. It can bring in outside help, whether that’s new hires or augmented staff, and get them productive against a real map instead of relying entirely on whoever happens to still be around to explain things. And it stops being one retirement away from losing knowledge it can never fully get back.
If your organization has a version of this story already in motion, a senior developer nearing retirement, a new IT leader trying to understand a system they inherited, a transformation initiative that keeps stalling in discovery, that’s worth a conversation now rather than after the departure date has passed.
Reach our to our expert team at Futurization@ProfoundLogic.com to talk through what IBM i documentation services could look like for your environment.