Service · Software development

Replace your AS/400 with a modern platform.

Somewhere in your organisation, an AS/400 is probably still running, now known as IBM i on Power Systems, with RPG programmes driving stock management, production planning or logistics against a DB2 for i database. Reliable, fast at batch processing, and in operation undisturbed for decades. The problem is not the strength of the system, but what has happened around it: a green-screen interface that no longer matches how people work, a shrinking group who still understand the RPG code, and business logic that is documented nowhere outside the code. We take stock of what is there and build a modern layer around it, or replace the system gradually, process by process.

Arrange an introductory call See our work

The system is not the risk; the knowledge surrounding it is.

An AS/400 installed thirty years ago that still runs the overnight processing flawlessly is not a bad system. IBM i, the name the platform has carried since the AS/400 and iSeries were rebranded, is known for stability and speed in batch processing. Wholesalers, manufacturers and logistics providers build their core processes on it, often without ever having suffered a major outage. That is precisely why it has been left alone: it works, and nobody wants to touch a working system.

The risks have arisen elsewhere. The 5250 green screens are quick to operate from the keyboard, but they no longer match what new staff are used to and offer no route to mobile or web. RPG developers, especially those who can still read RPG II or RPG III, are scarce and on average older than in almost any other technology. And beneath the surface lie thirty years of business rules that were never documented separately, that exist only as code, and sometimes only as knowledge in the head of one person who is about to retire.

Our approach mirrors how we also approach replacing legacy software and modernising legacy software more broadly: first understand what is there, then decide what should happen. For an AS/400, that means taking stock of the RPG programmes and the DB2 for i data structure before choosing between a modern layer around the system or a full rebuild.

How we approach AS/400 projects.

Assessment first

Mapping RPG programmes and the DB2 for i structure before we build

Layer or rebuild

A modern web/API layer on the existing core, or a complete new build

Per process

One business process at a time, with the AS/400 continuing to run the rest

Data ownership

Full migration away from DB2 for i with validation and a fallback position

Three ways to approach an AS/400.

The right route depends on how stable the RPG code still is, how many external systems connect to it and how much of the business logic is already documented outside the system itself. The approaches below together cover the vast majority of the AS/400 projects we become involved in.

Approach 01

Inventorying RPG and DB2 for i

The start of every AS/400 project

We map out which RPG programs are running, in which variant (RPG II, RPG III or the more modern ILE RPG), how the DB2 for i database is structured, which batch jobs run overnight and which systems connect to the AS/400. We combine code analysis with conversations with day-to-day users, because much of the business logic cannot be found in the code alone. We never skip this step, not even under time pressure.

RPG code analysisDB2 for i structureBatch jobs mappedIntegrations inventoriedUser interviews

Approach 02

Modern web/API layer on the existing core

When the RPG logic is still reliable

If the business logic and data still work well and the problem lies mainly in the interface and connectivity, we build a layer that communicates with the existing RPG programs and DB2 for i: via direct database access, programme calls to RPG modules, or a contemporary wrapper over 5250 screens. Employees get a web interface, external systems get an API, and the proven core logic remains untouched. This is often also a good intermediate step towards a later rebuild.

API on DB2 for iProgramme callsScreen modernisationWeb/mobile accessLow-risk route

Approach 03

Phased migration per business process

When full replacement is needed

If the RPG logic itself is outdated or opaque, or if the AS/400 relies on an ISV package approaching end-of-life, we build a successor on a modern stack. Never all at once, but process by process: for example, first inventory management, then order processing, then production planning. Each process runs in parallel with the AS/400 before it switches over, with data migration from DB2 for i and a validation step that compares old and new.

Process by processRunning in parallelDB2 for i data migrationValidation stepPhased cut-over

What you take away.

A modern system in production, or a modern layer on an AS/400 that remains in place as long as it delivers value, and an organisation that no longer depends on a single person who still understands the RPG code.

Production + staging

Two environments for the new layer or the new system, either in your own cloud or hosted by us.

Documented business logic

The rules hidden in RPG, made explicit and transferable.

Migration report

Which data from DB2 for i has been transferred, which validations were carried out, and where discrepancies occurred.

Decommissioning plan

How and when the AS/400 is cleared process by process, and which archive remains.

Managed service (optional)

Monitoring, backups, security patches and ongoing development under a maintenance contract.

When an AS/400 project becomes unavoidable.

Four patterns in which postponing is no longer the safest choice, and in which we are usually first invited for an assessment before anything concrete is planned.

Skills

The RPG specialist retires

One person, internal or at a small external firm, still truly knows the RPG code. New RPG developers are scarce, and getting someone up to speed on undocumented code often takes more time than a modern layer or rebuild.

Interface

The green screen no longer suits new staff

New staff are unfamiliar with the 5250 terminal and need a long onboarding period. There is no mobile access, no way to log in remotely, and every expansion of the user group runs into the learning curve of the screen.

Integration

Connecting with modern systems is becoming increasingly difficult

