Migrating RPG Code to Modern Languages
A practical playbook for teams modernizing IBM i applications, by Federico Tomassetti and Gabriele Tomassetti.
RPG has run core business applications for decades, and on IBM i it still does. What has changed is everything around it: the number of people who write RPG, the systems the business now needs to connect to, and how long a change takes when only two people can make it.
This is the book we wanted to hand to clients at the start of a project. It covers the decisions before the code—why migrate at all, what actually happens during a migration, which target language to pick—and then the specific technical problems that make an RPG migration different from any other: indicators, GOTO, data structures and overlays, green screens, CL programs and the database underneath all of it.
It is written for the people who have to do it and the people who have to approve it, which is why roughly half of it is about planning, testing and the ways migrations go wrong, and only the middle third is about translating code.
What is in it
Making sense of legacy migrations
- 01Why migrate? The reasons that hold up under scrutiny, and the ones that do not.
- 02What happens during a migration — the shape of the work, end to end.
Planning the migration
- 03The different kinds of migrations, and which one your situation calls for.
- 04Choosing the target language and framework: Java, Python or C#.
- 05Planning the migration: scope, sequence and the decisions that have to be made early.
Key technical challenges
- 06Translating RPG code, including indicators and GOTO.
- 07Translating data structures and overlays.
- 08Green screens and the user interface.
- 09The database.
- 10Translating CL code.
Ensuring success
- 11Testing the migration and verifying equivalence with the original.
- 12The Strumenta Migration Pipeline, the infrastructure we use to deliver migrations.
- 13Migration pitfalls and best practices.
Who it is for
- Teams who have decided to move and now have to plan it. Parts two and four are the ones you will use first.
- Developers who will do the translating. Part three is the technical core: the RPG constructs that have no direct equivalent, and what to do about each.
- Anyone who has to approve the budget. Chapter 1 and chapter 13 are the honest version of the business case, including when not to migrate.
If you want to know how we think about migrations before you talk to us, this is the longest and most candid version of the answer.
Where to get it
Paperback and Kindle
On Amazon, in the marketplaces below. The paperback and the Kindle edition are separate listings.
Beyond the book
The book describes the method. If you want it applied to your own estate, that is what the practice does.
Migration Blueprint
We parse your real codebase and map modules, dependencies, dead code and the risky corners, then set out a strategy with a realistic scope.
RPG & IBM i modernization
RPG to Java, RPG to Python, Synon / CA 2E, and the RPG Language Engine underneath all of it.
Ready-to-go RPG to Python
A packaged migration path for teams whose target is Python.
Read chapter 13 before you commit to anything.
It is the list of ways these projects go wrong. If your plan already avoids all of them, you probably do not need us. If it does not, tell us what you are running and we will say what we would do.
