To the uninitiated, green screens look like fossils. To those who use them daily, they’re lightning-fast tools of work. This is the contradiction at the heart of every modernization effort. The success of a migration is not just in solving the technical issues, but also in considering that the main question is not how to migrate, but for whom. Get that wrong, and modernization turns from progress into disruption.

What Are Green Screens?

Green screens are text-based interfaces used on IBM i (formerly AS/400) systems. They run on terminals that display a fixed 24×80 character grid, where every field, function key, and shortcut is precisely defined. For many, they look like fossils of a bygone computing age—but appearances can deceive.

For newcomers, green screens are intimidating: no mouse, no icons, just endless codes and cryptic key combinations. They seem rigid, unfriendly, and outdated compared to today’s graphical applications. Yet for many veteran employees, these same interfaces are tools of unmatched productivity.

Take the warehouse operator who can process hundreds of orders an hour by instinctively pressing F5, F9, or F12 at the right moment—without ever glancing at a mouse. Or the accountant who knows exactly which screen and which field to reach in three keystrokes. What looks like an archaic constraint to outsiders is, for these insiders, pure efficiency.

This dual perception explains why green screens survive: while they may repel new generations of users, they remain beloved by experts who have spent decades mastering their logic. In modernization projects, this clash of perspectives is the central tension.

Green screens are not just about technology; they embody the working habits, shortcuts, and muscle memory of entire professions. Whoever aims to modernize applications with Green Screens need to keep this in mind. And they should not just throw the latest technology at the problem, with the hubris of thinking this will be better independently of how it is used.

Why Are Green Screens Still Used?

Green screens persist not out of nostalgia, but because they are the visible part of an ecosystem that is uniquely robust, deeply customized, and incredibly difficult to untangle.

• Rock-Solid Stability. The green screens themselves are just the visible tip of an incredibly stable iceberg. They run on the IBM i platform, where the OS and the DB2 database are fused together, providing exceptional reliability that is critical for core business functions like finance and manufacturing. These are systems where unplanned downtime is measured across decades.
• Decades of Business Logic. The logic that drives these screens is not just old code; it’s a precise map of your business operations. Over the years, companies have embedded their competitive advantages—their unique workflows and domain knowledge—directly into the RPG programs that power these interfaces. To replace the screen is to risk losing this irreplaceable, battle-tested business intelligence.
• The Prohibitive Cost of Replacement. Modernizing a green screen isn’t just a UI update; it means replacing the entire, deeply integrated system behind it. A manual rewrite is often economically unviable, with costs sometimes estimated at over $32 per line of code. Switching to a standard ERP package often fails because no off-the-shelf software can replicate the custom logic built over decades.

The Challenges They Now Create

While Green Screens and the IBM i are stable, they are also a cage. The world has changed around these applications, and they now create significant barriers to growth and modernization.

• An Unforgiving Experience for Newcomers. What is lightning-fast for a veteran is a cryptic, hostile wall for a new employee. The lack of a graphical interface, the reliance on function keys, and the unforgiving text-based navigation create a steep learning curve. This makes it difficult to train new staff and alienates external partners who expect modern, intuitive web portals.
• Islands of Integration. Green screen applications were designed as self-contained worlds. The underlying RPG technology was intended for a world where integration was the key to success. They just do not fit in a connected ecosystem of web services and APIs. As a result, integrating them with modern tools is notoriously difficult; you will hardly find an official RPG library for a service like Stripe. This forces companies to build complex and fragile bridges using other technologies, turning their core systems into isolated islands.
• A Dwindling Pool of Experts. The most urgent risk is that the specialized developers who build and maintain these RPG-powered screens are retiring. The average age of an RPG developer is over 50, and very few younger programmers are learning the language. This “scarcity of RPG skills” creates a profound business risk: soon, there may be no one left who can fix a bug or add a feature to these critical systems.

What Are the Options?

Once we understand the challenges, we can map out a path forward. The good news is that the complex decision of what to do with green screens can be simplified by answering a single, crucial question.

The Deciding Question: Internal Expert or External Customer?

The entire UI migration strategy hinges on one simple question:

Who uses this system?. The answer almost always splits the application into two distinct worlds: the world of the internal power user and the world of the external customer or partner. The right migration strategy flows directly from this distinction.

Path A: The Complete Redesign (For External Users)

If any part of your UI is customer-facing, the choice is already made for you: the green screens must be replaced with a modern UI built from the ground up.

In today’s market, your user experience is a direct competitive advantage, and asking partners or clients to use a terminal emulator can put you at a severe disadvantage. In this scenario, the frontend is a separate development project, reimagining the user journey with modern frameworks like React or Vue. The migrated backend business logic is then exposed through a clean set of APIs (like REST) that the new frontend consumes. This results in a modern, decoupled architecture.

Path B: The Faithful Reproduction (For Internal Users)

For internal tools, the story is completely different. Here, the green screen is often a beloved and highly efficient tool. Forcing a data entry clerk who processes hundreds of invoices a day to switch to a mouse-driven web interface can be a disaster for productivity and morale.

In these cases, the first path to consider is an automated, faithful reproduction of the green screens as a web application. This is a technical translation, not a redesign. The process involves parsing the original Display File source (DDS), which defines everything from screen size to the exact row and column of every field. Then process the information and use it to generate something equivalent, expressed with a modern web framework. The result is a web page that looks and behaves almost identically to the original but runs in any browser, requiring no terminal emulator and minimal user retraining.

