AS400 Modernization: Keep the Core, Replace the Green Screen

AS400 modernization without a risky rewrite: what to keep, what to replace, a phased plan and the skills-shortage facts every owner should know.

10 November 202610 min read

Vintage beige computer terminal beside a modern monitor on a desk, illustrating AS400 modernization

AS400 modernization does not have to mean replacing a system that still runs your orders, stock and invoicing. In most cases the sensible move is to keep the proven business logic on IBM i and replace the green screen, the manual re-keying and the fragile integrations around it. That gives staff and customers a modern experience without betting the business on a rewrite.

This guide is for owners and operations leads who run an AS/400, iSeries or IBM i system, or who inherited one. It covers the names, what modernisation involves, why big rewrites go wrong, how a phased plan works and what the skills shortage means for timing.

Key Takeaways

AS/400, iSeries and IBM i are names for the same platform lineage, and IBM now calls it IBM i.
Modernisation changes how people and systems reach your data and logic. Replacement rebuilds the logic itself, which is where most of the risk sits.
A phased approach, one screen or integration at a time, keeps the business running and lets you change course.
A 2026 survey by Fortra, a vendor in this market, found IBM i skills had become the number one concern among its respondents.
The best first step is a review of what the system does today, so you can decide what to maintain, connect, modernise or migrate.

What Do AS/400, iSeries and IBM i Actually Mean?

They are the same family under different brand names. IBM introduced the AS/400 in 1988, and the hardware and software were renamed several times, iSeries being one of those names. In early 2008 the operating system was given its current name, IBM i, according to IBM's own developer introduction.

The old names stuck, so people still say "AS400" and "iSeries". IBM i modernisation, AS400 application modernisation and "fixing our old green screen system" usually mean the same job.

Why Are These Systems Still Running?

Because they work, and the logic inside them is expensive to rebuild. An IBM i system often holds decades of pricing rules, customer terms and exceptions added one at a time. Nobody has a complete written list of those rules. The code is the list.

The data points the same way. Fortra's 2026 IBM i Marketplace Survey outlook reports that respondents running half or more of their core business applications on IBM i has stayed at around three quarters for years. Treat that as indicative: Fortra sells products for this platform, and respondents chose to answer a vendor survey. It is global, not Australian.

IBM's IBM i product page describes the operating system as fully integrated, with database, security and runtime licensed as one. That is IBM's own claim, but it fits why owners find these systems hard to justify replacing.

What Does AS400 Modernisation Actually Involve?

It is a set of separate jobs, and you choose which ones you need. The common mistake is treating them as one all-or-nothing project. The table shows the usual layers.

Front end - What changes: Green screens are replaced by web or mobile screens that staff and customers can use on any device.; What stays: Existing business logic and screens you still rely on.
APIs and integration - What changes: Secure REST services connect IBM i to online shops, portals, mobile apps and other systems.; What stays: The RPG programs that already calculate prices, stock and orders.
Database access - What changes: Db2 data is exposed in a controlled way for reports, dashboards and new applications.; What stays: Db2 as the source of truth.
RPG code - What changes: Tangled programs are refactored into smaller, tested pieces, and documentation is rebuilt.; What stays: The rules the code enforces.
Hosting - What changes: Support, monitoring and, if it suits, cloud hosting move to a managed arrangement.; What stays: The platform itself.

Green screen replacement is the most visible change

A new front end is what staff and customers notice first. It removes function-key navigation and puts the same data on a phone or tablet. Every calculation can still run in the original RPG program, so results match what the business already trusts.

APIs are the quiet change that matters most

Most of the value comes from connecting IBM i to everything else. A secure API lets an online shop check live stock or a mobile app place an order through the same logic your staff use. We cover how a mobile app should consume this layer in our post on enterprise mobile app architecture.

RPG modernisation is about safety, not fashion

RPG is not the problem. Poorly understood RPG is. Refactoring means making the code readable, adding tests around the parts you plan to change and documenting what it does, so the next developer can pick it up.

