Cut RPG Technical Debt in 90 Days: Dependency First Mapping for IBM i

  • September 1, 2026
  • Ty Woods
  • 13 min read

Map what your RPG code actually touches before you change a single line. Dependency-first remediation, tracked with a Technical Debt Ratio and bus-factor mapping, catches the coupling and knowledge gaps that automated fixes miss. Run a dependency audit this week, flag your highest-risk hotspots, and let that map drive your first three remediation targets.

TL;DR:

  • Mapping dependencies before refactoring is essential to prevent unexpected production breaks and identify critical hotspots with high risk and low bus factor.
  • Combining static analysis, version control co-change analysis, and runtime call tracing provides a comprehensive view of program dependencies and hidden coupling.
  • Focusing on architecture and knowledge debt is crucial since these risks are harder to quantify but more likely to cause outages if ignored.
  • Prioritizing remediation based on severity and risk scores, along with establishing CI/CD pipelines, minimizes deployment friction and facilitates reversible incremental changes.
  • A 90-day focused plan starting with dependency mapping, followed by testing, automation, and documentation, significantly reduces structural RPG technical debt.

Table of Contents

What RPG Technical Debt Looks Like in Real IBM i Systems

RPG technical debt rarely announces itself the way a compiler error does. It hides in copy members shared across two dozen programs, in file access hardcoded three layers deep, and in business rules that exist only in one senior developer’s head. On IBM i, this debt tends to be structural rather than cosmetic, and structural debt is the kind that breaks production instead of just annoying your team.

A few patterns show up constantly in shops running decades-old RPG:

  • Copy members that duplicate logic across dozens of programs, so one fix requires touching every copy
  • Embedded I/O logic that mixes database access directly into business rules, with no separation layer
  • Deprecated fixed-format RPG (RPG III/RPG/400 style) sitting next to newer free-format code with no migration plan
  • Monolithic programs exceeding several thousand lines that handle validation, calculation, and output in one block
  • File access patterns hardcoded against specific physical file names, creating architectural coupling between logic and storage

Knowledge debt compounds all of it. When two or three people understand why a program branches the way it does, every change carries risk that no static scan will flag. That is the bus factor problem, and in RPG shops with 20 to 40 years of accumulated logic, it is often the single biggest source of deployment anxiety.

The Four Categories of Technical Debt You Need to Track

A recent systematic review of technical debt research identifies more than a dozen distinct types, but for RPG teams they collapse into four practical buckets: code, architecture, infrastructure, and knowledge/process. Each one behaves differently, and each requires a different detection method.

  • Code debt: duplicated logic, dead subroutines, inconsistent naming, missing error handling. Static analysis tools catch most of this automatically.
  • Architecture debt: tight coupling between programs, circular dependencies, business logic embedded in data access. This requires dependency mapping, not just line-by-line scanning.
  • Infrastructure debt: outdated OS releases, missing CI/CD, manual deployment steps, no automated rollback path. Usually visible in deployment logs and change records.
  • Knowledge/process debt: undocumented business rules, single-person ownership of critical modules, no runbooks. This one requires interviews, not tools.

Code debt is the easiest to measure and the least dangerous to ignore short-term. Architecture and knowledge debt are the opposite: harder to quantify, and far more likely to cause an outage when someone finally touches the wrong program. The same review found that most tooling still focuses on code and architecture debt, leaving documentation and process debt chronically under-addressed, which is exactly where RPG shops tend to bleed the most time during incident response.

Measuring RPG Technical Debt: Metrics That Convince Engineering and Finance

You cannot prioritize what you cannot measure, and “the code feels old” will not get you a remediation budget. The SQALE method gives you a starting formula: Technical Debt Ratio equals remediation effort divided by development effort, times 100. A high Technical Debt Ratio generally signals that a codebase needs structural attention, not just cleanup sprints.

TDR alone will not tell the whole story on IBM i, though. Pair it with metrics that catch architecture and knowledge risk specifically.

Metric What it measures How to collect it
Technical Debt Ratio (TDR) Remediation cost vs. development cost Static analysis + manual effort estimate
Change amplification Files touched per single feature change Git/version control history
Bus factor Number of people who understand a module Structured interviews
Time-to-deploy Days from code-complete to production Deployment logs
Dependency cycles Circular references between programs Dependency graph analysis

