RPG to Python: the route we have already built, and a client who has walked it.
You adopted RPG on your IBM i decades ago and it still runs the business. It just does not let you change the business any more. Python is the target when the destination is data work, an ERP on a modern stack, or a team that already writes Python — and it is the one target for which we publish a packaged migration path.
Read by an engine built for RPG IV and DDS. Translated at the pattern level, not statement by statement. Verified against the behavior of the system you already have.
- Only three people in the company can read the code
- Hiring means finding someone who learned RPG in the 1980s
- Every integration needs a bespoke bridge
- The application is tied to one vendor’s hardware
- Nobody can say what the system actually does any more
None of this is fixed by rewriting by hand. It is fixed by getting the logic onto a language people still learn.
A client who has already done it
David Nieper is a British designer and manufacturer of luxury women’s clothing, founded in 1961 in Derbyshire and employing over 250 people. Their software originated in the 1970s on an IBM AS/400. By 2025 they had concluded that while the RPG was still critical to operations, it had to be modernized so it could be connected to the rest of the business — and they had chosen Python as the target. What they did not have was a way to begin.
We started with a Migration Blueprint: five workshops and a handful of additional meetings. We analyzed the code, categorized the different ways GOTO statements were being used, and worked through the related technologies around the RPG — DDS, CL, Interform, the DB2 database and the integration with PHP middleware. The deliverable was a migration plan the company can follow: which code is worth migrating, which is dead and can be discarded, in what order the modules move, and how business continuity is preserved while they move.
“It was very carefully organized from the outset. We learnt a lot. The Strumenta team took the time to share knowledge and explain areas we didn’t understand. The information was shared in an easy to understand way. If you need to migrate your RPG code to Python, give Federico a call.”
“The detailed Blueprint Migration report covered the aspects, the process and exactly what needed to be done. The detailed report helped to give us a good understanding of the overall work involved and what was required in the project.”
Read the full case study: David Nieper — RPG to Python (PDF). More projects are collected on the case studies page.
Where RPG and Python disagree about money
This is the single most common way an RPG-to-Python migration produces a system that looks right and is wrong. RPG rounds one way; Python, out of the box, rounds the other. The two agree on almost every value and diverge exactly at the midpoints — which is where invoice totals, VAT and interest live.
Source — RPG
* GROSS holds 2.345 exactly: packed decimal
* stores digits, not binary fractions.
D GROSS S 5 3 INZ(2.345)
D NET S 5 2
C EVAL(H) NET = GROSS
* NET is 2.35. The (H) extender applies
* half-adjust: round half away from zero.
* Without (H), RPG truncates to 2.34.Target — Python
from decimal import Decimal, ROUND_HALF_UP
gross = Decimal("2.345")
cents = Decimal("0.01")
# Python's default is half-to-even
print(gross.quantize(cents))
# -> 2.34 WRONG against the RPG
print(gross.quantize(cents, ROUND_HALF_UP))
# -> 2.35 matches EVAL(H)The point is not that Python cannot do decimal arithmetic — it does it well. The point is that the correct behavior has to be chosen deliberately, per field, from the declared precision and scale of the original RPG definition, and generated consistently across the whole codebase. That is work a transpiler does from the parsed field declarations. It is not work a search-and-replace, or a developer reading a screen of code, does reliably a hundred thousand times.
A migration that is right on ninety-nine per cent of the arithmetic has not been done. It has been started.
What we read before anything is translated
Every RPG project of ours begins with the same parser: the RPG & DDS Language Engine. It reads RPG IV in both fixed-column and free format, embedded SQL in SQLRPGLE through a dedicated DB2 parser, and DDS sources, and it resolves references across the whole codebase so a field in a calculation spec links back to the record format that declares it. Parsing is error-tolerant: awkward code returns a partial tree plus positioned issues rather than stopping the run.
RPG III members are adapted line by line into the equivalent RPG IV fixed layout and then run through the same pipeline, so a mixed estate produces one AST and needs one set of migration rules rather than two. RPG II is the exception: tell us at the first meeting rather than at the quote. Full technical detail and licensing are on the RPG & DDS Language Engine page.
Why Python rather than Java
Python is the right target when the migrated system is going to keep changing, when the people who will own it afterwards already write Python, or when the destination is an ERP on a modern stack. Odoo, in particular, is a good fit for the kind of ERP that was traditionally built in RPG, which is why several RPG-to-Python projects end there rather than in a bespoke application.
Java is the better answer when the system has to outlast the team that builds it and when types must be checked before the code runs — the normal situation in banking and insurance. That route is on the RPG to Java page, and it goes through Migration CodeCraft rather than through the packaged path below.
Two ways to start
Ready-to-go RPG to Python
The packaged route: fixed sequence of five steps, our existing engine and transpiler, for estates that follow the patterns we already handle.
Migration Blueprint
The first step either way, and the one David Nieper bought on its own. Fixed scope, fixed price, and the report is yours whatever you decide next.
RPG modernization, all targets
The practice as a whole, including C#, Synon / CA 2E estates and the analysis work that does not end in a migration at all.
The only company automating RPG to Python
Strumenta is the only software language engineering company automating migrations from RPG to Python. The rest of this page is what stands behind that: a named client with a named target, quoted in their own words, a packaged offer with a published sequence of steps, and a parser whose coverage and limits are written down.
Straight answers
How good is the generated Python?
We customize the transpiler for each codebase and translate at the pattern level rather than statement by statement, so the output follows the idioms your code actually uses instead of reading like a machine transcription of RPG. The standard we work to is that your own developers accept it as code they could have written, because they are the ones who will maintain it.
How do we know the new system behaves like the old one?
Not by inspection. The Migration Blueprint includes a testing strategy, and during the migration we help you define the end-to-end approach and provide the templates, so you can verify the migrated system in your own infrastructure without depending on us to tell you it works.
Do we have to commit to the whole migration up front?
No. The Migration Blueprint is a step on its own with its own fixed scope and price, and its report is yours whatever you decide next. If the honest answer is that the migration is not worth doing yet, the report says so.
Does our source code have to leave our network?
The engine does not need it to: it runs wherever a JVM 11 or later runs, including inside your own network, with no connection to the IBM i. For us to plan and build a migration we do need representative sources, under whatever agreement you require.
Start where David Nieper started.
Tell us how much RPGLE there is, which flavours, how much of it anybody still understands. If the ready-to-go path fits your codebase we will say so; if it does not, we will tell you that instead of selling it to you.
