AS/400 ↔ Cloud architect
1Bridge between both worlds, target design, technical governance
Loading...
Loading...
Migration of AS/400 applications (IBM i, RPG, DB2/400) to Java, .NET Core, or TypeScript. ATLAS methodology, business knowledge preservation, progressive cutover.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Understand the existing RPG, COBOL/400, CL estate. Rebuild a usable functional analysis. Define scope, constraints, and success criteria.
Set the ground truth: 5250 screens, reports, datasets, recorded transactions. Map subsystems, queues, DB2/400 databases, integrations exhaustively.
Choose the target (Java + Spring Boot, .NET Core, TypeScript), design RPG migration patterns, SFL subfiles, data queues. Prepare the characterization test suite before any porting.
Translate pattern by pattern with line-by-line traceability. Incremental migration by subsystem (strangler fig). Signed parity audit between legacy and target on every delivered batch.
Progressive go-live, IBM i ↔ target coexistence for 6 to 24 months, batched transactional cutover, signed discrepancy registry, ops handover to the client team.
AS/400 — renamed IBM i since 2008 — remains remarkably present in SMEs and mid-caps in distribution, manufacturing, logistics, food industry, retail sectors. Many of these companies acquired their AS/400 in the 1990s to 2005s and still operate it today. The platform stands out for its exceptional operational stability (availability above 99.99% without intervention), its integrated model (OS, integrated DB2/400 database, native security), and its longevity (code written in 1995 still runs today without recompilation).
Three forces push for IBM i modernization: growing shortage of RPG developers (IBM indicates fewer than 100 new developers trained per year worldwide), significant IBM Power license costs at hardware renewal, and integration limitations with modern REST, GraphQL, event APIs. IT departments hesitate because AS/400 works perfectly, but the demographic cliff of RPG skills makes the decision inevitable in 5-10 years. Our ATLAS methodology is suited to this long trajectory.
An AS/400 estate typically combines three languages: RPG (the most common, from RPG II to modern RPG Free Form), COBOL (sometimes coexisting with RPG), CL (Control Language for system scripts). Each language has its own migration patterns. Classic RPG II / III is harder to migrate than RPG Free Form which is closer to a modern language. COBOL on AS/400 follows the COBOL to Java or .NET Core path. CL is generally rewritten directly in shell script or modern orchestrator (Airflow, Kubernetes CronJobs).
Java, .NET Core, TypeScript, PostgreSQL, conteneurs
Strategic AS/400 estate, need for transactional robustness, Java teams in-house or accessible via integrators. Default choice for SMEs and mid-caps wanting maintainable code long-term.
Microsoft ecosystem dominant in IT, integration with Dynamics 365 or Power Platform. See [COBOL to .NET Core](/parcours/cobol-to-dotnet-core) for arithmetic subtleties.
Moderate workloads, priority on velocity and cloud cost. Suited to management and e-commerce applications. See [COBOL to TypeScript](/parcours/cobol-to-typescript).
Urgency to exit physical hardware without immediate redesign. Lift-and-shift approach preserving RPG on IBM cloud. Useful as temporary stepping stone, not as final target.
An AS/400 modernization is typically structured over **eighteen to thirty-six months** depending on volume and criticality. The cell combines an **AS/400-cloud architect** capable of bridging both worlds, a **tech lead** on the target language (Java, .NET, TypeScript), three to six **developers** ideally with an RPG or COBOL background, a **DB2/400-PostgreSQL DBA** for data migration, a **cloud network engineer**, a QA. For an estate of **fifty to one hundred fifty thousand RPG lines**, plan **twelve to twenty months** with a cell of **eight to twelve people**.
Underestimating the specificity of RPG subfiles (SFL). 5250 subfiles are tabular display patterns with native pagination that have no direct equivalent in modern web.
Explicit porting of subfiles to web data tables (AG Grid, Material UI Table) with cursor-based pagination. Native AS/400 functions (READC, REFRESH, UPDATE) are reproduced as REST endpoints with client-side state management. UX parity tests on bulk entry/consultation workflows.
Ignoring data queues and data areas AS/400, inter-program communication mechanisms specific to IBM i.
Replacement with modern message queues (Azure Service Bus, RabbitMQ, Apache Kafka per context). Global data areas become entries in Redis or a key-value database. Unit tests on producer-consumer communication patterns to validate isofunctionality.
Forgetting DB2/400 specifics. DB2 for i differs from classic DB2 and PostgreSQL by its integrity rules, triggers, naming constraints (long names vs system tables 10 characters).
Exhaustive DB2/400 schema mapping from discovery phase. Migration to PostgreSQL with table name adaptation, triggers ported as PL/pgSQL functions, materialized views reproduced. Parity tests on representative datasets with automatic reconciliation.
Neglecting IBM i security mechanisms (user profiles, authorities, system groups). IBM i has very fine integrated security that target systems do not natively reproduce.
Target RBAC model designed from the architecture (Role-Based Access Control). AS/400 user profiles are mapped to a modern directory (Active Directory, Keycloak, Auth0) with granular roles and permissions. Non-regression tests on each user profile with representative access scenarios.
Wanting to migrate everything at once. An AS/400 estate accumulated over 15 to 25 years often contains forgotten programs, hidden dependencies, undocumented workflows.
Mandatory strangler fig strategy. We migrate subsystem by subsystem, the least critical transactions first. IBM i-cloud coexistence for 2 to 4 years. Progressive decommissioning of migrated programs. See the ATLAS methodology for the detailed protocol.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between both worlds, target design, technical governance
Java 21 / .NET Core 8 / TypeScript depending on the architecture choice
Ideally with an RPG or COBOL background for pattern-by-pattern translation
Schema migration, triggers, materialized views, data parity audit
IBM i / target cloud coexistence, security, integrations
Test bench, legacy/target comparison, ATLAS audit validation
AS/400 RPG patterns tested as part of our 10 global POCs. Modern RPG Free Form migrates with a ratio close to COBOL, around **8:1** to Java or TypeScript. Specifics (subfiles, data queues, DB2/400) are documented in our ATLAS catalog.
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.
Three concrete ways to start — from a free diagnosis to a full modernization cell. Our AS/400 / IBM i 7.5/7.6 approach is documented, priced, and applicable from the first meeting.