Multiply that gap by average developer hourly cost and you have a defensible dollar figure for the remediation backlog, which is exactly how architecture and organizational metrics turn into budget conversations instead of engineering complaints.

Bus factor is harder to put a dollar figure on directly, but it is the leading indicator of catastrophic risk. A module with a bus factor of one is not a maintenance problem. It is a business continuity problem waiting for a resignation letter or a bad week of sick leave.

Single point of failure dependency illustration

Prioritized Remediation Tactics: What to Fix First and How

Fixing the loudest bug first feels productive and usually is not. The sequence that actually reduces risk starts with visibility, not code changes.

  1. Map dependencies before touching anything. Build a graph of which programs call which, which files they touch, and which copy members they share. Skipping this step is the single most common reason RPG refactors break production unexpectedly.
  2. Score hotspots by severity times risk. A structured scoring approach that weighs how often a program changes against how badly a failure there would hurt the business gives you an objective backlog instead of a political one.
  3. Use strangler-pattern slices, not big-bang rewrites. Peel off one business function at a time, run it in parallel with the legacy path, and cut over only after validation. This keeps the RPG modernization effort reversible at every stage.
  4. Stand up CI/CD and version control before the first real refactor. Without automated regression testing and a rollback path, every change to legacy RPG is a bet with no insurance. This step is a prerequisite, not a nice-to-have, for sustainable modernization on IBM i.
  5. Document business rules as you go, not after. Write ADRs (architecture decision records) and runbooks for every module you touch. This is also how you shrink bus factor risk: pair a junior developer with the one person who understands a module, and have them co-author the documentation together.

Pro Tip: Treat every remediation slice as a knowledge-transfer opportunity. If only one person can explain why a subroutine exists, that program goes to the top of the backlog regardless of how “stable” it looks in production.

The order matters more than the speed. A team that maps first and refactors second moves slower in week one and faster in every week after that, because they stop discovering surprise dependencies mid-sprint.

Dependency Mapping and Tool Approaches for RPG Codebases

Building an accurate dependency graph for RPG requires more than reading source files. Three techniques, layered together, produce a map you can actually trust.

  • Static, IBM i–aware parsing extracts call chains, file references, copy member usage, and field-level data lineage directly from source, without needing the program to run.
  • Git or version-control co-change analysis (the method behind tools like CodeScene and code-maat) flags “logical coupling,” meaning files that change together even when no explicit call exists between them. This catches hidden dependencies static parsing alone misses.
  • Runtime call tracing logs which programs actually execute in production, which surfaces dead code and confirms whether a dependency the static parser found is still live or a leftover from a feature retired years ago.

None of these three methods alone is sufficient. Combining static analysis with Git history and manual hotspot review is what reveals logical coupling that automated tools miss on their own. The merged view, static structure plus real change history plus runtime confirmation, is what an IBM i–aware parser should hand your team before any remediation work starts.

Pitfalls and Anti-Patterns That Sink RPG Remediation Projects

Most failed modernization efforts do not fail because the code was too hard. They fail because the team skipped a step that felt optional at the time.

  • Refactoring without mapping business rules first: leads to silent breakage weeks later. Mitigation: no code change ships without a documented dependency check.
  • Trusting automated transforms blindly: AI-assisted conversion tools can rewrite syntax without preserving edge-case logic. Mitigation: pair every automated change with manual review of the original business rule.
  • Ignoring deployment friction and rollback plans: teams without CI/CD discover this the hard way during the first bad release. Mitigation: build the rollback path before the first production deploy, not after.
  • Deprioritizing knowledge debt because it does not show up in a scan: bus factor risk compounds quietly until someone leaves. Mitigation: schedule structured interviews as part of every assessment, not as an afterthought.

Your 90-Day RPG Technical Debt Reduction Checklist

