Your RPGLE codebase, converted to Python on a path we have already built.
A packaged migration for teams whose target is Python: the same RPG engine and transpiler we use every day, applied to your codebase, with a defined sequence of steps instead of a bespoke program designed from scratch.
Most migration projects begin by deciding everything at once: which target language, which architecture, which supplier, which order. If your destination is Python, most of those decisions are already made—and the route from RPGLE to Python is one we have walked before. This offer is that route, packaged: fixed steps, our existing tooling, and a conversion that starts from something that already exists rather than from a blank page.
We automatically convert your codebase written in RPGLE into a Python codebase. The translation is performed by our tooling, not by hand, so it is repeatable, reviewable and re-runnable while your RPG system keeps running in production.
Why teams move RPG to Python
Hiring
Recruiting an RPG developer is slow, expensive and getting harder: the people who know the language are retiring rather than arriving. There are vastly more Python engineers, and they are not a specialist market.
Where the code can run
Python runs on any infrastructure you choose, on premise or in any cloud, without specialized hardware underneath it. That makes capacity a commercial decision again instead of a hardware one.
Cost and dependency
RPGLE runs on hardware and skills that only a narrow market supplies. Moving the business logic to Python removes that dependency—both the machines and the people who are the only ones able to touch them.
What you get
- A Python codebase generated from your RPGLE, converted by our tooling rather than retyped by hand.
- Translation at the pattern level, not statement by statement. We customize the transpiler for each codebase, so the output follows the idioms your code actually uses instead of producing a literal transcription that nobody wants to maintain.
- Fewer human errors than a manual rewrite. A rule applied by a machine to a million lines behaves the same on line 1 and line 999,999.
- A testing strategy you can run yourselves. We help define the end-to-end testing approach and provide templates, so you can verify the migrated system in your own infrastructure, without depending on us to tell you it works.
- Access to the Python ecosystem. It keeps growing, and some Python frameworks—Odoo among them—are a good fit for the kind of ERP systems traditionally written in RPG.
Five steps, in this order.
For the modernization of AS/400 or iSeries software. Nothing is converted before the codebase has been read and the plan agreed—which is what keeps the conversion phase predictable.
Schedule a meeting
What are we dealing with?
A short questionnaire before we talk: how you use RPGLE, the size of the codebase, who its typical user is. It is what lets us advise you properly in the first conversation.
Discovery meeting
Is this the right route for you?
We get to know each other and go through your needs. You leave the meeting with our recommendation on the best way to move forward—including when it is not this one.
Migration Blueprint
What exactly is in the codebase?
An audit of the existing code and an analysis of the conversion problem, written up as a report: audit results, target architecture, risk analysis, mapping definition and testing strategy. Fixed scope, fixed price.
Language conversion
Does the generated Python hold up?
We execute the plan and convert the codebase, generating more of the target code with each iteration, translating at the pattern level. You pay on the basis of the results obtained and approved by you.
Testing and validation
Does the new system do what the old one did?
We support you in defining the end-to-end testing strategy and provide the templates, so you can verify and test the system autonomously, in your own infrastructure.
Ready-to-go, or Migration CodeCraft?
Both deliver a migrated system, and both begin with a Migration Blueprint. They differ in how much is decided in advance. Ready-to-go is the standard path, already built, for one source and one target. Migration CodeCraft is the general engagement, shaped around whatever you are running and whatever you want to run instead.
The path already exists
Your source is RPGLE, your target is Python, and your estate follows the patterns we already handle. You want to start from something proven rather than design an engagement.
The target language, the sequence of steps, the tooling and the conversion approach. Less to negotiate, and a faster start.
A Migration Blueprint, exactly as for CodeCraft. It is what tells you whether your estate really fits the standard path.
The path is designed with you
Your target is Java or C# rather than Python, your source is something other than RPG, or your architecture, integrations and delivery constraints need to be designed rather than assumed.
Target language and architecture, module boundaries and delivery order, with the code arriving module by module and full ownership of the result.
If you are not sure which of the two you are in, that is what the Blueprint is for: it reads the codebase and tells you. The Migration Blueprint is the same first step either way, and its findings are yours whichever route you take afterwards.
What already exists, so that nothing has to be built first
A packaged offer is only worth the name if the machinery it depends on is already finished. This one rests on the RPG & DDS Language Engine, which we sell in its own right and use every day. Strumenta is the only software language engineering company automating migrations from RPG to Python, and this offer is that capability packaged rather than a proposal to build one.
The RPG III support is worth stating as a mechanism rather than as a promise. RPG III members are adapted line by line into the equivalent RPG IV fixed-format layout and then run through the same pipeline, so an RPG III program and an RPG IV program produce identical syntax-tree node types. Everything downstream — the analysis, the transpiler, the generated Python — behaves the same on both, because it is not aware of the difference.
All of which is the practical difference from a bespoke engagement. On a custom project the first months go into reading a language; here they do not, and the first thing you get back is converted code rather than a research report. The engine has its own specification on the RPG & DDS Language Engine page, including what it does not cover.
What is good and what is bad in RPG development?
Our report on the state of RPG development: what teams running RPG say about their codebases, their tooling and their plans. Free, no form.
Straight answers
How good is the generated Python?
Good enough that your developers will accept it as their own, which is the only standard that matters. 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.
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 that too.
What if our target is Java or C# instead?
Then this is not the right offer. We migrate RPG to Java and C# as well, but through Migration CodeCraft, where the target architecture is designed with you rather than fixed in advance. RPG & IBM i modernization covers all three targets.
Where do I find more information?
When you book a meeting we point you at the material that fits your case: methodology, articles, webinars and tutorials. There is also the book, Migrating RPG Code to Modern Languages, which collects how to plan a migration, what to automate and where projects go wrong.
Can you help with anything beyond the conversion?
Usually, yes. Clients often buy a transpiler to use inside a larger system and integrate it themselves; just as often they ask us for training, help with the architectural design, or the implementation of the whole system. We are specialists in language engineering, and those supporting services exist so the migration actually lands.
Where can I find references from other clients?
Our clients page collects logos and testimonials, and case studies go into detail on individual projects. There are also interviews on the blog: with Rob Wunderlich and with Campbell Pryde.
Tell us what your RPGLE estate looks like.
How much code, which flavours, what it runs. An informal chat: we answer your questions about RPGLE to Python migration, explain the approach, and tell you honestly whether the ready-to-go path fits your codebase or whether you need the longer route.
