How to Modernize IBM i Without Rewriting Applications
How can you modernize IBM i without a full application rewrite?
Most IBM i estates can be modernized incrementally: modernizing the user interface, exposing existing RPG or COBOL programs as callable APIs, and modernizing database access, while the core business logic keeps running as it always has. A full rewrite is rarely necessary and carries significant risk; it's typically justified only when the application's data model itself — not just its interface or integration layer — no longer fits the business.
At a glance
Key takeaways
The interface is usually the biggest complaint, not the logic
Green-screen frustration is often a UI problem, solvable without touching the underlying RPG/COBOL business logic.
APIs unlock integration without a rewrite
Wrapping existing programs as callable services lets you connect IBM i to modern applications without re-implementing business rules.
Modernization should be phased, not big-bang
Incremental modernization reduces risk and lets you validate value before committing to the next phase.
A full rewrite is the exception, not the default
Rewrites are justified by specific, identifiable constraints — not simply because the platform is old.
UI Modernization
Two common paths exist for modernizing the user experience without touching business logic: screen-modernization tools that wrap existing 5250 screens in a web or graphical interface, and more structured approaches that build new web or mobile front ends calling existing program logic directly.
For many organizations, the sentiment that “IBM i needs to be replaced” is really a reaction to an outdated green-screen interface — a problem that is addressable without any change to the underlying RPG or COBOL programs that actually run the business.
API-Enabling RPG and COBOL Programs
Existing RPG and COBOL programs can be exposed as callable APIs — commonly REST/JSON services — either by using integration and API management tooling to wrap existing program calls, or by restructuring programs into callable modules or service programs that both the green-screen interface and a new API layer can share.
The benefit is significant: existing, tested, business-critical logic — often representing decades of accumulated business rules — is reused rather than re-implemented and re-tested from scratch, which is one of the largest risk factors in a full rewrite.
Database Access Modernization
DB2 for i, the relational database built into IBM i, supports modernized access patterns alongside its traditional native record-level access. Moving reporting and integration tools to SQL-based access, enabling ODBC/JDBC connections, and using views, stored procedures, and triggers can expose data far more flexibly without changing how the core application writes data.
This is frequently the unlock that lets a modern reporting or analytics tool connect directly to production data, without requiring any change to the RPG or COBOL programs that maintain that data.
Selective Refactor vs. Full Rewrite
Selective refactor means rewriting or restructuring specific modules or programs that are genuinely problematic — a poorly performing batch job, or an unmaintainable custom module — rather than replacing the entire application. A full rewrite means replacing the application in its entirety.
Most IBM i applications contain a mix of well-functioning core logic and a smaller set of genuinely problematic areas. Selective refactor targets only the latter, which is almost always lower risk and lower cost than a full rewrite.
The Risk of Rip and Replace
Full “rip and replace” modernization projects carry outsized risk because they require re-implementing and re-testing years or decades of accumulated business rules, including edge cases that may not be documented anywhere except in the existing code. These projects also typically take longer and cost more than initially scoped, and they create a period of parallel-running risk during cutover.
Large legacy rewrite and ERP replacement projects have a well-established industry pattern of significant delay and cost overrun. That pattern is a reason to plan modernization incrementally and validate value along the way, rather than committing to an all-or-nothing rewrite up front.
Building a Phased Modernization Roadmap
A practical sequence starts with the highest-visible-impact, lowest-risk change — usually UI modernization — then API-enables the integration points that unlock the most valuable new capabilities, such as mobile access or integration with a new CRM or e-commerce platform. From there, database access modernization can support reporting and analytics needs, and only after that should specific modules be evaluated for selective refactor.
Validate value at each phase before committing to the next. This keeps risk contained and gives the organization real evidence — not a plan on paper — that modernization investment is paying off.
When a Full Rewrite Is Actually Justified
A handful of specific, rare triggers genuinely justify a full rewrite: the underlying business has changed so fundamentally that the application’s data model itself no longer fits, not just its interface; the organization has lost all practical ability to maintain or extend the RPG/COBOL codebase, including through partners, with no feasible path to acquire that capability; or a strategic decision to consolidate onto a single enterprise platform — for example, replacing a custom system with a packaged ERP — for reasons unrelated to the technology itself.
“The platform is old” is, by itself, not one of these triggers. IBM i and its underlying RPG and COBOL programs can run modern, well-integrated systems for a long time when modernized incrementally.
Modernization Approach: Risk and Best Fit
Use this table to match a modernization approach to the problem you’re actually trying to solve.
| Option | Risk profile | When it fits best |
|---|---|---|
| UI modernization | Low — business logic untouched | When user experience or green-screen perception is the primary complaint |
| API-enabling RPG/COBOL programs | Low to Medium — requires careful interface design, not a logic rewrite | When new integrations (mobile, e-commerce, CRM) need to call existing logic |
| Database access modernization | Low to Medium | When reporting, analytics, or external tool integration is constrained by legacy access patterns |
| Selective refactor | Medium — scoped to specific problem modules | When specific programs are genuinely unmaintainable or underperforming |
| Full rewrite | High — full re-implementation and re-testing of business logic | Rarely; when the data model itself, not the interface, no longer fits the business |
Implementation Steps
- 1
Identify the real complaint
Determine whether the driver is user experience, integration limits, data access, or genuine application problems.
- 2
Start with UI modernization
Modernize the interface first for a visible, lower-risk win.
- 3
API-enable key integration points
Wrap the specific programs that unblock your highest-value new use cases.
- 4
Modernize database access where needed
Enable SQL/ODBC/JDBC access to support reporting and analytics needs.
- 5
Refactor selectively
Target only the specific modules that are genuinely problematic, rather than the whole application.
- 6
Reassess before considering a rewrite
Only evaluate a full rewrite if a specific, well-defined trigger applies after incremental modernization.
Risks and Common Mistakes
Use caution
Treating age as the problem
An old platform is not automatically a broken one — conflating platform age with an actual business constraint leads to unnecessary rewrite risk.
Use caution
Underestimating undocumented business rules
Decades of accumulated logic in RPG/COBOL programs often include edge cases that exist nowhere except in the code itself — a rewrite risks losing them silently.
Use caution
Big-bang modernization with no phased validation
Attempting UI, API, database, and logic changes all at once removes the ability to validate value and catch problems early.
Frequently Asked Questions
Can I modernize IBM i without touching RPG or COBOL code?
Often, yes for the interface layer — UI modernization tools can wrap existing 5250 screens without changing the underlying programs. API-enabling and database access modernization may require some restructuring, but typically reuse existing logic rather than replacing it.
What does API-enabling an RPG program actually involve?
It generally means wrapping or restructuring a program so it can be called as a service, for example over REST/JSON, by external applications, while the core business logic continues to run as it always has.
Is a full rewrite ever the right choice?
Occasionally, but it should be justified by a specific trigger — such as the application's data model no longer matching the business, or a genuine, unrecoverable loss of ability to maintain the code — rather than the platform simply being older technology.
How long does incremental modernization take compared to a rewrite?
It varies by scope, but incremental modernization is typically phased over months per phase with value delivered along the way, versus a full rewrite, which is typically a much longer, higher-risk, all-or-nothing project. Treat any specific timeline as illustrative until it's scoped against your environment.
Where should I start if I don't know what to modernize first?
Start by identifying whether the primary complaint is about user experience, integration limits, data access, or the application logic itself — that determines which modernization pattern to apply first.
Sources
- IBM i modernization and application development documentation
- Vendor UI modernization and API-enablement tooling guides
- Industry legacy modernization risk research
Ready to Build a Modernization Roadmap?
Get a directional assessment of where incremental modernization would deliver the most value in your IBM i environment.