# RPG and IBM i Skills Succession Risk Assessment

> Source: https://netray.co/tools/rpg-skills-succession-risk-assessment
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Score how exposed your IBM i and RPG environment is to retirements, single points of knowledge and missing documentation.

## Category

erp-migration

## Erp

Oracle JD Edwards World

## Audience

- IT director
- CIO
- IBM i team lead

## Tool

**Kind:** assessment

**Questions:**

#### How many people can independently support your RPG and CL programs?

**Options:**

##### Five or more

**Score:** 4

##### Three or four

**Score:** 3

##### Two

**Score:** 2

##### One

**Score:** 0

#### How many of your IBM i staff expect to retire or leave in the next five years?

**Options:**

##### None expected

**Score:** 4

##### One, with a successor identified

**Score:** 3

##### One or more, no successor

**Score:** 1

##### Most of the team

**Score:** 0

#### How well documented are your customised programs and batch schedules?

**Options:**

##### Current documentation, reviewed yearly

**Score:** 4

##### Documented but out of date

**Score:** 2

##### Only in people's heads and comments

**Score:** 0

#### Do you have an external partner under contract for IBM i or JD Edwards World support?

**Options:**

##### Yes, with defined response times

**Score:** 4

##### Informal arrangement

**Score:** 2

##### No

**Score:** 0

#### How often do you recruit or train new IBM i and RPG staff?

**Options:**

##### Regularly, with a mentoring plan

**Score:** 4

##### Occasionally

**Score:** 2

##### Not at all

**Score:** 0

#### Does your team use modern RPG (free format RPG IV) and source control?

**Options:**

##### Yes, both

**Score:** 4

##### RPG IV but no source control

**Score:** 2

##### Mostly older fixed format, no source control

**Score:** 0

#### Can you restore and run the system from backup without the one person who knows how?

**Options:**

##### Yes, tested in the last year

**Score:** 4

##### Probably, not tested

**Score:** 2

##### No

**Score:** 0

#### How many modifications have been made to standard JD Edwards World code?

**Options:**

##### Few or none

**Score:** 4

##### A moderate number, documented

**Score:** 2

##### Many, some undocumented

**Score:** 0

#### Do business users depend on green screen programs only one person knows?

**Options:**

##### No, all are shared knowledge

**Score:** 4

##### A few

**Score:** 2

##### Yes, several critical ones

**Score:** 0

#### Have you written down a roadmap decision (stay, modernize, replace) with dates?

**Options:**

##### Yes, approved by management

**Score:** 4

##### Discussed, not written

**Score:** 2

##### No

**Score:** 0

**Bands:**

#### High succession risk

**Min:** 0

**Max:** 34

**Verdict:** Your environment depends on a very small number of people or on knowledge that is not written down. A single departure could stop support.

**Recommendations:**

- Start documenting the ten most critical batch jobs and programs now
- Contract an external partner for coverage before a gap appears
- Pair a junior person with each key expert immediately
- Test a full restore from backup this quarter

#### Moderate risk

**Min:** 35

**Max:** 64

**Verdict:** You have some coverage but gaps in documentation, tooling or planning would hurt during a departure or incident.

**Recommendations:**

- Document programs by business criticality
- Move source into a repository and adopt a review habit
- Write down the roadmap decision and a review date
- Identify a backup for each key person

#### Reasonably resilient

**Min:** 65

**Max:** 84

**Verdict:** Your team and documentation give good coverage. Focus on keeping it current and planning the longer term direction.

**Recommendations:**

- Review documentation at least yearly
- Plan recruitment ahead of retirements
- Run a failure drill for restore and recovery

#### Strong position

**Min:** 85

**Max:** 100

**Verdict:** Staffing, practice and planning are well covered. Keep refreshing skills and revisit the roadmap when the vendor or hardware lifecycle changes.

**Recommendations:**

- Keep a written roadmap with review dates
- Share your practices with newer team members
- Track vendor support dates for hardware and software

## Content

**Intro:** Many IBM i environments run well but depend on two or three experienced people. This assessment scores that dependency so you can decide whether to document, hire, outsource or plan a different direction.

**Sections:**

#### How to use it

**Body:** Answer the ten questions honestly, ideally with the team lead and a manager together, because the two often answer differently. Each answer scores from 0 to 4, and the total is shown as a percentage band. Export the result to share with leadership. Repeat it once a year so you can show whether risk is going down.

#### What the questions measure

**Body:** They cover four areas: how many people can support the system, how much knowledge is written down, how modern the practices are, and whether there is a plan. Key person dependency and undocumented customizations are the two biggest drivers. A system with one expert and no documentation scores low even if the software is stable and the hardware is healthy.

**Bullets:**

- People coverage and retirement timing
- Documentation and customization volume
- Tools: free format RPG, source control
- Recovery testing and roadmap decision

#### What to do with the result

**Body:** A low score does not mean you must replace the system. Often documentation, a support contract and a tested recovery plan lower the risk at a modest cost. A written decision on whether to stay, modernize or replace removes the drift that makes the risk worse each year. Take the lowest scoring answers first, since those are the cheapest improvements.

#### Common mistakes

**Body:** Counting people who know the system in general as people who can support specific custom programs overstates coverage. Treating a vendor contract as insurance without checking that it covers your modified code is another. Waiting until the retirement notice arrives leaves too little time for knowledge transfer, which typically takes many months to be effective.

**Cta:** Netray can help capture knowledge from legacy code and ERP data with private AI that runs on your own hardware, so documentation does not depend on one person's free time.

**Faq:**

#### Is the IBM i platform itself at risk?

**Answer:** The platform is actively supported by IBM with new releases. The risk in most shops is people and documentation rather than the operating system. This assessment focuses on the skills and knowledge side of the system.

#### How many experts are enough?

**Answer:** Three is a practical minimum for any critical system, including external partners, because it survives one departure and one absence. Fewer than two is a clear risk, however stable the system looks day to day.

#### Should a high risk score mean we replace the ERP?

**Answer:** Not necessarily. Many shops reduce risk through documentation, a support contract and modernizing tooling. Replacement is a large project, so make it a deliberate decision with a business case rather than a reaction to a score.

#### Can AI help with legacy RPG code?

**Answer:** Language models can explain RPG and CL code, draft documentation and help with analysis, but output needs review by someone who knows the system. Running the model on your own servers keeps source code private.

## Search terms

rpg programmer shortage, as400 skills gap, ibm i succession planning, key person risk as400, legacy rpg developer retirement, jde world support risk, ibm i staffing risk, as400 knowledge transfer

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
