An AS/400 has run core transactions for 30 years because it is exceptionally reliable, up to eight 9s of uptime on current IBM hardware (ITIC, 2023). What it lacks is real-time visibility, mobile access, and lot traceability. The fix is usually a layer built around it, not a risky replacement of the system the whole business runs on.
Why an AS/400 has lasted 30 years
An AS/400 (IBM's midrange system, now called IBM i, that many distributors and manufacturers still run their core transactions on) survives because it almost never fails. In the 2023 ITIC reliability survey, 88% of users on current IBM Power hardware running IBM i reported eight 9s of uptime, about 315 milliseconds of unplanned downtime a year (ITIC, 2023). Its transaction reliability (the ability to process orders, inventory, and invoices without errors or outages) is the reason it has never been worth the risk of ripping out. Downtime is expensive: 90% of organizations put an hour of it above $300,000 (ITIC, 2024). A system that does not go down protects that money.
What an AS/400 does not do on its own
The AS/400 was built to process transactions, not to show them. It does not produce real-time dashboards, it does not run on a phone in the warehouse, and it does not connect on its own to modern logistics, CRM, or analytics tools. Operational visibility (seeing margin, inventory, and service levels as they change, not at month-end) is the gap, along with mobile access and lot traceability. None of that is a flaw in the core. It is simply work the system was never designed to do.
The real risk is one person, not the machine
The larger risk in most AS/400 shops is not the hardware, it is key-person risk (the business depending on one person who understands the system). Often that is a single RPG programmer in their late fifties or sixties. Roughly half of IBM i professionals are 56 or older, and the typical RPG developer is near retirement age (IT Jungle, 2024). Replacing the whole system does not remove that risk. It amplifies it, because the migration itself depends on the same scarce knowledge. Documenting the logic and adding a modern layer around it spreads the knowledge instead of betting the business on a rebuild.
How a layer adds what the AS/400 lacks
The lower-risk path is to leave the AS/400 as the system of record and build around it. An API layer (a connection, usually through ODBC or DB2, that lets modern tools read and write the AS/400's data without changing it) feeds a dashboard on a current stack and a mobile interface for the warehouse floor. The core keeps processing transactions exactly as it does today.
In our work with distributors still running on an AS/400, the core is rarely the problem; the gap is everything around it. That is the approach behind our legacy modernization work, and the same logic covered in ERP augmentation strategy and whether the ERP is really the problem.
Lot traceability without replacing the system
Food businesses face a specific pressure: lot traceability (tracking a product's lot through the supply chain, required under the FDA Food Traceability Rule, FSMA 204). The compliance date is July 20, 2028, and the FDA has been directed not to enforce it before then (Federal Register, 2025). That requirement does not mean replacing an AS/400. The lot and event data already lives in it. An add-on layer captures the tracking events and produces the records the rule requires, on top of the system that already holds the data.
Frequently asked questions
Why does an AS/400 stay in service for decades?
Because it is built for reliability. In the 2023 ITIC survey, IBM i on current Power hardware reached eight 9s of uptime, about 315 milliseconds of unplanned downtime a year. It processes core transactions, orders, inventory, and invoices, without failing, which is why replacing it has rarely been worth the operational risk for the businesses that depend on it.
What can an AS/400 not do on its own?
It does not produce real-time dashboards, run on mobile devices, connect on its own to modern logistics or CRM tools, or provide predictive analytics and lot-tracking views. These are not defects. The system was designed to process transactions reliably, not to visualize or share them, so those capabilities have to be added around it.
Can lot traceability for FSMA 204 be added without replacing the AS/400?
Yes. The lot and event data usually already lives in the AS/400. An add-on layer captures the required tracking events and produces the records the FDA Food Traceability Rule asks for, without changing the core. The compliance date is July 20, 2028, which leaves time to add a layer rather than run a full replacement under deadline pressure.
What is the risk of relying on one RPG programmer?
If one person holds all the knowledge of the system, the business is exposed the day they retire or leave. About half of IBM i professionals are 56 or older (IT Jungle, 2024). Replacing the system does not fix this, since the migration depends on the same knowledge. Documenting the logic and adding a layer spreads the risk across more people and tools.
How can dashboards and mobile access be added to an AS/400?
Through an integration layer that reads the AS/400's data, usually over ODBC or DB2, and feeds a dashboard and a mobile interface built on a modern stack. The AS/400 keeps processing transactions unchanged. Nothing is migrated off the core, so the reliability stays intact while the visibility and access get added on top.
Where a replacement helps, and where it does not
Some systems genuinely need replacing. An AS/400 running clean transactions usually is not one of them. The lower-risk, lower-cost move is to add the visibility, access, and traceability it lacks and leave the core alone. If an AS/400 still runs the business and the gaps are everything around it, a layer is the answer. 3ALICA builds those layers on the existing system. Tell us which gap is costing the most.