Green Screen Modernization: A Practical Roadmap for IBM i Teams
The real difference between screen scraping and full modernization, and how to sequence a green screen project so it produces a visible result instead of stalling out.
Web enablement and full modernization are not the same project
Green screen modernization vendors generally describe two distinct approaches. Web enablement, sometimes called screen scraping or refacing, gives a 5250 screen a modern browser-based look without changing the underlying program logic, and can act as a fast stopgap. Full modernization instead converts the DDS source behind the screen into rich display files, or uses RPG Open Access to remove the 5250 datastream dependency entirely, producing an interface that can genuinely run in a browser rather than a styled terminal emulation.
Buyers should be explicit about which outcome they actually need before evaluating tools, since a screen-scraped interface will still carry 5250 protocol limitations underneath, even though it looks modernized on the surface.
Sequence the technical work realistically
A common and workable sequence is to convert RPG to free-format first, then move database access to SQL, and only then decide whether to reface the 5250 screens for the web or pursue full DDS conversion. Doing the code and database groundwork before the interface work tends to produce a more stable foundation, since interface tools work better against clean, current RPG than against decades-old fixed-format code.
- Convert RPG to free format before investing heavily in interface tooling
- Move database access toward SQL where practical, ahead of UI work
- Decide explicitly between screen scraping and full DDS or RPG Open Access conversion
Start with one workflow that has a visible business result
The IBM i modernization projects that stall are almost always the ones that tried to redesign the entire interface at once. A phased approach, choosing a single high-friction workflow such as order entry or warehouse picking, delivering a working modern interface for it, and then expanding, gives the project a checkpoint where leadership and users can see real progress instead of waiting years for a big-bang release.
Match the tool to the skill and risk tolerance on the team
Several established vendors offer different paths into this work: DDS conversion and RPG Open Access tooling for full modernization, screen-reface tools for fast web-enabled results, and low-code visual designers for teams that want to build new screens without hand-coding a browser front end. The right choice depends less on which tool is most powerful and more on which approach the internal team can realistically maintain after the vendor's implementation engagement ends.