The Challenge
A mid-sized European manufacturing company had been running their core ERP system on IBM i for over 25 years. The system — built and maintained almost entirely in RPGLE — covered everything from production planning and inventory management to customer order processing and financial reporting.
The problem was not the software itself. It worked reliably. The problem was the people who understood it.
Over the preceding three years, four of the company’s six RPG developers had retired. The remaining two were planning to retire within 18 months. The IT Director estimated that 60% of the system’s business logic existed only in the code and in the heads of those six people — not in any documentation.
The company had tried twice to document and rewrite portions of the system. Both attempts had stalled: the rewrite was too slow, too expensive, and the output too unreliable.
Why They Chose Strumenta
The IT Director had read Federico Tomassetti’s book on RPG migration and reached out directly. The key differentiators that led to Strumenta being selected over two other vendors:
- A working tool, not a promise. Strumenta was able to demonstrate an actual RPG parser analysing a sample of the client’s code within the first meeting — not a slide deck about future capabilities.
- Fixed price. The other vendors quoted time-and-materials. Strumenta committed to a fixed price after a thorough Phase 1 analysis.
- No hand-off to junior staff. The same engineers who did the Phase 1 assessment would lead the migration.
Our Approach
We began with a three-week Phase 1 analysis. Our engineers received a sanitised copy of the codebase and performed a complete structural analysis: module inventory, dependency mapping, identification of complex patterns (embedded SQL, data areas, activation groups), and an assessment of documentation coverage.
The Phase 1 report identified 847 RPG source members, 23 embedded SQL programs, and 14 areas of particularly complex business logic that would require architectural discussion before migration. It included a proposed Java package structure, a migration timeline, and a fixed price.
The client accepted the proposal. We proceeded to Phase 2.
The automated transpiler processed the majority of the codebase — approximately 520,000 lines — in the first pass. Our engineers then spent six weeks reviewing and improving the output: renaming variables to idiomatic Java conventions, restructuring several modules that had grown organically over the years, and working with the client’s two remaining RPG developers to ensure the business logic in the 14 complex areas was correctly understood.
Throughout Phase 2, we held weekly video calls with the client’s IT Director and lead developer, sharing intermediate output and discussing any areas where architectural decisions were needed.
The Outcome
The migration completed on time and on budget. The final Java codebase was deployed to a test environment running on the client’s existing IBM i hardware, where it ran alongside the original RPG system.
The end-to-end test suite — 2,400 test cases covering all critical business scenarios — passed at 100% on the first full run.
Client Quote
“The migration completed on time, on budget, and our team was writing new features in Java within a month of handover. What impressed us most was that Strumenta’s engineers clearly understood RPG — they weren’t just translating syntax, they understood what the code was doing.”
— IT Director, European manufacturing company
Lessons Learned
A few things we would do again, and a few we’d adjust:
What worked well:
- The fixed-price model forced us to do a very thorough Phase 1. There were no surprises in Phase 2 because we’d already identified everything in Phase 1.
- Keeping the client’s two remaining RPG developers actively involved throughout Phase 2 was critical. Their domain knowledge caught several edge cases that weren’t obvious from the code alone.
- Running Java and RPG in parallel on IBM i during the validation phase eliminated all risk from the cutover.
What we’d refine:
- We underestimated the time needed to migrate the 23 embedded SQL programs. They required more architectural discussion than the RPG-only code. We’ve since refined our Phase 1 assessment process to flag this earlier.