// DEEP DIVE | LEGACY INTEGRATION
IBM i (AS/400) Modernization: Legacy Integration Instead of Innovation Theater
AS/400 modernization does not automatically mean migration. Most digitization projects fail precisely at the attempt to replace working cores wholesale. We go a different way: we use your stable IBM i as the foundation and make it API-capable for the AI era. Proven RPG code stays where it is. Modern interfaces get added on top.
THE PROBLEM
67 percent of migrations fail because they were never necessary
Every IBM i estate carries decades of RPG code that encodes complex business logic. Price calculations, commission models, special agreements with key accounts, material configurations. Much of it is not cleanly documented anywhere because the logic grew with the company. Rewriting that in Python introduces errors no one notices until a customer complains.
Yet many boards still buy into the narrative "the AS/400 has to go, it's stone age." Rarely is there a real business argument behind it, often just fashion. The IBM i is unbeatable for transaction integrity, uptime, and DB2 performance. What is missing is not stability, it is connectivity.
We call this innovation theater: lots of motion, lots of budget, in the end the old machine still runs in the basement and makes the revenue. The honest question is not whether you replace the IBM i, but how you connect it to the modern world without touching it.
Why do migrations from AS/400 systems fail so often?
Because decades of RPG code carry complex business logic that is barely documented. A rip-and-replace often leads to data loss and operational downtime. The pragmatic solution is therefore not replacement but integration via an API wrapper. Proven ILE RPG service programs become REST endpoints. The DB2 for i opens up via SQL for AI models. Closed applications without source code get operated through 5250 terminal emulation via RPA. The machine in the basement stays. The interfaces facing outward become modern.
Drei Wege auf die IBM i, je nach Ausgangslage
/ OUR APPROACH
01
Step 01
RPG to REST API (The Wrapper)
You have price calculation, bonus computation, or material configuration already programmed in RPG. It has run flawlessly for years. Instead of rewriting it in Python and introducing errors, we build a wrapper around the existing ILE RPG service programs. The web shop or the AI model calls in via JSON, the AS/400 calculates as always, and answers through a modern REST interface. Decades-old logic becomes a microservice.
02
Step 02
DB2 SQL access for AI models
AI models need data in a form they can process. We set up performant SQL views on your physical files (PF/LF) so an AI agent can query stock levels, customer histories, or open items in real time. Without anyone needing to open the green screen. The SQL views are read-only. Write access continues to go through the existing RPG programs.
03
Step 03
5250 terminal emulation as fallback
If no source code is available any more (typical for third-party applications whose vendor disappeared years ago), we fall back to 5250 emulation via RPA. A bot emulates the user at the terminal, reads defined screen positions, and types entries. Not elegant but extremely effective and deployable in days, where otherwise a six-figure rebuild would be needed.
04
Step 04
Security and authorization concept
We use IBM i native authorization objects exclusively. A dedicated integration user gets only the object authorities required for the defined use cases. No global privileges, no modifications to existing profiles. Every action is traceable in the IBM i journal.
Your most stable server does not have to be the dumbest
The IBM i is unbeatable for transaction integrity, data integrity, and uptime. The problem is not the machine, it is the isolation. We break the silo open without damaging the foundation. Your RPG programmer continues to maintain the core, we build the interfaces around it. Two worlds, separated responsibility, shared value.
67 %
failure rate on full AS/400 migrations
Industry reality: 67 percent of companies fail at AI integration because they try to bypass legacy systems instead of embedding them. Your IBM i has run flawlessly for 20 years and makes the revenue. Why throw that asset away? With the integration approach, the first API stands in 4 to 8 weeks, the system stays in production, and the migration-risk discussion becomes obsolete.
The difference in numbers
Factor
Full replacement (risk)
API integration (Xanevo)
Time to value
2 to 5 years
4 to 8 weeks
Risk
67 percent failure rate
Minimal, system stays in production
Cost
Seven figures (consulting and license)
Five figures (implementation)
Business logic
Rebuilt from scratch, untested
Proven RPG code stays
Downtime
Cut-over weekends, high risk
No downtime, run in parallel
Three questions IBM i owners ask
No. Your RPG programmers continue to maintain the core where their strengths lie. We build the interfaces with our own skills (Python, REST, SQL). Two worlds, clean separation of responsibility. In times of scarce RPG resources, this is an advantage: you do not lock your internal expertise into new builds, you keep it on the logic layer.
Yes. We use IBM i native authorization objects exclusively (object authorities, authorization lists). The integration user gets only the rights needed for the defined use cases. No global privileges, no changes to existing profiles. Every action lands in the IBM i journal with user ID and timestamp.
Yes. The wrapper principle is identical: existing business logic stays untouched, a REST layer makes it API-capable. We have experience with COBOL on mainframe systems (z/OS) and with hybrid landscapes where IBM i, mainframe, and modern cloud applications need to coexist.
Related deep dives
SAP Integration
Side-by-side connection to SAP R/3 and S/4HANA via BAPI, IDoc, and OData. Different world, same principle: core untouched, interfaces modern.
Microsoft Dynamics
Custom connectors for NAV, Business Central, AX, and Dynamics 365 where Power Automate runs out of road.
// XANEVO | IBM i / AS/400
Let's review your integration options.
Which IBM i version is in use, which RPG or COBOL programs are critical, where is source code still available? We review your integration options, identify the fastest paths to API capability, and deliver a concrete recommendation. No sales pressure, no migration agenda.