Most conversations about transforming IBM i applications start small, and for good reason. A single screen. One flagship program. A pilot that proves the concept works before anyone commits real budget to it. That instinct is sound. Nobody should bet an entire portfolio on an unproven approach.
But somewhere between the successful pilot and the finished transformation, a lot of organizations quietly stall. The one program that got refactored works beautifully. The other nine hundred are still exactly where they were. The question worth asking isn’t whether an approach can update one application. It’s whether it can hold up across an entire codebase, built over decades, with all the tangled dependencies that come with it.
That’s a different problem, and it’s the one most IBM i organizations are actually facing.
The Portfolio Most IBM i Shops Are Actually Sitting On
It helps to be honest about the scale involved. Homegrown, in-house-written applications remain the most common software running on IBM i, accounting for 73% of what organizations run on the platform, according to the industry’s most closely watched annual benchmark. These aren’t a handful of packaged applications with vendor support contracts. They’re custom-built systems, often decades old, shaped by thousands of small business decisions that were never fully documented anywhere except in the code itself.
Meanwhile, the teams responsible for maintaining all of it haven’t grown to match. A considerable share of organizations, 21%, report running their IBM i environment with just three to five developers, a figure that has held steady for the past ten years. And separate analysis of the same annual survey data found that roughly four in ten IBM i shops run nearly all of their core business applications on the platform, not just a supporting piece of their infrastructure.
Put those together and the shape of the problem becomes clear. Large, deeply homegrown portfolios. Lean, stable teams. And a business that depends on all of it running correctly every day.
This is the context Futurization™, our unique approach to reimagining IBM i applications without abandoning the platform or the business logic built into it, actually has to operate in. Not a single application in isolation. An entire codebase.
Why Pilot-Scale Success Doesn't Scale on Its Own
A successful pilot proves something real, that a program can be understood, that its logic can be preserved, that the transformation doesn’t break what the business depends on.
What it doesn’t prove is that the same approach holds up at a thousand times the size.
The complexity doesn’t grow at the same pace as the program count. It compounds. A single program might call a dozen shared routines. Those routines might be reused across hundreds of other programs, each with slightly different assumptions about what gets passed in and what comes back out. Business logic that looks like a local decision in one program often turns out to be a dependency that a dozen other programs quietly rely on. None of this is usually written down anywhere except in the code.
A four-person team, however skilled, cannot reasonably map that web of dependencies by hand across a thousand-program portfolio in any timeframe a business can tolerate. This isn’t a resourcing problem that more hours can solve. It’s a structural one. Traditional program-by-program transformation, at portfolio scale, is a math problem before it’s ever a labor problem.
A Composite Scenario: 1,200 Programs, Four Developers, One Retirement Clock
Consider a composite scenario built from patterns common across mid-size IBM i organizations, not any single named company.
A regional industrial distributor has run its core business on IBM i for close to thirty years. Order processing, inventory allocation, and pricing all live in roughly 1,200 RPG programs, maintained by a team of four developers.
One of them, the only person who fully understands the pricing engine’s discount logic, is eighteen months from retirement.
The traditional path here is familiar and grim. Either the transformation project takes years, working through the portfolio one program at a time while the team keeps the lights on, or the organization accepts the risk of losing that pricing logic entirely when its last expert walks out the door.
An agentic, portfolio-wide approach changes the shape of that problem.
Rather than analyzing programs one at a time, the environment is mapped as a whole, which programs share subroutines, which business rules appear in multiple places with subtle variations, where the highest-risk technical debt actually sits. That mapping surfaces the pricing engine’s hidden dependencies long before the retirement clock runs out, not as an afterthought discovered mid-project.
From there, the work gets prioritized by business impact rather than working through the file directory alphabetically. The programs that carry the most operational risk, the ones tied to revenue-critical logic like pricing and allocation, move first. Verification runs continuously as changes are made, so the team isn’t waiting until the end of a multi-year project to find out whether something broke. And because the approach favors coexistence over wholesale replacement, the existing applications keep running throughout. The business never has to choose between stability and progress.
What would take a four-person team years to work through manually, one program at a time, becomes a tractable, prioritized initiative when the environment can be understood and acted on as a whole rather than one file at a time.
Designing for the Whole Portfolio, Not Just the Flagship App
This is where the difference between a pilot and a strategy really shows up. A platform that can only handle one program at a time will always run into the same wall once the pilot ends and the real portfolio comes into view.
An approach built for scale works differently from the start.
It learns the patterns specific to an organization’s environment, not just generic RPG syntax, so that the same shared subroutine used across four hundred programs gets recognized and handled consistently rather than re-analyzed from scratch every time. It verifies changes continuously across the portfolio rather than requiring a single, high-stakes review at the end.
And it prioritizes by what actually matters to the business, which programs carry the most risk or the most value, rather than treating every file as equally urgent simply because it’s next in line.
The Business Case for Portfolio-Wide Futurization
For the executives sponsoring this kind of initiative, the math is straightforward even if the codebase isn’t.
If 73% of what runs on IBM i is homegrown, buying a packaged replacement doesn’t solve the underlying problem for most of the portfolio. The business logic that makes an organization’s IBM i environment valuable, the pricing rules, the allocation logic, the decades of accumulated operational knowledge, has to be preserved and carried forward, not discarded.
Doing that one flagship application at a time and calling it done leaves the other ninety percent of the codebase exactly as exposed as it was before the project started.
The retirement risk doesn’t shrink. The technical debt doesn’t shrink. The dependency on a handful of people who understand undocumented logic doesn’t shrink.
A portfolio-wide approach is what actually moves those numbers, because it’s the only approach that reaches the scale where the risk actually lives.
What Changes for the Developers Doing the Work
For the developers actually doing this work, day to day, the shift is just as real, even if the business case looks different from their side of it.
Program-by-program modernization tends to turn developers into archaeologists first and engineers second. Before you can safely change anything, you have to reconstruct what a program actually depends on, often by tracing calls through copybooks and shared modules that were never documented.
With futurization at a portfolio scale, that reconstruction work happens once, systematically, across the whole environment, rather than being repeated by hand every time someone touches a new program.
That frees up time for the part of the job that actually requires judgment. Deciding whether a business rule the code implements is still the rule the business wants, not just confirming that the code still compiles. It’s a shift toward verifying business logic and away from manually re-deriving structure that a system can map on its own.
The Real Test of Futurization
A single transformed screen or program is a valuable proof point. It answers a narrow but important question: can this be done safely, without breaking what the business depends on?
A whole portfolio is a different kind of test entirely. It asks whether the approach holds up when the dependencies are tangled, the documentation is thin, and the team doing the work hasn’t grown in a decade even as the codebase has.
That’s the test that actually matters, because that’s the scale most IBM i organizations are living with right now.
If your organization is trying to figure out what a transformation looks like across an entire codebase rather than a single pilot, that’s a conversation worth having early, before the scope of the problem becomes the reason nothing moves. Reach our expert team at Futurization@ProfoundLogic.com, or explore the full approach at Agentic Futurization, powered by CoderFlow.