A new webshop, a modern WMS or a CRM package expects real-time APIs. The AS/400 has traditionally communicated through nightly batch exports and manual file exchange, so every new integration becomes a separate custom project.

Ecosystem

An ISV package on the AS/400 approaches end-of-life

Many AS/400 environments run not only on home-built RPG but also on a package from an external vendor. If that vendor stops further development, the choice to take control yourself becomes pressing.

Risks we address explicitly.

An AS/400 project touches core processes that have often run undisturbed for decades. Four risk categories we identify up front in every project.

Data

Data loss during migration from DB2 for i

Fields that have informally come to be used for something other than what they were created for, keys that no longer hold consistently everywhere, historical records the old system tolerated. We carry out a data audit in advance and build a validation step that compares every migration against the source, with a fallback position after the switchover.

Logic

Hidden business rules in the RPG code

A special-case exception for one customer, a correction that was once meant to be temporary and was never removed, a nightly job nobody can explain any more but that turns out to be essential. We interview every user group and run old and new in parallel, so that discrepancies surface before a process goes live.

Continuity

Disruption to batch processing and core processes

Stock, production and logistics cannot simply stop. We migrate process by process, schedule transition moments in quiet periods for operations, and keep a rollback scenario ready until a process runs stably.

Adoption

Resistance from experienced 5250 users

Operators who work the green screen blind initially find a mouse-driven interface slower, even when it objectively offers more. We involve these users from the start, respect familiar shortcuts where possible, and support the transition with targeted training.

How an AS/400 project works.

01Introduction→ 02Assessment→ 03Build & migration→ 04Cut-over & support

Step 01

Introduction

Which processes run on the AS/400, who still knows the RPG code, and which pain points are urgent. A no-obligation conversation with IT and operations.

Step 02

Discovery

We analyse the RPG programs and the DB2 for i structure, interview users, and choose per process between a modern layer or a full rebuild.

Step 03

Build & data migration

Working modules delivered in sprints, running in parallel alongside the AS/400, with a validation pass for the migration out of DB2 for i per process.

Step 04

Cut-over & decommissioning

Phased transition per business process, fallback position ready, and the AS/400 decommissioned once all processes have been taken over.

From AS/400, RPG and DB2 for i to a modern stack.

We encounter AS/400 environments alongside other legacy stacks, and the approach overlaps: first understand what is there, then choose a modern layer or a full replacement. We follow the same pattern for COBOL systems and FoxPro applications, and the broader overview is under software development.

Starting point

RPG II / IIIILE RPG (RPG IV)CLDB2 for i5250 / green screenQuery/400

Target stack, frontend and backend

Next.jsAstroReactNode.jsPython.NET 8PostgreSQL

Migration & integration

ODBC/JDBC to DB2 for iProgram call APIsScreen modernisationETL pipelinesAnti-corruption layerDocker

Frequently asked questions.

Does our AS/400 system have to be replaced entirely in one go?

No. We migrate process by process, starting with the process that has the fewest integrations and the best documentation. The AS/400 keeps running for whatever has not yet been moved, so business operations never depend on one big switchover.

Can the AS/400 keep running while we build a modern front end?

Yes, often as a first step. We build a web or API layer that talks to the existing RPG programs and DB2 for i, so users and external systems get a modern interface while the core logic stays intact. That layer can be temporary or remain in place.

What happens to the data in DB2 for i?

We first inventory files, fields and keys, and which data is still actively used versus archived. We then migrate to a modern database with a validation pass against the source. The AS/400 remains available read-only as a fallback position.

We no longer have an RPG developer in-house, is that a problem?

That is more the rule than the exception. We reconstruct the business logic through code analysis, user interviews and observing the system in practice. Not everything is written down, so we let the new system run in parallel for a while to surface discrepancies.

Is a green-screen interface inherently a problem?

Not necessarily. A 5250 screen is often fast for experienced users, and the logic behind it can be perfectly sound. The problem usually lies elsewhere: new staff, no mobile access, or systems that cannot integrate in real time. We determine case by case whether a front layer is enough.

How long does it take to replace or modernise an AS/400?

That depends on the number of processes, the documentation and the number of integrations. Because we migrate process by process, you will see a process in production after the inventory and the first sprints. We only give a timeline once that inventory is complete.

What determines whether we build a modern layer or rebuild the system entirely?

Mainly how stable the RPG code still is, how many systems depend on it, and whether the pain lies in the interface or also in the logic. If the core logic runs reliably, a layer is often sufficient. If the logic itself is outdated or tied to a package being phased out, a rebuild is the better route.

Will we remain the owner of the new software and data?

Yes, fully. Code, infrastructure, documentation and credentials are in your name, in an environment you manage yourself or that is handed over to you. The migrated data also remains yours, with a documented export format for any future migrations.

Talk to us about your AS/400.

A non-binding half-hour introductory conversation. We listen to which processes run on the system, where it hurts, and what prompts you to look at it now, even if it turns out the system can remain in place for some parts.

Schedule an introductory call Email fabian.vandijk@appfront.nl