You do not need a two-year modernization program to start seeing results. A focused 90 days, sequenced correctly, gets measurable risk reduction on the board.

  1. Days 0 to 7: Run a dependency inventory across your core RPG programs and map bus-factor hotspots through short interviews with senior developers.
  2. Weeks 2 to 6: Build regression tests for your top three highest-risk hotspots and start logging deployment friction (time-to-deploy, rollback frequency).
  3. Weeks 6 to 12: Stand up basic CI/CD, schedule your first strangler-pattern refactor slice, assign a named owner to each critical module, and update runbooks accordingly.

Pro Tip: A five-stage assessment, inventory, architecture review, infrastructure audit, knowledge audit, and severity scoring, typically produces a prioritized backlog within one to two weeks for a medium-sized codebase. Use that speed to get your 90-day plan approved before momentum stalls.

Dependency-First Modernization: What a Mapping-Led Approach Delivers

Golden Path Digital built AS/Forward around one premise: you cannot safely modernize what you have not mapped. The tool parses IBM i RPG codebases directly, extracting call chains, file dependencies, copy member usage, and field-level lineage, then outputs a prioritized dependency graph before any transformation logic runs.

That sequencing matters because architecture debt is the most predictive risk signal for future delivery speed, more predictive than code-only metrics. Skipping the map to save time upfront routinely costs more in consulting hours later, when a change breaks something the team never knew was connected.

What that dependency-first output typically includes:

  • A full call-chain and file-dependency graph across the target programs
  • Copy member usage mapping to flag shared-logic coupling before refactor
  • A severity-by-risk scored backlog, not a flat list of findings
  • Bus-factor flags on modules with single-person ownership

The Bottom Line on Reducing RPG Technical Debt

Map first, measure second, refactor third. Change amplification is the metric to report to stakeholders this quarter. If a routine feature still touches a dozen files, that number, not a vague sense of “old code,” is your case for budget and time.

A Modernization Lesson Worth Repeating

A Modernization Lesson Worth Repeating — overview diagram

Every project I have seen go sideways skipped the same step: someone started refactoring before anyone mapped what the code actually touched. The teams that mapped first before writing a change ticket rarely hit production regressions, because they knew exactly what a change would ripple into before they shipped it.

AI-assisted code transforms deserve real skepticism here. They can rewrite RPG syntax quickly, but syntax was never the hard part. The business rule buried in a 15-year-old IF statement is, and no automated tool reads intent. Treat AI transforms as a fast first draft, never as the final review, and keep a human who understands the original logic in the approval chain every time.

— Ty

Get a Dependency Map Before You Touch a Line of Code

Golden Path Digital’s IBM i Modernization Assessment gives you the dependency-first foundation this article has been building toward, without the guesswork of a manual audit stretched across months.

Golden Path Digital

The assessment delivers a full call-chain and dependency graph, bus-factor flags on single-owner modules, and a severity-scored remediation backlog, typically within one to two weeks for a mid-sized RPG codebase. That timeline matters because most modernization budgets die waiting on a discovery phase that never produces a usable map. Teams facing a harder rescue situation, where a project has already stalled or a vendor handoff went wrong, may also want to look at a project rescue and takeover service built for exactly that scenario. For everyone else, the direct path is simpler: get the IBM i modernization assessment scheduled, and start your 90-day plan with an actual map instead of a guess.

Sources

FAQ

What are the four types of technical debt?

Code, architecture, infrastructure, and knowledge/process debt cover the practical categories RPG teams need to track, with architecture and knowledge debt requiring manual review rather than automated scanning alone.

How much technical debt is acceptable?

There is no universal safe number, but a Technical Debt Ratio above 20 percent generally signals the codebase needs structural attention rather than routine cleanup.

What is considered technical debt?

Technical debt is any shortcut, outdated pattern, or undocumented decision in a codebase that makes future changes slower or riskier, including hardcoded file access, deprecated fixed-format RPG, and single-person knowledge ownership.

What is an example of technical debt in RPG?

A common example is a business rule embedded directly inside file I/O logic across multiple copy members, so that fixing one calculation error requires touching a dozen programs that all duplicate the same architecturally coupled logic.

How do I start reducing RPG technical debt without a full rewrite?

Start with a dependency audit and bus-factor interviews, then use a strangler-pattern refactor to replace one business function at a time instead of rewriting the system outright.

Leave a Reply

Your email address will not be published. Required fields are marked *