1
Discovery
We list libraries, programs, files, data areas, job queues and users, and flag dead objects, undocumented jobs and external dependencies.
AS/400 and IBM i
AS/400 and IBM i modernization for RPG applications
Many IBM i applications are stable and valuable. We help you choose between new interfaces, APIs, partial rewrites and migration, and sequence the work to protect the business.
- RPG, CL and DB2 for i reviewed first
- Green screens replaced without a big bang
- APIs, rebuild or stay, decided per module
Should we leave AS/400 or modernize in place?
For many organizations the honest answer is to modernize in place first. IBM i has a long record of running core business processes, and the RPG code often holds rules that took years to get right. Replacing the interface and adding APIs delivers visible change at lower risk than a rewrite.
Leaving the platform makes sense when the real constraint is something else: a shrinking pool of RPG developers, a vendor package at end of life, a corporate decision to exit the hardware, or a need to integrate with a stack that IBM i cannot serve well. In that case the work looks like our legacy application modernization approach: assess, pilot one slice, then migrate in phases.
We start with a review of objects, programs, display and printer files, job schedules and data, so the decision is based on what is actually there.
What can be modernized on IBM i
IBM i is a reliable platform. Modernization usually targets the parts that limit your business, not the whole system.
-
The user interface
Replace 5250 green screens with web screens that call the existing RPG logic, so users get a modern front end without a logic rewrite.
-
Integration
Expose RPG programs and database tables through REST services, so other systems stop relying on file transfers and screen scraping.
-
The code
Convert fixed-format RPG to modern free-form RPG, modularize large programs and add automated tests where none exist.
-
The data
Move DB2 for i data to another database, or keep it and add replication for analytics and new applications.
How an IBM i project runs
The order matters. Interfaces and APIs come first because they reduce risk for everything after.
2
Decide per module
Each application area is marked retain, wrap, refactor, rebuild or retire, with the reasons written down.
3
Pilot a thin slice
One screen flow or one integration is rebuilt first and run beside the existing one so users and operators can compare.
4
Expand in phases
Further modules follow in planned groups. Each has tests, a rollback path and a sign-off before the old version is switched off.
Keep RPG or rebuild elsewhere
| Keep and refresh | Rebuild or migrate | |
|---|---|---|
| Business logic | Kept as it runs today | Re-implemented and retested |
| User impact | New screens, same rules | New system and training |
| Skills needed | Some RPG knowledge stays | RPG knowledge fades out |
| Risk profile | Lower, change is gradual | Higher, more to verify |
| Fits when | System works, UI is dated | Platform exit is decided |
Risks and limits
IBM i applications often grow around the platform. Business logic may live in display files, in CL scripts, in triggers and in jobs started by hand, so a quick look at the RPG alone misses behavior. Printed output and spooled files are another hidden dependency, since other departments may depend on them.
- Wrapping code with APIs does not fix poor structure. It makes it safer to reach, not easier to change.
- A rewrite takes longer and costs more than it appears to, because the old system holds many small rules. We do not promise dates or savings before assessment.
- Moving to the cloud does not by itself modernize anything. It changes where the same code runs.
When the system is working and well supported, the correct recommendation can be to improve it lightly and leave the rest.
AS/400 and IBM i questions
- Is AS/400 obsolete?
The platform is still supported and in use, now under the IBM i name. What ages is the application layer: green screens, fixed-format code and file-based integration. Those can be modernized without leaving the platform, which is often the lowest-risk first move.
- Can we replace green screens without rewriting RPG?
Yes. A web front end can call existing RPG programs through service interfaces, so the logic stays as it is while the screens change. Some screens need small changes in the programs to separate display from logic, and we scope that during discovery.
- What if we only have one RPG developer?
That is a common risk and a good reason to act. We document the code, add tests, and move toward modular, readable programs so knowledge is not held by one person. Your developer is a key source for the review, and we plan around their time.
- Can IBM i data feed new cloud applications?
Yes. Replication or change capture can copy DB2 for i data into another database for reporting or new services, while the core application continues to run. We would size the load on the system first so production is not disturbed.
- Which other pages are relevant to IBM i work?
If you are considering a hosted or cloud target, read about cloud migration. For rewriting core logic and the testing techniques that protect it, see COBOL modernization, which shares many of the same practices even though the language and platform differ.
Describe your IBM i environment
Message us on WhatsApp at +92 326 5200333 or use the request form. We reply with questions and next steps, and a mutual NDA can be signed before you share details.
What to send
- Applications and what they do for the business
- IBM i version and hardware or hosting
- Languages in use: RPG, CL, SQL, other
- Number of users and external integrations
Chat on WhatsApp
Request a code audit
Please keep credentials and source code out of the first message.
Running a business on IBM i?
Send the request form or message us on WhatsApp with the applications, the OS version and what you want to change.