The safest path from RPG to microservices is incremental, not a rip-and-replace project. Start with dependency mapping to see what actually touches what, wrap stable RPG logic in APIs without changing the underlying code, and run one bounded pilot before committing further. A full rewrite carries real risk and is rarely the right first move.
TL;DR:
- Most IBM i shops should focus on wrapping existing RPG logic in APIs rather than rewriting code, reducing risk and preserving proven business functions.
- Exposing RPG programs as web services can be achieved using Node.js, XMLSERVICE, or SQL wrappers on the same IBM i server, avoiding additional infrastructure complexity.
- Begin modernization with dependency mapping and a bounded pilot, gradually expanding to more workflows while ensuring proper testing, security, and clear ownership.
- Full rewrites are justified only if the data model no longer aligns with business needs or the module is completely unmaintainable, not due to aging code.
- Conduct an IBM i modernization assessment first to create a dependency map and prioritized plan, avoiding assumptions and guesswork common in typical projects.
Table of Contents
- What Does RPG to Microservices Actually Mean?
- How Do You Technically Expose RPG as a Microservice?
- How Do You Build a Realistic Modernization Roadmap?
- What Security Controls Does an IBM i Microservice Need?
- When Is a Full Rewrite Actually the Right Call?
- How Golden Path Digital Approaches RPG Modernization
- What I’d Tell an IT Manager Starting This Now
- Get an IBM i Modernization Assessment Before You Commit to a Pilot
- Sources
- FAQ
What Does RPG to Microservices Actually Mean?
For most IBM i shops, “RPG to microservices” doesn’t mean tearing out RPG and replacing it with something else. It means exposing what already works as callable services, so new applications, mobile clients, and integration partners can consume that logic without knowing (or caring) that it’s running on IBM i. Your general ledger posting routine, your inventory allocation logic, your order validation rules: these have been battle-tested for decades. The goal is to make them reachable over HTTP, not to rebuild them from scratch.
That distinction matters because it changes the entire risk calculus. Instead of a multi-year rewrite with an uncertain payoff, you’re layering a service interface on top of proven business logic. The IBM i Application Modernisation Roadmap frames API wrapping as the most practical entry point precisely because it requires no changes to the RPG itself, just a thin service layer that calls existing programs and returns JSON.
Which modernization pattern fits your situation
Different modules deserve different treatment. Here’s how to think through the choice:
- UI modernization or screen transformation. If your 5250 green screens are functionally fine but painful to look at, wrap them in a modern web or mobile front end without touching the RPG business logic underneath. This is the lowest-risk, fastest win available, and it buys goodwill from users who’ve been staring at function keys for twenty years.
- API wrapping. This is usually the first real modernization step. A service layer calls your existing RPG programs through XMLSERVICE or itoolkit and hands back JSON. No RPG code changes, no data migration, no downtime risk.
- Service enablement on IBM i (IWS/CGI). For teams already invested in IBM’s own web services stack, Integrated Web Services or CGI-based endpoints can expose specific programs directly, which sometimes fits better than building a separate adapter layer.
- Selective rewrite. Reserve this for modules that are genuinely unmaintainable, like RPG II code nobody understands, tangled GOTO logic, or programs with no separation between UI and business rules.
- Full rewrite. Justified only when the underlying data model no longer matches the business, or when a module can’t be maintained by anyone, anywhere, at any price.
Pick based on risk tolerance and how much of the module you actually need to touch, not on what’s trendy.
How Do You Technically Expose RPG as a Microservice?
The engineering here is more approachable than most teams expect, largely because Node.js in PASE has been available to IBM i 7.3 and later for years, and it doesn’t require additional IBM licensing. You can run an Express-style adapter directly on the same box that hosts your RPG programs, which eliminates an entire category of network latency and infrastructure-management headaches that a separate Linux host would introduce.
The core connection patterns are well established:
- itoolkit or XMLSERVICE call RPG service programs directly from Node.js, Python, or Java, passing parameters and receiving structured responses.
- ODBC or idb-connector give you SQL access to DB2 for i from any modern language, useful when the “service” is really a data query rather than a business rule.
- Stored-procedure wrappers let you encapsulate RPG logic behind a callable SQL interface, which many teams find easier to secure and version than raw program calls.
- An API gateway in front of everything handles authentication, rate-limiting, and monitoring so your adapters stay focused on business logic instead of reinventing security controls. This is where gateway architecture does its real work, standardizing behavior across every service you expose.
On deployment, you have a real choice: run adapters in PASE on the IBM i itself, or host them on a separate server and call back into the IBM i over the network. On-system PASE deployment is usually simpler to operate and secure, since you’re not managing a second server, patching a second OS, or troubleshooting network hops between two boxes.
Pro Tip: When calling RPG programs through stored procedures, map errors explicitly. It’s easy to let a business-rule exception get swallowed into a generic “500 error” during translation, which makes debugging production issues far harder than it needs to be.
How Do You Build a Realistic Modernization Roadmap?
Every successful RPG to microservices project starts the same way: someone maps what’s actually there before anyone writes a line of new code. Skipping this step is the single most common reason modernization projects blow their budgets, because teams discover dependencies mid-project instead of before it.
- Run dependency and codebase analysis first. A tool like AS/Forward-style parsing shows you which programs, copy members, and files are genuinely connected, so you scope the pilot to a slice that’s actually isolated rather than one that looks isolated on paper.
- Select a bounded workflow for your Strangler Fig pilot. Pick something valuable enough to matter but contained enough to fail safely, order status lookups rather than the entire order-to-cash cycle. Workflow capture techniques that trace how users actually move through screens can surface natural service boundaries that pure code analysis sometimes misses.
- Define test and cutover criteria before you build anything. Contract tests confirm the new service returns what callers expect; reconciliation jobs compare legacy and new outputs side by side until you trust the match.
- Iterate with an operations checklist. Once the pilot proves stable, expand to the next bounded workflow, applying the same mapping, boundary, and reconciliation discipline each time.
This is the strangler fig pattern in practice: new services gradually take over traffic while the old RPG system keeps running underneath, on a schedule instead of on a prayer.
What Security Controls Does an IBM i Microservice Need?
Exposing RPG logic to the outside world means the outside world can now reach data it never touched before. That’s not a reason to avoid modernization, but it is a reason to harden the path deliberately.
- Use SQL views instead of raw table access. Views let you filter columns, mask sensitive fields, and control exactly what a service can see, which reduces the attack surface compared to granting broad table permissions.
- Create dedicated service profiles with least privilege. Never route API traffic through a profile that also has interactive signon rights or broad object authority.
- Terminate TLS at the gateway, and use OAuth2, JWT, or mutual TLS for service-to-service calls so credentials aren’t passed around in the clear.
- Enable audit logging and forward it to your SIEM. Rotate service credentials on a defined schedule rather than leaving them static indefinitely.
Statistic Callout: Nick Litten’s security guidance on exposing RPGLE as web services notes that a dedicated service account with view-based access is a baseline operational practice, not an optional hardening step, for any RPG program reachable from outside the IBM i.
Testing needs the same rigor. Contract tests validate that a service’s interface matches what consumers expect. Replay-based behavior validation runs historical transactions through both old and new paths to catch divergence. End-to-end reconciliation closes the loop before you shift real traffic.
When Is a Full Rewrite Actually the Right Call?
Full rewrites get proposed more often than they’re warranted. The honest answer is that they’re justified only when the existing data model no longer fits the business or when a module genuinely cannot be maintained by anyone at any cost, not because the code looks old.
- Watch for measurable triggers: a module blocking new product lines, a data structure that can’t represent current business rules, or a vendor dependency that’s disappearing.
- Don’t bolt on external stacks your team can’t operate long term just because a vendor sold you on them.
- Protect IBM i domain knowledge deliberately. The people who understand forty years of business rules are retiring, and that expertise needs a staged handover, not a scramble.
- Validate any rewrite timeline with a small pilot first. If the pilot takes three times longer than estimated, the full project will too.
Pro Tip: If a vendor’s first recommendation is a full rewrite before they’ve mapped your dependencies, that’s a signal to get a second opinion.
How Golden Path Digital Approaches RPG Modernization
Golden Path Digital’s methodology follows the sequence this article recommends: map dependencies first, then enable APIs, then refactor selectively, only reaching for automation where it genuinely reduces manual work.
- AS/Forward parses IBM i RPG codebases to surface dependencies, dead code, and copy member relationships before anyone changes a line of production code.
- Laravel Ascend automates framework upgrades from version 6 through 11 for teams running modern web front ends alongside their IBM i core.
- QuantaPath AI handles CRM and workflow automation once your services are exposed, extending the value of the modernization work you’ve already done.
Teams starting this process typically request a modernization assessment before committing to a pilot scope.
What I’d Tell an IT Manager Starting This Now
Start with mapping and one high-value pilot, not five parallel projects. Get stakeholders aligned on data ownership and cutover criteria before you write a single adapter, because unclear ownership is what turns a six-week pilot into a six-month standoff. And document the RPG domain knowledge your senior developers carry in their heads. That knowledge doesn’t transfer through code comments.
— Ty
Get an IBM i Modernization Assessment Before You Commit to a Pilot
Golden Path Digital gives you a dependency map before anyone touches production code, which is the opposite of how most modernization vendors start. Where a typical consulting engagement leads with architecture diagrams and a rewrite proposal, Golden Path Digital’s IBM i Modernization Assessment begins by parsing your actual RPG codebase with AS/Forward to show which programs, files, and copy members are truly connected.
The deliverable is concrete: a dependency map, a prioritized list of candidate pilot workflows, and a scoped recommendation for whether API wrapping, selective refactor, or a targeted rewrite fits each module. For teams comparing routes into legacy code modernization, this assessment removes the guesswork that usually gets baked into fixed-bid rewrite proposals. Request an assessment and you’ll walk away with a scoped, defensible plan instead of a slide deck full of assumptions.
Sources
- Building REST APIs on IBM i: Node.js in PASE, IAS REST, and connecting modern front ends to your RPG business logic
- Exposing RPGLE as Webservices – Security Considerations – Nick Litten
- IBM i Modernization: Legacy Apps Without a Rewrite
FAQ
Is Microservice Architecture Dying?
No. Adoption keeps growing across enterprise software, though many teams are getting more selective about scope, favoring a handful of well-bounded services over dozens of tiny ones.
What Is Replacing Microservices?
Nothing is broadly replacing microservices. Some teams are shifting toward modular monoliths or “macroservices” for lower-traffic domains, while keeping true microservices for high-scale, independently deployed functions.
Are Companies Moving Away From Microservices?
Some teams that over-split their architecture are consolidating services to cut operational overhead, but this is a maturity correction, not a retreat from the pattern itself.
Is Apache Kafka a Microservice?
No. Kafka is a distributed event-streaming platform that microservices use to communicate asynchronously, not a microservice on its own.
Do I Need to Change My RPG Code to Expose It as an API?
No. API wrapping calls existing RPG programs through a thin service layer using itoolkit or XMLSERVICE, so the underlying RPG code stays untouched while new consumers reach it over HTTP.