Many companies still run production, warehousing, orders and invoicing on a business system that has been going for twenty years or more on an AS/400. Today that platform is called IBM i (it went from AS/400 to iSeries, System i and finally IBM i), but the name almost everyone still uses is the first one. Faced with a system this old, the instinctive reaction is to think it should be scrapped and rebuilt. Almost always that is the wrong conclusion. The problem is rarely the machine, which remains reliable and fast. The problem is that the system lives isolated from the rest of the world, depends on an increasingly rare skill, and was often never designed to be exposed to the outside safely. These are three different problems, and none of them is solved by rewriting everything from scratch.
The AS/400 system works: the problem is elsewhere
An AS/400 that has been in production for years has an underrated virtue: it holds the company's business logic, refined by decades of real cases, exceptions and fixes. Rewriting it from zero means throwing that asset away and risking the reintroduction of bugs that were already solved. That is why the real risks are three others. The first is isolation: the system does not talk to the website, the app, the customer and supplier portals, the other applications. The second is skills: the language it is written in, RPG, is mastered by ever fewer people, many close to retirement. The third is security: born in an era when the system sat locked in a machine room, it is not necessarily ready to be reached by a modern network.
Why modernise the AS/400 instead of rewriting it
The most common proposal is also the riskiest: redo everything on a new platform, in one go. On paper it is seductive; in practice it is the kind of project that most often overruns time and budget, or fails outright. A system that keeps the company running cannot be switched off for months while its replacement is built, and rebuilding years of rules in a single migration means discovering too late all the details nobody remembered.
The mature alternative is not to replace, but to connect: leave the AS/400 doing what it does well and build around it, step by step, the modern layer it lacks. Each step delivers concrete value straight away and can be paused or corrected without ever having put the heart of the system at risk.
How to integrate the AS/400 with APIs over RPG and DB2
The first building block is to give the system a modern communication port. The RPG programs and the DB2 for i database that live on the AS/400 can be exposed, without modifying them, behind APIs: interfaces that speak today's language (web requests, JSON) and that other systems already know how to use. The system's database is fully queryable in SQL, and the platform runs Java as a first-class, fully supported runtime: this makes it possible to build a service layer that reads from and writes to the system through stable channels, without rewriting the logic inside it. These are the same standard tools used for any modern application: for example a Java framework such as Spring Boot for the service layer, which talks to DB2 naturally. From the outside the system becomes a service like any other; inside, it stays exactly as it was.
This is the pattern known in the literature as the "strangler fig": instead of replacing the system in one move, a modern shell is built around it that intercepts requests and absorbs one function at a time. Old and new coexist, and the handover happens gradually, as each single piece is ready and verified.
From the 5250 green screen to a modern web interface
With those APIs in place, the next step is the interface. The classic green-character screens (the 5250 terminal) work, but they put off younger users, make training slow and do not exist on a phone. On top of the service layer a web interface can be built, and where needed an app, with widespread component libraries (such as React) consuming the JSON produced by the APIs, and with the experience people expect today. The operator works on a modern screen; behind it, every action reaches the same old system. An honest caveat: redoing the interface does not mean photographing the old screens and pasting them onto a web page, a fragile shortcut that breaks at the first change. It means rebuilding the interaction on top of the APIs, where data and rules travel through stable channels.
Integrating the AS/400 data with other systems
An isolated system keeps its data locked inside itself. Often it is needed elsewhere: to feed another application, to exchange it with a supplier or customer portal, to produce up-to-date extracts. Because the DB2 for i database is queryable in SQL, that data can be made available to other systems in a controlled way, or copied continuously to another database when it needs to stay aligned. The delicate point is not technical, it is one of method: expose only what is needed, through dedicated reads, without handing whoever is outside the keys to the whole system.
Securing IBM i during modernisation
Here lies the point too many modernisation projects overlook, and which is in fact decisive. Exposing a system born to stay locked in a machine room to a modern network multiplies its attack surface. This is not a theoretical risk: real vulnerabilities are found on IBM i too, and an access configuration inherited from twenty years ago often grants more power than necessary. Modernising without securing means building a new house on an old lock.
Modernisation done well treats security as part of the project, not as a final touch-up. The API layer is not only a technical convenience, it is also the control point: it is there that it is decided who can do what, requests are validated, access is tracked and direct exposure of the system is avoided.
On the system itself the principle of least privilege applies: every technical account gets only the powers it needs, and the broadest authorities (those equivalent to the system's all-powerful administrator, historically the QSECOFR profile) stay restricted and watched. Recent versions of IBM i add modern tools, such as multi-factor authentication, that should be used. The rule is simple: every door opened to the outside must be designed to withstand whoever will misuse it, not only whoever will use it well.
Reducing dependence on RPG developers
The third problem, skills, is addressed without drama but without postponing it. Finding and keeping people who know RPG is increasingly hard and expensive, and tying the company's survival to a handful of people is a risk in itself. The same gradual approach offers a way out: as the service layer is built, the logic that changes most often can be moved, one piece at a time, towards widespread technologies for which skills are easy to find. It is not a race to dismantle the system, it is a controlled reduction of dependence: the stable core stays where it is, the parts that evolve migrate to where the labour market is wider.
Modernising the AS/400 one step at a time, with controlled risk
The thread tying it all together is the method: no total migration, but a sequence of bounded steps, each with a clear purpose and a verifiable result. It almost always starts with an initial analysis: understanding how the system is built, which data and programs really matter, where the security risks are, and which integration is worth starting from. From there the first block that delivers value right away is chosen (often a single integration, or one critical screen rebuilt), delivered at a defined scope and price, and only then is the next step decided. That way the investment stays under control, the system never stops, and at every stage there is something that works, not a promise.
In short
- The AS/400 (IBM i) is usually not the problem: it is reliable and it holds the company's business logic.
- The real risks are three: isolation from other systems, ever rarer RPG skills, and security designed for a closed world.
- Rewriting everything in one go is the most expensive route and the most exposed to failure.
- The mature path is to connect, not replace: APIs over programs and database, without touching their core.
- On top of the APIs: a modern web interface in place of the green screen, and data integrated with other systems.
- Security is designed alongside the rest, not bolted on at the end: least privilege, a single control point, strong authentication.
- One step at a time, each with concrete value and bounded risk, starting from an initial analysis.
Frequently asked questions about AS/400 modernisation
How much does it cost to modernise an AS/400 system?
There is no single price: it depends on which integrations and interfaces are actually needed. That is exactly why it is worth starting from a low-cost initial analysis that defines the scope and priorities of the first block. The phased approach keeps costs and timelines predictable, because each step has a defined scope and price before it begins.
Does the AS400 have to be switched off during migration?
No. The idea is to build the modern layer alongside the system, which stays in production. Old and new coexist and functions move over one at a time, as each is ready and verified. There is no shutdown while a replacement is built.
Can the AS/400 be integrated with e-commerce and e-invoicing?
Yes. Once the system is exposed behind APIs, its data and functions become available to other systems: an online shop, a supplier or customer portal, document exchange (EDI) or electronic invoicing. Only what is needed is exposed, in a controlled way.
How can the shortage of RPG developers be addressed?
With the same gradual modernisation: as the service layer is built, the logic that changes most often can migrate towards widespread technologies for which skills are easy to find. The stable core stays on the AS/400, and dependence on a rare skill is reduced over time.
Is it better to modernise or rewrite from scratch?
In the vast majority of cases modernising is better. Rewriting everything in one go means throwing away decades of business logic and taking on the project most likely to fail. Connecting and replacing gradually delivers value straight away and keeps risk under control.
Connecting the past to the present, safely
Modernising an AS/400 system does not mean disowning what has worked for twenty years. It means connecting it to the present, safely, without stopping the company and without betting everything on a rewrite. The first step is not a big project, it is a question: where is it worth starting, and at what risk.
The simplest way to answer it is to start from an initial analysis: understanding which data and programs really matter, where the security risks are, and which integration is worth starting from. It is a first step at a defined scope and price, not a commitment to the whole project.
For the services these projects are delivered with: Legacy system integration and modernisation.
Originally published on custralis.com.
Top comments (0)