Why Is a Big-Bang Rewrite So Risky?

A rewrite asks one team to rebuild every rule, report and integration, then switch the business over on a single date. A missed rule shows up as a wrong invoice or a lost order. You also pay twice for a long time, because the old system must keep running while the new one is built.

Fortra's outlook page makes a related point, with the same vendor caveat. It says only about 4% of respondents plan to move all applications off IBM i within two years, and that of those planning a move, 64% have no plan to do so within two years. Fortra's view is that IT management often underestimates the time to switch. Read that as one vendor's opinion, not a law.

That does not make migration wrong. Some businesses should leave IBM i, for example when their application vendor has ended support. Decide on evidence, not because the screens look old.

What Does a Phased Approach Look Like?

Each phase delivers something usable and leaves the core running. 9Byte's IBM i modernisation service is framed the same way: its page says it helps organisations decide what should be maintained, integrated, extended, selectively modernised or migrated. A typical sequence looks like this.

Review. List the programs, screens, files and integrations, and mark which ones the business depends on daily.
Connect. Wrap the most-used logic in secure APIs so new channels can use it without touching the RPG.
Replace the worst screens. Start with those that cause errors or customer delays.
Refactor what you must change. Add tests and documentation first.
Review hosting and support. Decide between on premises and managed hosting.

An illustration only, not a client story: a distributor takes orders on green screens. Phase one adds an API for stock and prices. Phase two gives sales staff a web order screen that calls the same price logic. Phase three opens a customer portal. The old screens keep working throughout.

9Byte's page also describes a Melbourne enterprise where a REST API layer kept Db2 as the source of truth, kept existing RPG programs where appropriate and let new services run alongside older SOAP integrations during the transition. That is the pattern: new beside old, then retire old when it is safe.

How Serious Is the IBM i Skills Shortage?

Serious enough to plan around. In Fortra's 2026 IT initiatives report, IBM i skills took the number one spot among respondents' concerns, the first time since 2017 that cybersecurity was not first. It notes that few higher education programs include the operating system.

The outlook report adds that respondents planning to move some or all applications to a new operating system rose from 18% to 24%, and it names skills concern as a likely contributor. The practical reading: the person who understands your RPG may retire before your next system is ready.

That is an argument for modernising early and documenting as you go, not for panic. AI code assistants may help short-staffed teams, but they do not replace someone who understands your business rules.

Related Resources

Common Questions About AS400 Modernisation

1. What is AS400 modernization?

It is the work of making an IBM i system easier to use, connect and support without throwing away the business logic inside it. That usually means a new web or mobile front end, secure APIs, cleaner database access and tidier RPG code, rather than a full replacement.

2. Is the AS400 still supported?

IBM still sells the platform under the name IBM i, and its product page describes release 7.6. Check your own hardware and software versions with your IT team.

3. How long does AS400 modernization take?

It depends on how many screens, reports and integrations the system has. A single integration or front-end module is a smaller project, while a full programme is staged over many releases. A fixed timeline is only honest after a review.

4. What is the difference between modernising and migrating off IBM i?

Modernising keeps the IBM i system as the engine and changes how people and other systems reach it. Migrating means rewriting or replacing the applications on a different platform, which carries more risk and cost because the business rules must be rebuilt and proven again.

5. Can RPG code be modernised instead of rewritten?

Yes. RPG can be refactored into smaller, tested pieces and exposed as services that other applications call. Rewriting in another language is a separate decision and is rarely needed just to get a modern interface.

Modernise the Front, Protect the Core

The system that has run your business for years is rarely the problem. The screens, the manual re-keying and the missing integrations around it are. Fixing those first opens new sales channels and a safer path to whatever comes next, while the proven logic keeps doing its job.

If you want a plain view of what to keep, connect and replace in your own system, send 9Byte a brief describing what it runs today and what is getting in your way.