AS/400 Modernization Cost

Part 8 decided which workloads to modernize and in what order. This final part takes on the question that decides whether the program happens at all: what does it cost, and is it worth it? One thing up front, because it sets the tone: this article does not, and cannot, quote a price, because the only honest cost figure for a specific AS/400 comes from understanding that AS/400 first. What it does is give you the framework to reason about the economics — the drivers that move the cost, the total cost of ownership the platform bill hides, the cost of not acting, and how to make the investment predictable rather than open-ended. The reasoning parallels the mainframe cost article; this is the AS/400-specific version.

Why there is no sticker price

An AS/400 modernization cannot be quoted from a brochure for the same reason a building cannot be renovated from a photograph: the cost is a function of the specific structure, and the specifics are exactly what you do not yet know. Two estates of similar size can differ widely depending on how entangled the RPG is, how much undocumented behavior must be recovered, how heavy the data-reconciliation burden is, and how deep the integration perimeter runs.

This is why a serious engagement begins with a fixed-scope discovery phase rather than a number. Discovery is the bounded, predictable investment that produces the estimate — a grounded assessment of effort, risk, and roadmap — before anyone commits to the larger program. On an AS/400 this matters as much as on a mainframe, because of the DB2-for-i schema-recovery problem from Part 5: for some workloads you genuinely do not know the shape of the problem until the RPG and the data have been read. Anyone quoting a firm price for a large AS/400 program before understanding the system is either guessing or padding heavily to cover the guess.

The cost drivers, AS/400-specific

The investment is shaped by a consistent set of factors. Understanding them lets you reason about your cost even without a figure — and move several of them in your favor:

• RPG size and entanglement. The raw volume of RPG and CL, and — more decisively — how tightly the programs are coupled through shared files and global data. Monolithic programs that do everything are harder to slice cleanly, which raises the cost of every increment. Coupling usually moves the number more than line count does.
• Data volume and integrity. DB2 for i reconciliation on ledger-grade or compliance-sensitive data can rival or exceed the build effort. As Part 5 warned, this is the single line item teams most underestimate, because copying rows looks trivial and proving them correct does not.
• The integration perimeter. Every inbound and outbound feed, EDI connection, file transfer, and integrated system that must be preserved or migrated is cost that has nothing to do with the RPG itself. An AS/400 wired into dozens of partners and systems carries a perimeter cost all its own.
• The interface scope. Whether the workload needs only API enablement, refacing, or a full new front end materially changes the effort. Refacing is cheap; building genuinely new channels against exposed services is more.
• Scope discipline — what you don’t rebuild. The largest lever you control. Every workload you keep, rehost, or retire rather than re-architect is cost removed from the program entirely. Decide what stays before you price what moves.
• Approach. Big-bang versus incremental changes the cost structure. Big-bang carries a large, hard-to-estimate cost plus an implicit risk premium — the overruns and rework behind the 70% transformation-failure rate (BCG, 2023). Incremental converts that into smaller, bounded increments, traded for the operational cost of running the AS/400 alongside the modern slices during transition.

Total cost of ownership, not project cost

The most common costing mistake is to compare the project cost of modernizing against the current bill for the AS/400. That comparison is rigged in the platform’s favor, because it counts the modernization in full and the AS/400 at a fraction of its true cost.

The honest comparison is total cost of ownership over a multi-year horizon, for both options. The AS/400’s TCO is not just its current run cost; it includes:

• The platform bill — Power hardware or cloud-hosted capacity, IBM i and middleware licensing, third-party tools, and specialist support.
• The skills premium and key-person risk — the shrinking RPG pool from Part 2, where 69% of IBM i organizations name skills their top concern (Fortra, 2026), means rising contractor rates and a concentrated dependency on a few people whose departure is a real, dated risk.
• Opportunity cost — the value of capabilities the business cannot ship because logic is locked on the platform, often the largest hidden number of all.
• Rising maintenance and run-the-business drag — consistent with Deloitte’s finding that roughly 55% of the IT budget goes to running existing systems rather than building new capability (Deloitte, 2020).

Set against a full TCO, modernization is frequently the cheaper option over the horizon that matters, even when its project cost is the larger number in year one.

The cost of delay is usually the bigger number

Here is the figure most AS/400 business cases under-weight, and often the most decisive: the cost of waiting. On this platform the cost of delay is unusually literal, because the skills clock is real and ticking. Every quarter a pressured workload goes unaddressed:

• The RPG skills pool shrinks and contractor rates climb, raising the eventual recovery cost.
• More of the people who hold the undocumented rules retire, so the knowledge that makes modernization safe gets more expensive — and at some point impossible — to recover.
• Capabilities the business wanted stay blocked, compounding the opportunity cost.
• The modernization effort itself grows, because there is more accumulated behavior to recover and fewer people left who remember it.

Delay is not a way to avoid the cost — it is a way to increase it while paying interest in the meantime. The right framing is rarely “can we afford to modernize this year?” It is “what does another year of this workload actually cost us, all in — including the experts we lose?”

Making the cost predictable

Unpredictability, more than magnitude, is what makes these budgets frightening — the fear is less “it will be expensive” than “it will be expensive and we won’t know how much until it’s too late to stop.” The structure that addresses this is the same one that de-risks the work:

• A fixed-scope discovery phase turns the largest unknown — what the RPG actually does and how coupled it is — into a bounded, predictable first step that produces an evidence-based estimate.
• Incremental delivery means each slice is bounded and estimated as it is planned, so you forecast a slice or two at a time with real information rather than committing to one giant number computed blind.
• The option to stop after any slice, with working software in production, means you are never locked into spending the whole projected amount on faith. That optionality caps your downside in a way a big-bang commitment never can — and because each slice ships value as it completes, ROI begins accruing after the first slice rather than waiting for a distant cutover.

When the number says don’t

AS/400 modernization is not always the economically right call, and the cost framing has to admit that plainly. If a workload is stable, under no roadmap or compliance pressure, running at predictable cost, and not blocking anything new, the lowest-cost answer is not to modernize — the platform is extraordinarily reliable, and a quiet workload nobody is pushing on may be cheapest left alone (after capturing its knowledge to kill the key-person risk). The cost-of-delay argument is powerful precisely where the pressures are real and compounding; it does not apply to a workload no one is pushing on. If the honest answer is “this is costing us very little,” modernization may be the wrong investment regardless of the platform’s age.

Closing the series

This series began with a beige box in a back room and ends here, with the economics of changing it. The throughline has been consistent: the AS/400 is not dying, so the decision to modernize is about people and agility, made workload by workload, on evidence rather than fear — and delivered incrementally, proven at parity, with the platform running throughout. When you are ready to turn that framing into a plan for your own system, a fixed-scope discovery phase is the first concrete step, and a short discovery call is how it begins. You can also browse the modernization guides for practical, scenario-specific walkthroughs, or reach us at sales@modernlift.ai.