Modernize an AS/400 estate to cloud-native architectures.

Yes, IBM continues to invest in IBM i. The current version IBM i 7.5 was released in 2022 and a 7.6 version was announced. IBM guarantees support until 2030 minimum for recent versions. The decision to migrate therefore does not come from imminent IBM end-of-support, but from strategic considerations: RPG skills shortage, costs, modern web integration. It's a 5-10 year decision, not urgent.

Yes, this is IBM i web-facing. Tools like Profound UI, looksoftware, Aura, or Rational Open Access for RPG components allow dressing an existing RPG application with a web interface without rewriting the back-end. Pros: fast modernization, business code preservation, lower investment. Cons: vendor dependency, evolution limits, license costs. It's a transition solution, not a long-term strategy — to combine with a progressive back-end migration plan.

Modern RPG Free Form: ratio about 8:1 (8 RPG lines per 1 Java/TypeScript line), comparable to COBOL. Classic RPG II / III: tighter ratio 5:1, because old RPG is very verbose with its fixed specifications. CL translates with a variable ratio depending on target shell (bash, PowerShell, orchestrator). Target volumes are smaller than sources thanks to modern framework primitives.

5250 screens are replaced by a modern web interface (React, Angular, Vue). 5250 workflows oriented to function keys (F3 = exit, F12 = back) are translated to web workflows with explicit buttons and configurable web keyboard shortcuts. 5250 subfiles become paginated web tables. The user experience is rethought — users trained on 5250 need support during transition but generally find the web version more productive after 4 to 6 weeks of use.

For an estate of one hundred thousand RPG lines with about fifty 5250 screens in nearshore co-delivery, plan one to one million five hundred thousand euros including UX, development, tests, user training. For three hundred thousand lines, budget two to four million euros. Cost typically lower than mainframe migration thanks to more modest estate sizes. See the delivery models for contractual formats.

Yes, it's even a good fit. The BOT model consists of entrusting the modernization cell to Access for 2-4 years, then progressively transferring the team to your internal organization. Suited to mid-caps wanting to internalize their target skills while avoiding startup risk. See the development center for BOT contractual terms.

There is no IBM-imposed end of life for the AS/400 — IBM rebranded it to iSeries then IBM i and continues active investment. The current version IBM i 7.5 was released in 2022 with support guaranteed at least to 2030. The decision to modernize therefore does not come from imminent IBM end-of-support. The real drivers are: shrinking RPG developer talent, hardware cost (Power systems are not cheap), modern integration friction (cloud, mobile, AI all require workarounds), and business agility requirements that the green-screen experience cannot match. Modernization is a 5-10 year strategic decision, not an emergency. The ATLAS methodology handles AS/400 modernization to Java, .NET Core, or TypeScript with proven parity. See the AS/400 modernization journey.

It depends on your existing ecosystem and what you want to gain from the migration. Pick Java when your platform is already built around Spring, Kafka, Kubernetes, or open-source databases (PostgreSQL, MariaDB) — Java's library depth on financial transactions, AS/400-style record I/O, and its long-term language stability make it the safer default for large RPG estates. Pick .NET Core 8 when your organization runs on Microsoft (Azure, Dynamics 365, Power Platform) — interop with the rest of the stack saves real money, and modern C# is now on par with Java on every dimension that matters. But the choice of Java vs .NET is the second decision. The first is what experience you want on the other side: leave the green-screen behind, expose the system as APIs, prepare for AI-assisted evolution. A line-for-line port has the worst ROI of all options. The ATLAS methodology frames this with a internal classified discrepancy registry.