Path C: The Hybrid Migration (The Pragmatic Approach)

For some organizations, the wisest path is a hybrid of the two. It’s a pragmatic, phased approach that minimizes risk while laying the foundation for future improvements.

• Phase 1: Automate and Migrate. We begin by performing a faithful reproduction of all internal green screens, as described in Path B. This gets the organization to a functionally equivalent, fully migrated web application quickly, allowing you to decommission old dependencies.
• Phase 2: Evolve and Enhance. Now that the UI is built on a modern web stack, we can begin to improve it iteratively. This could mean replacing F-key buttons with a proper navigation menu or introducing modern data tables with built-in sorting and filtering.

This approach allows you to deliver value continuously without the “big bang” risk of a full redesign.

Key Challenges

Migrating a green screen UI involves more than just a visual update; it requires solving deep architectural challenges. Moving from a tightly coupled, server-driven terminal model to the modern web means rethinking how logic and state are managed.

Untangling Embedded UI Logic

One of the thorniest problems in any RPG migration is that business logic and UI logic are often deeply entangled. An RPG program doesn’t just calculate a value; in the very next line, it might set a boolean flag, known as an indicator, to make a field on the screen blink or change color.

For example, a line in an RPG program might set *IN25 = *ON, which is then linked to a DSPATR(HI) (highlight) attribute in the corresponding DDS file. The core challenge is that this indicator has an ambiguous meaning. Does it represent a core business state (e.g., “This order requires manager approval”) or is it purely a presentation instruction (“Make this field bright”)?.

A modern application requires a clean separation of concerns. The ideal migration untangles this by:

• Preserving the business rule on the backend. The migrated code should return a clear status in its API response, like {“orderStatus”: “needsApproval”}.
• Moving presentation logic to the frontend. The web component receives this status and decides how to render it, perhaps by applying a CSS class to highlight the field.

This separation is crucial for long-term maintainability, as it allows frontend and backend developers to work independently.

The State Management Shift

Perhaps the biggest architectural change is handling state.

Green screen applications are inherently stateful. The RPG program on the IBM i server knows exactly what screen the user is looking at, what data is displayed, and even the cursor’s position.

In stark contrast, modern web applications are fundamentally stateless. Each API request from the browser to the server is treated as an independent event; the server doesn’t “remember” what the user was doing before.

Bridging this gap is a major challenge. The best long-term strategy is to refactor the backend to expose truly stateless APIs. The responsibility for managing the UI state—what screen is active, what data is loaded, which form fields have been modified—moves from the server to the client’s browser. This is the standard model for modern Single-Page Applications (SPAs) and is what frameworks like React and Vue are designed for.

How to Decide: A Practical Framework

Modernizing green screens is not a purely technical exercise—it is a matter of aligning technology with business reality. Therefore, the question is not which technology stack is better but which trade-off your organization can live with. A good decision framework looks at three dimensions:

• who the users are
• what the system means for the business
• and how much risk you can afford

1. Start from the User

Forget technology for a moment. Look at who actually uses the system:

• If they are customers or partners, the interface is part of your competitive positioning. You cannot afford to look outdated—redesign is mandatory.
• If they are internal experts, speed and familiarity outweigh aesthetics. Here, faithful reproduction is often the only way to preserve productivity.

This distinction is not negotiable. Getting it wrong alienates either your market or your staff.

2. Recognize the Business Weight

Not all screens are equal. Some handle peripheral tasks, others are the backbone of revenue or compliance.

• Mission-critical screens should move cautiously, with minimal disruption.
• Non-critical ones offer a safer ground to test redesigns or hybrid approaches.

Think in terms of what the business can stop for a week without damage versus what cannot be down for an hour. That will tell you where to experiment and where to be conservative.

3. Be Honest About Risk

Every organization has a different appetite for risk. A wholesale rewrite is the riskiest option and fails more often than it succeeds. Incremental modernization—first reproduce, then evolve—spreads the risk across smaller, reversible steps.

If your company cannot afford a failed project (most cannot), avoid “big bang” rewrites. If you are okay with updating the technology and getting the corresponding gains in maintainability but accepting a more outdated appearance, then go with the faithful reproduction. Otherwise, if you want a more up-to-date presentation layer, then a hybrid strategy offers a safer path: quick wins first, deeper redesign later.

Conclusion

The journey away from green screens is not a simple technical swap; it’s a strategic business decision with no single “right” answer. Success comes from thoughtfully balancing the competing pressures of operational risk, modernization cost, and your long-term vision. As we’ve seen, the path you choose should be dictated by the needs of your users and the goals of your business.

Experience shows that “big bang” rewrites almost always fail and when they don’t, they are still very expensive. So we believe you have two options you should consider:

• If you do not care how your application looks like, you want just to improve maintainability then go with the Faithful Reproduction
• Otherwise go for the Hybrid Migration. Handled thoughtfully, this transition doesn’t just put a prettier face on an old system; it transforms a legacy liability into a valuable and future-proof asset.

Summary

Green screens remain critical in many IBM i environments, but their modernization is essential for future growth. The right path depends on the user: a complete redesign for external customers, a faithful reproduction for internal experts, or a phased hybrid approach. This choice must be balanced against business needs, team skills, and risk, with most organizations finding an incremental modernization path to be the most effective strategy.