Most IBM i shops assume that migrating from a legacy OS version requires a careful stair-step process. They think you need to go version by version with months of testing at each rung.
That assumption is expensive, and in some circumstances, it isn't true. In many cases, a direct jump is possible. The real variable is whether your team can read the code underneath the platform's standard toolchain.
IBM i code fluency at the legacy RPG level is what determines whether a migration runs 60 days or 18 months. Most organizations never find that out until they are already committed to the longer path.
Deep fluency in legacy RPG code, not just modern IBM tools, is what separates a 60-day IBM i migration from a year-long project. Source Data's senior programmers carry expertise across every generation of the platform, including versions IBM shipped in the 1970s and 1980s. That experience translates directly into faster diagnostics, shorter migration windows, and dramatically lower costs.
What Separates IBM i Environments That Run Well from Those That Struggle
There's a difference between engineers who know how to use IBM's tools and programmers who can actually read the code. That might sound like a subtle distinction, but the outcomes it produces are significant.
IBM's standard upgrade tools provide essential information about platform compatibility and system requirements. Experienced programmers add another layer of analysis by examining application logic, dependencies, and older code that automated reports may not fully explain.
A programmer who can read the underlying logic directly operates with a different kind of confidence. That confidence shows up in diagnostic speed, IBM i migration path selection, and the ability to recover capacity organizations have been silently losing for years.
A Five-Minute Fix Resolved What Nobody Else Could Diagnose
One of our clients was running a 9402 model 170 on V4R3, and its general ledger had stopped working. The client had already reached out to others before contacting Source Data, and nobody could diagnose the issue. It had gone unresolved long enough to become a genuine operational concern.
We connected the client with one of our senior programmers. This programmer has been writing code since the early 1980s. The fluency runs deep into the older RPG versions IBM was shipping in the 1970s, 1980s, and early 1990s. Most current IBM i engineers have never touched these languages.
The programmer fixed the general ledger in five minutes. The diagnostic process was essentially instantaneous because the programmer could read the code directly. He understood the logic well beneath what modern IBM tools surface, and recognized the failure pattern immediately.
That kind of fluency is not taught in current IBM i certification tracks. It exists in a very small population of practitioners who came up through the platform's earlier generations and never stopped working in it.
A Better Migration Path Starts With the Code
You don't always have to migrate a legacy IBM i system version by version. In some environments, it is possible to skip some of the steps. The answer depends entirely on what a direct code-level assessment reveals.
That same programmer from the earlier story was handed a different challenge. A client in Washington, D.C. was running a Power-era system on V5R3 in native RPG. The conventional IBM i migration path would have required multiple OS version jumps, each with its own testing cycle and risk window. It would have drawn the project out over many months.
The programmer's assessment showed a direct jump to V7.5 was viable. We pushed the environment from V5R3 to V7.5, validated that the software performed correctly, and closed the project in about 60 days. Not only did it save months, but the cost was also a fraction of a conventional multi-step migration.
To learn more, read our post explaining that full migration project in detail. Along with looking at that migration, it covers the steps and considerations that go into executing a jump like that.
It is worth being precise about what made this possible. The approach does not work universally. If an environment has incorporated newer OS functionality or accesses devices that depend on more recent platform features, the multi-step path remains the better choice. The programmer's expertise lies in knowing which situation applies before committing to either direction.
Finding Performance Gains in Decades-Old Code
A third case makes the underlying principle visible from a different angle. A client with legacy software dating to 1976 had a day-end routine that consumed three and a half hours every night. The client had no explanation for why it ran that long. They had simply absorbed it as a fixture of operations.
Source Data's senior programmers examined the code directly. What our team found, and what they did with it, illustrates why legacy RPG code fluency produces outcomes that modern toolchain approaches cannot replicate.
"It's 85 pages of RPG programming. This makes no sense. So they figured out how to determine what was happening in 15-minute increments. Based on that, they figured out where they could cut out unneeded routines and recognized patterns. As senior software developers, they made specific and intelligently selected use of augmented intelligence to streamline the day-end routine. They reduced it from three and a half hours a day to an hour. That two-and-a-half-hour reduction is a gain of 900 extra hours a year. When we look at the incremental cost of programming hours, it's probably about 20 hours. This is cheap." – Bob Losey, Founder and President, Source Data Products
900 hours of recovered processing capacity. Roughly twenty hours of programming time to achieve it. The only reason that trade was possible is that the programmers could read what was happening inside the code.
IBM i Code Expertise Is Getting Harder to Find
The IBM i talent situation is shifting in ways that create a quiet but compounding risk for mid-market organizations. Practitioners who carry deep fluency in legacy RPG versions, the code IBM shipped in the 1970s, 1980s, and early 1990s, are a shrinking population. Many of these professionals have retired.
Engineers entering the field today are trained on current tools and methodologies. Those skills are valuable, but they don't include the ability to work with code that predates the AS/400's 1988 introduction. For organizations still running on V5R3, V7.2, or earlier versions, that gap has practical consequences. It affects how quickly teams diagnose problems, which IBM i migration paths are available, and how much budget a version upgrade requires.
"My programmers have expertise not only in the most current versions of RPG but also in the older versions of RPG that were used by IBM in the 70s, 80s, and early 90s. The good news about these guys is they love what they're doing, and they're still relatively young." – Bob Losey, Founder and President, Source Data Products
Deep historical fluency combined with current platform knowledge is what makes the five-minute diagnostic and the 60-day V5R3-to-V7.5 IBM i migration possible. That combination is what most organizations discover they cannot find elsewhere.
We touched on the IBM i expertise shortage in a post about what happens when a legacy programmer leaves after many years. It covers why this dependency creates structural risk when it is concentrated in one or two people inside a single organization.
FAQs About the Value of IBM i Code Fluency and Migrations
Is it really possible to skip OS version steps on an IBM i migration?
In some environments, yes. An application may move to a newer IBM i version without requiring every intermediate migration step. However, the operating-system upgrade path still depends on IBM's supported release combinations, hardware, and software dependencies. A code-level assessment helps identify application requirements before the team selects a migration strategy.
Why do some legacy IBM i problems take weeks to diagnose when others resolve in minutes?
The difference usually comes down to whether the engineer uses IBM's diagnostic tools or reads the underlying RPG code directly. Tool-based approaches surface what the platform reports. Code-level fluency surfaces what the program actually does. For legacy environments, those two things are often very different, and the gap between them is where unexplained problems hide.
How much of the IBM i expertise pool has already retired?
A significant portion of practitioners who carry deep fluency in legacy RPG versions have already retired or are approaching retirement age. Engineers entering the field today are trained on current methodologies but rarely have exposure to older RPG generations. That creates a growing gap for organizations still running environments built on code from the 1970s, 1980s, and early 1990s. We touched on related issues in our recent post about the AS400 skills collapse.
What RPG versions does a programmer need to know for legacy IBM i code work?
The relevant generations span Original Program Model RPG, RPG II, RPG III, and RPG IV (also called ILE RPG). Code written in the 1970s and 1980s is predominantly RPG II and RPG III. Most current IBM i engineers are trained in ILE RPG and aren't equipped to read earlier versions without significant ramp-up time. For environments running software from that era, the generational fluency gap is the primary diagnostic obstacle.
How long does a code-level IBM i migration assessment take?
A code-level assessment is typically faster than most organizations expect. A senior programmer fluent in the relevant RPG generation can often complete an initial readiness evaluation in a few days. The output is a clear picture of which migration paths are safe, which require intermediate steps, and where optimization opportunities exist.
What should an organization do if it has a legacy IBM i problem nobody else could fix?
Start with a conversation with a team whose programmers are fluent in the specific RPG generation the code was written in. Many problems that have resisted diagnosis for months resolve quickly once someone can read the code rather than interpret what IBM's standard tools report. Assessing the environment is the right first step before committing to a platform replacement or a lengthy, multi-step migration project.
Experience Makes the Difference
An older IBM i environment does not automatically require a long, expensive migration. The code itself often determines which paths make sense. Someone who understands that code can identify options that standard upgrade planning might overlook.
Source Data team has decades of experience, building expertise across generations of RPG and IBM i. Our team can assess your applications, identify migration requirements, and help you avoid unnecessary steps. Reach out to us before deciding what your next IBM i migration will cost.
