What Is AS/400 (IBM i)?

In thousands of mid-market manufacturers, distributors, regional banks, insurers and wholesalers, the system that takes the order, prices it, checks the stock, cuts the invoice and posts the ledger is a beige or black box in a back room that almost nobody looks at. It has run for twenty, thirty, sometimes nearly forty years. The screens are green text on black. The people who built the programs are mostly retired. And it has never, in living memory, been down for a reason anyone can remember. That box is an AS/400 — and this series is about modernizing it without breaking the one system the business cannot run without.

This first part defines the territory: what the AS/400 actually is, why it has survived four decades and four name changes, what makes it different from a mainframe, and why the case for modernizing it is a decision about people and agility rather than a forced march off a dead platform. The eight parts that follow go deep on each piece — the skills cliff, the RPG language and how to modernize it, DB2 for i, the 5250 green screen, the move to cloud, the keep-or-migrate decision, and the cost.

What the AS/400 actually is

IBM introduced the Application System/400 in 1988 as an integrated business computer: not a database you bolted onto an operating system you bought separately, but a single, tightly integrated platform where the OS, the relational database, and the programming environment were designed together and shipped as one. That integration is the platform’s defining trait and the reason it has been so durable. The pieces you will get to know across this series:

• The operating system. Originally OS/400, today IBM i. It is famous for stability, an object-based design, and a single-level storage model that treats memory and disk as one address space. It is also famously closed: the platform’s strengths and its modernization friction come from the same place.
• RPG — the language most of the business logic is written in. Report Program Generator began as a tool for printing reports and grew into a full business language across dialects: RPG II, RPG III (RPG/400), RPG IV (ILE RPG), and modern free-format RPG. A single shop often has all of these layered on top of each other.
• CL — Control Language — the scripting that glues programs together, drives the job scheduler, and runs system operations. Most AS/400 estates have a large, under-appreciated body of CL alongside the RPG.
• DB2 for i — the relational database built into the operating system. Unlike a bolted-on database, it is part of the platform, accessed both by old-style record-level I/O and by SQL. Tables are often still defined in legacy DDS rather than SQL.
• The 5250 green screen — the character-based terminal interface, defined by display files and delivered over the 5250 data stream. It is fast and keyboard-driven, and it is the face of the system most users have only ever known.

None of this is broken. It is the opposite of broken — it works, at a reliability most modern systems never reach, on hardware that has been continuously updated underneath it. That is exactly why it is hard to replace, and why respect for it is the starting point, not an afterthought.

The names: AS/400, iSeries, System i, IBM i

One source of confusion deserves clearing up immediately, because it trips up every conversation about this platform. The machine has been renamed repeatedly:

• 1988 — AS/400, running OS/400.
• 2000 — rebranded eServer iSeries.
• 2006 — rebranded System i.
• 2008 onward — IBM split the branding: IBM i is the operating system; Power Systems is the hardware it shares with AIX and Linux.

Practitioners still say “AS/400” decades after IBM retired the name, the way people still say “Xerox” for photocopying. Throughout this series we use “AS/400” and “IBM i” interchangeably, because the buyers we work with do. When someone tells you they run an AS/400, they almost always mean a current or recent IBM i system on Power hardware — not a museum piece.

Why it is still here

The AS/400 survived because it is genuinely excellent at what it does. It is reliable to the point of being invisible. The integrated database means data integrity is enforced at the platform level. Backward compatibility is close to absolute — programs compiled decades ago still run, which is a gift operationally and a trap for modernization, because it means nothing ever forced a cleanup. And for the mid-market core it was sold into — order entry, distribution, manufacturing, banking back-office — it was simply the right tool, and replacing a working core is expensive and risky.

The result is a platform that is not legacy in the sense of broken, but legacy in the sense of isolated: a closed, reliable island running business-critical logic that the rest of the modern stack struggles to reach.

How it differs from a mainframe

The AS/400 is often mentioned in the same breath as the IBM mainframe, and the mainframe modernization series covers many shared principles. But they are different machines for different buyers, and conflating them leads to wrong decisions.

Dimension	IBM mainframe (IBM Z, z/OS)	AS/400 (IBM i on Power)
Typical buyer	The largest banks, insurers, and governments	Mid-market manufacturers, distributors, regional banks and insurers
IT footprint	Large teams, large budgets, dedicated systems staff	Small teams, tight budgets, often no one who remembers the original design
Core language	COBOL, with PL/I and Assembler	RPG, with CL and some COBOL
Database	DB2 for z/OS, plus VSAM and IMS datastores	DB2 for i, built into the operating system
How it is assembled	Separately-evolved pieces stitched together (CICS, JCL, VSAM, DB2)	OS, database, and runtime designed together as one integrated whole
Terminal interface	3270 green screen	5250 green screen

The integration line is the one that matters most for modernization. On the mainframe you can often modernize one subsystem (say, the CICS transaction tier) somewhat independently of the others. On the AS/400 the database, the language, and the OS are so tightly woven that the RPG, the DB2 for i tables, and the display files usually have to be read and moved as one connected system.

The practical upshot: AS/400 modernization is usually a smaller, more self-contained problem than a mainframe program, but it runs into the same core risk — undocumented business rules buried in code, held by a workforce that is leaving.

Why modernize it at all — the honest framing

Here is the point this series is most careful about. The AS/400 is not end-of-life. IBM actively supports IBM i; version 7.5 shipped in May 2022, it runs on current Power hardware, and IBM’s published roadmap commits support well into the 2030s (IBM, 2022). Anyone telling you to migrate because the platform is “dying” is selling fear with a false premise.

