Every month end, one nightly job on your IBM i runs twice. Your senior RPG developer knows why, and he knows which customer file the second run must not touch. Nobody else on the team could tell you, and none of it lives on paper. A knowledge transfer plan exists to move that kind of knowledge from one person to the team before the team needs it.
Most plans start in a meeting room. For an RPG library, we start the plan from the code, and the meetings come second.
What a knowledge transfer plan has to move
Knowledge transfer means moving facts or practical skills from one person or group to another. Inside a company it is a practical problem: the knowledge lives in one part of the organization, and another part needs it. Much of that knowledge is tacit, which means the person who holds it finds it hard to put into words.
That is why a memo or a meeting alone does not finish the job. Your senior developer can explain the month end job in one session. He cannot explain every program in the library that way, and he cannot recall the ones he has not opened in years. The tribal knowledge on an IBM i team is the behavior of the code itself, spread across programs, files and copy members.
A knowledge transfer plan for IBM i therefore has two halves. One half is what the code does, and a machine can write that half down. The other half is why the code does it, and only a person can supply that.
Why a template plan misses most of an RPG library
The usual knowledge transfer process gives the senior person a template. He fills in the systems he owns and the tasks he does each week. Then the team books sessions and takes notes.
On an IBM i system, that template captures what the developer remembers to mention. It misses the copy member that many programs pull in at compile time. It also misses the field that a print job formats into a fixed column on a report nobody has questioned in years.
The gap is not his fault. A source library often has fixed-format and free-format RPG side by side, with DDS-defined files, display files and printer files threaded through it. No person keeps all of that in his head. A plan built on recall will cover the programs people talk about and leave out the ones that quietly run every night.
What a knowledge transfer plan for IBM i contains
When we build the plan from the code, each part has a clear source and a clear owner.
| Part of the plan | Where it comes from | Who owns it |
|---|---|---|
| A plain-English description of every program | AS/Forward, written from the ingested source | Your team reviews it |
| The dependency map of programs, files and copy members | AS/Forward | Your team reviews it |
| The list of copy members the analysis could not resolve | AS/Forward | Your team finds the missing source |
| The programs marked for human review | The readiness status in AS/Forward | The senior developer explains each one |
| Calls whose target is built at run time | The senior developer | The senior developer |
| The reason behind each business rule that matters | The senior developer and the business owner | Both, in writing |
The first four parts come from the source before anyone books a session. The last two come from people, and they are the reason the sessions exist.
How a description of every program changes the sessions
AS/Forward ingests your IBM i source through a proprietary ingestion layer. It covers each of the RPG dialects in your library, along with the DDS around them. Before any AI model sees the source, it builds a dependency map and writes a plain-English description of each program. A team can put that record to work for knowledge transfer before anyone converts a line.
With the descriptions in hand, the sessions change shape. The senior developer no longer starts from a blank page. He opens the Programs view, where every ingested program shows its source, its generated description, its dependency edges, its warnings and its confidence status. He confirms what is right and tells your team what is wrong. He spends his time on the gaps. Each program page also feeds the model both the raw source and the generated English description, so any answer the model gives starts from your real code. We don’t hand raw code to a language model and hope for the best.
The map changes the questions too. A junior developer can pick a file, see the programs the map links to it, and ask one precise question. “Why does this program update the customer file on month end?” has one precise answer the senior developer can give. “How does billing work?” can fill session after session and still leave gaps.
Two more views help the junior developers on your team. The IBM i Navigator shows how each program connects to the files and procedures it uses, so a new person can trace a job from screen to file. The Migration view lets them pick a field or an object and see what else would need to change. A junior developer who can see that list before he edits a file asks better questions, and he asks them sooner.
The same record works for managers. The output of the analysis is a report you can hand to a CTO and a lead developer in the same meeting. Leadership sees the size of the library and the share of programs that need review. The lead developer sees each program and each open question.
If your team wants one page per program in plain English, our post on AI code documentation shows that page in detail. If you plan to check each page against the code that actually runs, our post on checking AS400 documentation against the compiled source covers how.
The questions only a person can answer
A description tells you what a program does. It cannot tell you why the business wanted it that way.
Some calls are invisible to any tool that reads source. When a program builds the name of the program it calls from a parameter at run time, no static cross-reference can show the target. Your senior developer often knows those targets by heart, and your team writes them down in the plan.
IBM’s own DSPPGMREF command has a related limit. It reports which files a program references at the file level, and it captures those references when the program is compiled. When a program builds the name of the file it opens at run time, that file will not show up there either. When the senior developer explains a job, your team records in the plan every file he mentions that the map does not show.
AS/Forward also lists the copy members it could not resolve. That list shows exactly where the map stops. Each item on it becomes a question for the person who knows where that source lives.
Programs with gaps carry a review status, and clean programs are marked ready. The review list makes a good agenda for a senior developer. Each item he explains closes one gap on the list. For the rules that matter most, your analysts can turn the descriptions into rule statements, as our post on business rule extraction explains.
A senior developer may change roles or retire. A knowledge transfer plan built this way means his hours go to the questions only he can answer, while the rest of the record already exists.
How to run the plan, one group at a time
Your knowledge transfer plan can follow the same order every time. Each step has an owner, and each step ends with something written down.
- We load your production source libraries, including the libraries that hold copy members, and run AS/Forward inside your network.
- Your team reviews the dependency map and the descriptions for one group of programs that share files.
- The senior developer works through the review list and the unresolved copy members for that group.
- Your team writes down the run-time call targets and the reasons behind the rules he explains, program by program.
Then the team moves to the next group. The plan grows one group at a time until every group has its answers written down.
The preferred deployment is fully local and air-gapped. Your source and the analysis stay inside your infrastructure, and with a local model no data leaves your network. You choose the model, whether Claude, OpenAI, Gemini or one you run locally.
The same record serves your next decision
A knowledge transfer plan can be the first step toward a bigger choice. The record you build here is the same record a modernization needs.
Some teams want to stay on IBM i and clean up fixed-format code into free-format RPG, and we do that work. Others want to convert the code to Python or another language their team picks, and we do that work too. Plenty of teams want to keep their green screens exactly as they are, and we modernize the programs behind them. Every one of those outcomes is valid, and your team makes the call.
Your first step is the IBM i modernization assessment. It gives you the program count, the map, the descriptions and the readiness split, and it sizes any work that follows. The assessment comes first, the target decision comes second, and the second decision is yours.
Start your knowledge transfer plan with us
Tell us how many source libraries you run and which jobs worry you most. Tell us who on your team knows the code best, and how much of his time the plan can use. We will set up the assessment and hand your team the descriptions and the map. Then we help you build a knowledge transfer plan around the review list.
Call 501-232-7188, or send us a note through our contact page.