A note before you read: if you only have thirty seconds, here is the whole argument.
- Your green screens are not broken, and that is exactly why they are dangerous. Working systems never make the budget list until something forces them to.
- Two clocks changed the math in 2026: the RPG workforce is retiring faster than it is being replaced, and AI tooling cannot touch data that lives behind 5250 keystrokes.
- There are four modernization routes: screen refacing, web enablement, API-first refactoring, and full re-architecture. They differ massively in cost, speed, and what you end up with.
- Refacing is fast and cheap but cosmetic. API-first is where the compounding value is, because it opens your IBM i to web, mobile, integration, and AI in one move.
- The right first step is not picking a tool. It is a two week assessment of your screens, your code, and your integration needs.
The rest of this article walks you through each route and how to pick.
You can move an AS400 green screen to a modern interface four ways: reface the existing 5250 screens so they render in a browser, rebuild your highest-traffic workflows as web pages that call your existing programs, expose your business logic as APIs and treat the interface as one consumer among many, or re-architect the application entirely. They differ by how much code you touch, how fast you see a result, and how much you can build on afterward.
Why the Green Screen Becomes a Problem Before the System Does
The AS400 itself is rarely the thing that breaks. IBM i runs, and it keeps running. What degrades is everything that has to meet it.
Onboarding takes longer every year: New hires arrive expecting to click. Instead they memorize command sequences and function key mappings that exist nowhere except in a colleague's head. Time to competence stretches from days into months, and the people who could shorten it are the ones closest to retirement.
Data cannot leave the screen: Stock levels, order status and production counts sit in DB2/400 where the business needs them in a dashboard, a mobile app, or a partner's system. When the only interface is a 5250 session, that data gets re-keyed into a spreadsheet, which is where it starts going wrong.
Partner integrations stall: Customers and OEMs ask for API access, EDI in a newer format, or a portal. Every request turns into a custom project because the system has no modern surface to connect to.
Field and warehouse staff work around it: Anyone away from a desk cannot reach the system, so they write on paper and someone enters it later. That delay is where inventory accuracy goes.
What are the four routes from green screen to GUI?
Every vendor pitch you will hear fits one of these four. The differences in cost, time, and outcome are enormous, so know which one you are being sold.
Route 1: Screen refacing, the quick facelift
Refacing tools read your 5250 data streams and render them as web pages. No code changes, live in weeks, and your users lose the terminal emulator. For some teams that is genuinely enough, especially as a first step that buys goodwill.
Be clear about what you get, though, because refacing gives you the same screens in a browser with the same navigation logic, the same field limits, and the same everything underneath. If your pain is that the screens look old, refacing solves it, but if your pain is training time, integration, or the AI wall, refacing solves none of it. It is a coat of paint, and coats of paint are fine as long as nobody sells them to you as a renovation.
Route 2: Web enablement, modern UX where it counts
Instead of converting every screen, you rebuild the workflows that matter most, order entry, inquiries, approvals, as proper web pages that call your existing programs. Users get real modern UX on the 20 percent of screens they use 80 percent of the time.
This is the pragmatic middle path, and it is the shape of most successful first projects we see. When a global logistics firm modernized its applications with a UX redesign, the wins came from rebuilding the workflows people lived in daily rather than converting every screen wholesale. The catch is that web enablement quietly depends on how callable your existing code is, which is why it often becomes the on-ramp to route 3.
Route 3: API-first refactoring, the compounding option
This is the route where the value stacks. You carve the business logic out of your monolithic programs and expose it as APIs. Then the GUI becomes just one consumer of those APIs, alongside your mobile apps, your integrations, your e-commerce platform, and yes, your AI tooling.
The green screens become optional instead of load-bearing. Your RPG logic keeps running where it runs best, on the IBM i, but everything above it is modern and replaceable. This is also the only route that dismantles the AI wall rather than repainting it, because agents and automation connect to APIs, not to screens.
It costs more than refacing and takes longer, but it is the only route where the money you spend keeps paying you back every time you connect something new. Our IBM iSeries solution modernization work followed exactly this pattern, keeping the proven logic on the platform while opening everything above it.
Route 4: Full re-architecture, the last resort that gets pitched first
Rewriting the whole application, or replacing it with a package, is sometimes right, usually when the business logic itself no longer fits the business. But it is the most expensive, slowest, riskiest route, and it throws away decades of battle-tested logic that still works. Be suspicious of any vendor who leads with it before reading your code.
Not sure which of the four routes fits your system?
Get in touch with our IBM i modernization team. We will look at your screens and your code, then tell you which routes are realistic and what each one costs.
One examples from our own work
An Arkansas-based provider of end-to-end solutions for fitness centers across the US and Europe ran its SaaS platform on iSeries. The green screens were dated and visible to their own customers, which made them a commercial problem rather than an internal one. Documentation was thin, the legacy code had become patchy over years of change, and integrating partner solutions built on newer technologies had become difficult.
Our team worked on site to understand the priorities, then set out a phased plan. We continued supporting the legacy application so business-critical functionality kept working, and migrated the solution to a GUI in stages using web technologies rather than attempting a single cutover. The customer-facing portal was rebuilt for a better experience, and business intelligence tooling was added so the client could get insight out of data that had previously stayed on the screen.
The work ran across RPGLE, CLLE, ILE, Java, JBoss and iSeries.
What happens if you wait another few years?
The system keeps running, so there is never an obvious moment to act. The costs of waiting are real, but they arrive slowly enough that no single year makes the case on its own.
RPG developers get more expensive every year: Each retirement makes the remaining expertise scarcer. You will pay for that scarcity somewhere: in salaries, in consultant rates, or in the risk of running a system only one person understands.
The knowledge leaves without being written down: Green screen modernization forces someone to document how your system actually works. Wait long enough and that stops being documentation and becomes reverse engineering, working out your own business rules from code nobody remembers writing. This happens often enough that it has become its own engagement. We built AS400 system documentation for a food processing business for exactly that reason, so the knowledge outlived the people holding it.
The gap to competitors widens faster each year: Companies that open their IBM i data get automation and AI gains stacked on top of what they already had. The green screen does not stay still relative to them. It falls further behind, because everything around it is accelerating.
The project itself grows: Modernizing while the people who built the system are still employed is a project. Doing it after they leave is an excavation.
What should you do this quarter?
- Count your key-person risk: List the programs only one person can safely modify, and their retirement horizon. This number usually ends the internal debate on its own.
- Pick your three most painful workflows: Not screens, workflows. That is your pilot scope for any route.
- Get the code assessed: Two weeks of analysis tells you which routes are realistic and what they will actually cost for your specific system, instead of pricing from a vendor brochure.
To see what Screen modernization looks like for your specific AS400, fill the form below and we will set up a free 30 minute consultation to help you understand which route fits your screens, your code, and your budget.
Frequently Asked Questions
What is the fastest way to modernize AS400 green screens?
Screen refacing tools convert 5250 screens to web pages in weeks with no code changes. It improves the look and removes the emulator, but the underlying logic, navigation, and limitations stay the same.
Is screen scraping the same as modernization?
No. Screen scraping and refacing change how screens are displayed, not how the application works. True modernization, like API-first refactoring, changes how the application connects to users and other systems.
What happens to our batch jobs and printer files?
Nothing. Modernizing an interactive interface does not affect batch processing, job scheduling or spooled output. Those continue exactly as they do today.
Can AS400 applications get a modern GUI without rewriting the code?
Yes. Refacing, web enablement, and API-first refactoring all keep your existing RPG or COBOL logic running on the IBM i. Only full re-architecture involves rewriting the application.
Can we keep using the green screen after modernizing?
Yes. Refacing and web enablement can run alongside the existing 5250 session. Experienced operators often keep the keyboard-driven interface because it is faster for them, while new staff use the web version.
Why does green screen modernization matter for AI and automation?
Modern automation, copilots, and AI agents interact with software through APIs and web interfaces. Applications accessible only through 5250 screens are locked out of that tooling, so modernizing the interface layer is what makes the data and logic reachable.
How long does AS400 green screen modernization take?
Refacing takes weeks. Web enablement of key workflows takes a few months. API-first refactoring typically runs from several months to a year depending on code structure. A two week assessment gives real numbers for a specific system.