The real case for modernizing is different, and more honest:

• The skills cliff. The RPG workforce is retiring and is not being replaced — colleges do not teach RPG, and the hiring pool shrinks every year. In Fortra’s 2026 IBM i Marketplace Survey, 69% of respondents named IBM i skills as a top concern, up from 60% the year before, and 62% named application modernization (Fortra, 2026). Part 2 is entirely about this.
• Agility. The closed runtime and green-screen interface make it slow and expensive to connect the AS/400 to mobile apps, web portals, partner APIs and modern analytics. The business logic is sound; reaching it is the problem.
• Undocumented rules. Decades of RPG encode business behavior nobody wrote down — the pricing exception, the rounding rule, the special handling for one customer type. That knowledge is walking out the door with the people who hold it.

So the decision is not “escape a dead platform.” It is “capture what this system knows and free its logic for modern channels before the people who understand it are gone.” That reframing matters, because it means doing nothing is a legitimate option for some workloads — a question we take seriously in Part 8.

The range of modernization options

“Modernize the AS/400” is not one project. It is a spectrum, from touching almost nothing to replacing everything, and the right point on that spectrum depends on where the pain actually is. Most real programs use more than one of these at once, applied to different parts of the estate.

• Stay and maintain. Keep IBM i, keep the RPG, and just fund the maintenance. Legitimate for a stable core under no agility or skills pressure. It solves nothing about the retiring workforce, but it is honest as a holding position while you plan.
• Surround and API-enable. Leave the RPG core in place and put modern interfaces around it. The business logic keeps running on IBM i, and you expose it through web services or APIs so mobile apps, portals, and partners can reach it. This is the fastest way to relieve the “we cannot connect to it” problem without rewriting the logic. It does not address the skills cliff, because the RPG still has to be maintained.
• Refactor on IBM i. Modernize the code in place. Convert fixed-format RPG to free-format ILE RPG, break monolithic programs into callable modules, move data definitions from DDS to SQL DDL, and replace green-screen flows with a web UI while staying on the platform. You keep the reliability of IBM i and make the code approachable to a wider pool of developers.
• Rewrite or replatform off IBM i. Move the business logic onto a modern stack, most often Java or another mainstream language, on standard infrastructure. This is the transformative option and the most involved, because the RPG, CL, DB2 for i, and 5250 layers all have to be understood and re-expressed. Done as a big-bang rewrite it is also the option that fails most often, which is why it has to be done incrementally.
• Replace with a package. Retire the custom AS/400 application entirely and move to a packaged ERP. This is not modernization, it is replacement, and it only works when your process is standard enough to fit the package. The trap is that the AS/400 usually survived precisely because it encodes decades of business-specific behavior a package will not match without heavy customization.

The pattern that fails most reliably is the all-at-once rewrite or the rip-and-replace ERP swap that cuts over on a single date. The pattern that works is incremental, whichever destination you pick.

What drives the cost and difficulty

There is no list price for AS/400 modernization, because the effort tracks the estate, not a SKU. A handful of factors do most of the work in deciding whether a modernization is weeks per slice or months:

• The volume and age of the RPG and CL, and how much of it is undocumented. Reading and re-proving business rules nobody wrote down is the slowest, most expensive step. A shop with millions of lines of RPG II from the 1990s, and no one left who wrote it, is at the hard end.
• How the data is defined. Files defined in legacy DDS, often with logic living in the file layer, take more work to modernize than tables already defined in SQL.
• How tightly the 5250 UI is coupled to the business logic. When display-file handling and business rules are tangled together in the same RPG programs, separating the UI you want to replace from the logic you want to keep is real work.
• The integration surface. Every external system the AS/400 talks to, and every batch job and interface, is a boundary that has to be preserved through the move.
• Whether you stay on IBM i or leave it. Refactoring in place is cheaper than replatforming onto a new stack. Leaving IBM i buys a mainstream talent pool but costs a full re-expression of the logic.

The approach that works

Everything in this series assumes one approach, the same one the broader field has learned the hard way: incremental, parity-proven modernization with the AS/400 running throughout. The alternative — a multi-year big-bang rewrite or a rip-and-replace ERP swap that cuts over on a date — is the approach that fails most reliably; Boston Consulting Group found that up to 70% of digital transformations fail to meet their objectives (BCG, 2023). On a system that runs the order-to-cash core, that failure mode is not a missed deadline; it is a business that cannot ship product or bill customers.

The approach that works reads the RPG, CL, DB2 for i and display files together as one connected system, captures the undocumented rules as living specs, rebuilds a slice of business behavior at a time, proves each slice behaves identically to the AS/400 through parity validation, and cuts over gradually behind a facade with rollback available at every step. AI-accelerated discovery changes the economics of the slowest step — reading and documenting decades of RPG nobody remembers — but it is the parity gate, owned by senior engineers, that makes the cutover safe. AI is how we read faster; it is never left to decide what is correct.

Where this leads

This part defined the platform and reframed the reason to modernize it around people and agility rather than a faked end-of-life. The single force driving most AS/400 decisions is the one we have only named so far: the RPG workforce is retiring, and the knowledge of how these systems actually work is leaving with them. Part 2, AS/400 Talent Shortage & Risk, looks at that skills cliff in detail — what the numbers say, what it costs a business when the last RPG developer retires, and why capturing tribal knowledge as living specs is a race against the calendar rather than a documentation project.