Layered roadmap guide
IBM i Modernization Options: Browser Access, Templates, APIs, and Rewrites
A credible roadmap distinguishes immediate delivery friction from presentation, integration, maintainability, and replacement goals. This guide helps teams avoid applying a deep and risky technique to a shallow problem, or a cosmetic technique to structural work.
The short answer
Choose the modernization layer that matches the business goal. Browser terminal access changes delivery. Screen templates change presentation. APIs change integration. RPG Open Access changes the display path. Refactoring or rewriting changes application structure. Replacing the application changes the product and operating model.
Using a deeper technique than the goal requires can increase cost and risk. Using a shallow technique for a structural problem can postpone necessary work. Many IBM i roadmaps combine several approaches.
Compare the main approaches
| Approach | Best suited to | What remains | Main tradeoff |
|---|---|---|---|
| Browser 5250 access | Remove workstation installation or establish managed web entry | 5250 application and presentation | Does not by itself redesign workflows |
| Branding and terminal themes | Establish product identity and visual consistency | Host screens and behavior | Primarily cosmetic outside the application shell |
| Exact-screen templates | Improve selected stable workflows | Live 5250 session, host validation, and Db2 state | Depends on reviewed screen fingerprints and field geometry |
| Screen refacing | Rapidly apply GUI conventions across many screens | Usually the 5250 stream and host programs | Generated presentation still depends on host-screen behavior |
| APIs and services | Integrate IBM i logic or data with new channels | Selected programs and data | Requires interface design, authority, monitoring, and lifecycle ownership |
| RPG Open Access | Replace the 5250 display path while retaining RPG program logic | RPG logic and IBM i runtime | Deeper development and conversion effort |
| Refactor or source transformation | Improve maintainability, language, tests, or architecture | Business behavior selected for preservation | Requires strong regression evidence and skilled delivery |
| Replace the application | Change the operating model or retire unsuitable software | Data and selected processes after migration | Highest organizational and migration impact |
Start with the business constraint
Access and deployment friction
If users cannot reliably install or reach a desktop client, begin with browser delivery and network architecture. Do not call this a full application modernization project when the application itself remains unchanged.
Training and workflow friction
If a small number of dense screens slow occasional users, selective templates may create value quickly. Experienced operators may prefer Classic terminal efficiency, so measure by role rather than assuming every green screen is a problem.
Integration friction
If the business needs partner, mobile, automation, or event-driven channels that should not reproduce terminal interaction, design explicit APIs or services. A screen template is not an integration contract.
Maintainability and staffing risk
If the core problem is tightly coupled code, missing tests, obsolete language practices, or declining expertise, presentation work will not resolve it. Invest in code understanding, automated characterization, modular boundaries, and a longer-term application roadmap.
A layered roadmap
A practical sequence can be:
- Stabilize identity, transport, observability, and current application behavior.
- Provide managed browser access for a bounded user group.
- Improve one high-value screen workflow and retain Classic fallback.
- Expose explicit APIs for new channels rather than automating terminal screens.
- Refactor or replace modules when a measured business case supports deeper change.
This is not a universal order. It illustrates how immediate access needs and long-term architecture can progress without pretending they are the same project.
Evaluate vendors fairly
Ask every vendor to demonstrate the real workflow, unsupported behaviors, deployment topology, credential model, revocation behavior, accessibility, fallback, source-code requirements, scaling assumptions, and exit path. Free trials and automated conversions are useful evidence, but they do not replace operational testing.
PristineScreen400 belongs in the access and selective-presentation layers. It should be compared with deeper modernization tools only when the distinction is explicit.