James Allman — JA Technology Solutions LLC
RPG Modernization: Options Beyond Java Migration
The migration question is more nuanced than vendors suggest. Here are the real options, tradeoffs, and a practical framework for deciding.
If you run an IBM i environment with significant RPG business logic, you have almost certainly been pitched the idea of migrating everything to Java. Maybe a consulting firm presented a roadmap. Maybe a vendor showed you a tool that promises automated code conversion. Maybe a new CIO arrived with a mandate to eliminate legacy technology. The pitch is always the same: RPG is old, Java is modern, and migration is the path forward.
The reality is more complicated than that. Migration to Java is one option among several, and depending on your situation, it may not be the best one. I have spent over 35 years working across IBM i, Java, and modern platforms, and the pattern I see most often is organizations making modernization decisions based on assumptions about what they should do rather than a clear-eyed assessment of what they actually need.
This article lays out the real options for RPG modernization — not to argue against migration, but to make sure you are evaluating all the paths before committing to one.
The Problem with "Migrate Everything to Java"
The migrate-everything narrative starts with a reasonable premise: RPG developers are getting harder to find, and Java has a larger talent pool. From there, it leaps to a conclusion that does not always follow: therefore, you should rewrite your RPG applications in Java. This logic skips over the most important questions. How much business logic lives in that RPG code? How well is it documented? What is the actual risk of a rewrite? And what specific problem are you trying to solve?
Automated RPG-to-Java conversion tools have been marketed for over two decades. The promise is appealing — feed in RPG source, get Java out the other side. In practice, these tools produce Java code that looks like RPG written in Java syntax. The resulting code is difficult for Java developers to understand, hard to maintain, and loses the performance characteristics that RPG has on the IBM i platform. You end up with code that is foreign to both RPG developers and Java developers.
Full rewrites carry their own risks. The business logic embedded in production RPG programs has been tested by years of real-world use. Every edge case that was discovered and handled, every business rule adjustment, every integration workaround — all of it has to be reproduced in the new code. Studies of large-scale rewrite projects consistently show cost overruns, timeline extensions, and subtle business logic differences that take months to surface after deployment. This is not an argument against ever migrating. It is an argument for understanding what you are actually committing to before you start.
I covered the depth of business logic that lives in RPG code in an earlier article, RPG: The Language Behind Your Business Logic. If you have not read it, the short version is this: your RPG programs encode decades of institutional knowledge that no requirements document fully captures.
Start with the Real Question: What Are You Trying to Achieve?
Before evaluating modernization options, you need to be honest about the problem you are solving. The answer shapes everything that follows. Organizations pursuing RPG modernization are typically motivated by one or more of these concerns: talent availability, integration with modern systems, user experience expectations, cost reduction, or compliance and auditability requirements.
If the core concern is talent, the question is whether the solution requires eliminating RPG or making RPG more accessible. If the concern is integration, the question is whether existing RPG programs need to be replaced or simply exposed through modern interfaces. If the concern is user experience, the problem is almost always the presentation layer, not the business logic underneath it. If the concern is cost, you need an honest comparison of total cost of ownership — including the cost and risk of migration itself.
These distinctions matter because different motivations lead to different solutions. An organization that needs modern web and mobile interfaces does not necessarily need to rewrite its business logic. An organization concerned about finding RPG talent may get more value from converting fixed-format code to free-format RPGLE than from a multi-year Java migration. Getting the diagnosis right saves enormous amounts of time, money, and risk.
I have seen organizations spend years and millions of dollars on migration projects that could have been addressed with a targeted API layer and a modern front end. I have also seen organizations delay a necessary migration until the cost of inaction exceeded the cost of the move. The right answer depends on the specifics of your situation, not on a general philosophy about old versus new technology.
Modernize in Place: Free-Format RPGLE, SQL, and Web Services
The lowest-risk and often highest-value modernization step is to modernize the RPG code itself. Modern free-format RPGLE is a structured, readable language that any competent programmer can learn. Converting fixed-format RPG to free-format preserves the tested business logic exactly while making the code accessible to a broader pool of developers. The programs run the same, produce the same results, and interact with the same data — they are just written in a form that does not require specialized knowledge of column positions and indicator-based logic.
Alongside code modernization, replacing legacy data access patterns with embedded SQL improves both readability and performance. Older RPG programs often use native I/O operations that are tied to specific file access paths. Rewriting these to use SQL allows the DB2 for i query optimizer to choose the most efficient access strategy, and makes the data access logic comprehensible to anyone who knows SQL — which is a much larger talent pool than those who understand RPG native I/O. Tools like the DDS to SQL Converter can help bridge that transition by converting physical and logical file definitions to their SQL equivalents.
IBM i also supports ILE (Integrated Language Environment) service programs, which allow RPG business logic to be organized into modular, reusable components with well-defined interfaces. This is the IBM i equivalent of building a library or API — the business logic is encapsulated in service programs that can be called from RPG, COBOL, C, Java, or any ILE-compatible language. If your RPG code is currently a collection of monolithic programs, refactoring into service programs is a modernization step that pays dividends regardless of what you do next.
These in-place modernization steps are not glamorous. They do not produce a flashy demo for a steering committee. But they reduce risk, improve maintainability, and create a foundation that makes every other modernization option easier and less expensive to pursue later.
API-First: Wrapping RPG Business Logic in REST Services
One of the most effective modernization patterns is to leave the business logic in RPG and expose it through REST or SOAP web service interfaces. The RPG programs continue to run on IBM i, with all the performance and reliability advantages that entails. But instead of being accessible only through green-screen programs or batch processes, the logic is callable from any system that can make an HTTP request — web applications, mobile apps, integration platforms, trading partners, and internal systems on any platform.
IBM i provides several mechanisms for building web services. The Integrated Web Services Server (IWS) allows you to expose ILE programs and service programs as REST or SOAP endpoints with minimal code changes. Scott Klement's open-source HTTP server tools provide additional flexibility. And frameworks built on top of IBM i's PASE environment, including Node.js-based API layers, offer modern REST framework capabilities directly on the IBM i system.
The API-first approach addresses several modernization concerns simultaneously. Talent becomes less of a constraint because the consumers of the API do not need to know RPG — they interact with standard HTTP endpoints that return JSON or XML. Integration with modern systems becomes straightforward because REST APIs are the universal language of system integration. And the user experience can be modernized completely by building modern front-end applications that call the API, without touching the business logic.
The key architectural decision is how granular to make the API. Wrapping an entire RPG program as a single endpoint is fast but inflexible. Decomposing the logic into finer-grained services takes more effort but produces an API that is more reusable, testable, and maintainable. I generally recommend starting with the integration points that have the most immediate business value — the handful of transactions or queries that external systems or a new front end need access to — and expanding from there.
Hybrid Architectures: Modern Front Ends, IBM i Back Ends
For many organizations, the real frustration with their IBM i environment is not the business logic — it is the user interface. Green-screen 5250 applications were designed for character-based terminals. They are functional, often faster for experienced users than graphical alternatives, but they do not meet modern expectations for usability, accessibility, or mobile access. They are also a barrier to hiring, because new employees expect graphical interfaces.
A hybrid architecture separates the presentation layer from the business logic. The front end is built with modern web technologies — React, Angular, Vue, or whatever framework your team prefers — and communicates with the IBM i back end through APIs. The RPG business logic stays where it is, doing what it does well. The user experience becomes modern, responsive, and accessible from any device with a browser.
This pattern is well-proven. I have worked alongside organizations that run React-based web applications backed entirely by RPG business logic on IBM i. The users interact with a modern interface. The business logic runs on a platform optimized for exactly that workload. The data stays in DB2 for i, which means reporting, batch processing, and other back-end operations continue to work exactly as they did before. For a broader view of how IBM i fits into modern technology decisions, see IBM i: The Platform Decision-Makers Should Understand.
The hybrid approach also creates a natural migration path if you decide later that moving business logic off IBM i is the right call. Once the front end is decoupled from the back end, you can replace back-end services one at a time, at whatever pace makes sense, without disrupting the user experience. You are not locked into IBM i forever, but you are also not forced into a risky big-bang migration.
When Migration Genuinely Makes Sense
There are real situations where migrating off RPG and IBM i is the right decision. If your IBM i workload is small enough that the platform licensing costs are disproportionate to the value it provides, migration makes financial sense. If your organization has made a strategic commitment to a different platform and has the budget, timeline, and risk tolerance for a full migration, that can be a valid business decision. If the business logic is simple enough that a rewrite is feasible without significant risk of logic loss, migration may be straightforward.
Migration also makes sense when the RPG applications are genuinely end-of-life — when the business processes they support are being replaced entirely, not just re-platformed. Replacing a legacy order entry system as part of adopting a new enterprise resource planning platform is a different proposition than rewriting the same order entry logic in Java on a different server.
What does not make sense is migrating because of a general belief that legacy technology is bad and modern technology is good. Every platform has strengths and weaknesses. IBM i's strengths — reliability, integrated security, backward compatibility, performance for transactional workloads — are real and not easily replicated on commodity hardware. If you are migrating to a platform that does not match those characteristics, you need to account for the operational differences in your planning, staffing, and budget.
The risks of migration are well-documented: business logic gaps that surface only in production, data migration errors, performance differences, integration disruptions, and the sheer organizational effort of running parallel systems during a transition. None of these are insurmountable, but all of them need to be planned for and budgeted. A migration estimate that does not include a substantial contingency for discovered complexity is not a realistic estimate.
Node.js, Python, and Other Languages on IBM i
IBM i's PASE (Portable Application Solutions Environment) provides a full AIX-compatible runtime that supports Node.js, Python, PHP, Ruby, and other open-source languages directly on the IBM i platform. This means you can build new functionality in modern languages without leaving the system, and those programs have direct access to DB2 for i data, IFS files, and IBM i system services.
Node.js on IBM i is particularly interesting for web service development. Its asynchronous, event-driven architecture handles concurrent HTTP requests efficiently, and the npm ecosystem provides packages for virtually any integration need. Python is valuable for data analysis, automation, and machine learning workloads. Both languages have large talent pools and active communities.
The practical advantage of running these languages on IBM i rather than on a separate server is proximity to data. There is no network latency between the application and the database. There is no data replication or synchronization layer to maintain. Security and authorization use the same IBM i profiles and object authorities. And the operational infrastructure — backups, monitoring, job management — is already in place.
This option is sometimes overlooked because it does not fit neatly into either the "keep RPG" or "migrate away" categories. But for organizations that want to build new capabilities in languages their development team already knows, while maintaining the operational advantages of the IBM i platform, PASE-based development is a practical middle path. New services are written in Node.js or Python. Existing RPG logic continues to run. Both access the same data.
The Talent Question
The talent question is real but often framed too narrowly. Yes, the pool of experienced RPG developers is shrinking as longtime professionals retire. But the conclusion that the only solution is to eliminate RPG does not follow from the premise.
Modern free-format RPGLE is learnable by any developer with experience in procedural or structured programming. The syntax is different from Java or Python, but the concepts — variables, control structures, procedures, database operations — are the same. An experienced developer who learns RPGLE can be productive within weeks, not years. The barrier is not the language itself. It is the business domain knowledge that takes time to acquire, and that barrier exists regardless of what language the code is written in.
Organizations that invest in making their RPG code modern and readable, documenting their business logic, and exposing functionality through standard APIs create an environment where the specific language becomes less important. A developer who understands the API contract and the business rules does not need to be an RPG expert to work with the system. The RPG expertise is still needed, but it can be concentrated in a smaller group that maintains the core business logic while a broader team works on integration, front-end development, and new features.
The other dimension of the talent question is whether your organization will have better luck finding and retaining Java developers, Node.js developers, or Python developers than RPG developers. In competitive hiring markets, that is not a given. The advantage of a hybrid approach is that it lets you use whichever talent you can find for whichever part of the system is best suited to their skills.
Building a Practical Modernization Roadmap
A useful modernization roadmap starts with an inventory of what you have and an honest assessment of where the risk and value are. Which RPG programs are business-critical? Which ones are well-understood, and which ones are black boxes? Where are the integration pain points? What are the actual business outcomes you need — not what technology you think you should be using, but what the business needs to accomplish?
From that assessment, practical roadmaps tend to follow a pattern. First, stabilize and document. Convert fixed-format RPG to free-format where it reduces risk. Document the critical business logic, data flows, and integration dependencies. Make sure more than one person can support the critical systems. This step has immediate value regardless of what comes next.
Second, expose. Build API interfaces around the highest-value RPG business logic. Start with the integration points that are causing the most pain — the manual file transfers, the batch processes that should be real-time, the data that external systems need but cannot access. Each API endpoint you create reduces coupling and increases flexibility.
Third, extend. Build new capabilities in whatever language makes sense — Node.js, Python, Java, or modern RPGLE — depending on the nature of the work and the skills available. New web interfaces, new integrations, new reporting, new automation. These build on the APIs and data access you established in the previous step.
Fourth, evaluate selectively. With the foundation in place, you can make informed decisions about whether specific RPG programs should be rewritten, replaced, or left as they are. Some will be better off staying in RPG. Some may be candidates for rewriting in a different language. Some may be replaced entirely by a different approach. But you are making those decisions with real data about cost, risk, and value — not based on a blanket philosophy about technology age.
What This Looks Like in Practice
I have worked with IBM i environments at every point on this spectrum. Organizations running 30-year-old fixed-format RPG with no documentation and a single developer who knows how it works. Organizations with well-maintained modern RPGLE codebases and clean API layers. Organizations midway through migration projects that stalled because the cost and complexity exceeded estimates. And organizations that made deliberate, well-planned decisions to modernize incrementally and are better off for it.
The organizations that do well share a few characteristics. They start with a clear understanding of what they have and what they need. They resist the temptation to solve a talent problem by creating a migration problem. They invest in the foundation — code readability, documentation, API exposure — before making big platform decisions. And they treat modernization as a continuous process, not a one-time project.
The organizations that struggle tend to approach modernization as an all-or-nothing proposition. Either we keep everything in RPG on IBM i exactly as it is, or we migrate everything to a new platform. The most practical path is almost always somewhere in the middle — preserving what works, improving what does not, and building bridges to new capabilities incrementally.
Getting Started
If your organization is facing these decisions, the first step is an honest assessment of where you stand. Not a vendor pitch. Not a technology recommendation based on market trends. An assessment grounded in your specific environment, your business requirements, your risk tolerance, and your budget.
With over 35 years of experience across IBM i, Java, modern web technologies, and enterprise integration, I bring a perspective that is not tied to any single platform or vendor. I have no product to sell and no predetermined answer. My interest is in helping you find the most practical path forward for your specific situation — whether that means modernizing in place, building hybrid architectures, planning a targeted migration, or some combination of all three.
If you want to have that conversation, reach out. I am glad to start with a straightforward discussion about what you have, what you need, and what your realistic options are. You can also learn more about my IBM i consulting practice and the range of modernization services I provide.