RPG (RPG/400, RPG IV, ILE RPG, Free-Form RPG)
The historical and modern language of the AS/400. We translate RPG programs to Java 21 or 25 (LTS) or to .NET 10 pattern by pattern, capturing business rules and running upstream characterization tests.
AS/400 / IBM i modernization
An AS/400 running since 1995 can become a cloud-native Java application.
Access International modernizes AS/400 and IBM i estates (IBM-supported 7.5 and 7.6, as well as earlier releases) to cloud-native architectures. RPG, COBOL/400, CL programs, 5250 screens, DB2 for i databases — each component is ported with proven functional parity. ATLAS methodology, Tunis nearshore delivery, France presence (Vivantro), co-delivery with our Canadian partners.
Key figures
IBM i 7.6
current release, generally available since April 18, 2025
IBM
5 phases
ATLAS, from scoping to go-live
By batches
incremental delivery, duration set at scoping
ATLAS methodology applied
From scoping to deployment, five structured phases.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact.
- 01Phase 1
Scoping
ATLAS stepsE1 Intake · E2 Discovery · E2b Functional specificationUnderstand the existing RPG, COBOL/400, CL estate. Rebuild a usable functional analysis. Define scope, constraints, and success criteria.
Phase deliverableEstate inventory + functional specification + pricing - 02Phase 2
Capture & dependencies
ATLAS stepsE2e Existing-system capture · E3 Dependency mappingSet the ground truth: 5250 screens, reports, datasets, recorded transactions. Map subsystems, queues, DB2/400 databases, integrations exhaustively.
Phase deliverableReference transaction bench + complete mapping - 03Phase 3
Target architecture
ATLAS stepsE4 Target architecture · E4b Pre-migration testsChoose the target (Java + Spring Boot, .NET, TypeScript), design RPG migration patterns, SFL subfiles, data queues. Prepare the characterization test suite before any porting.
Phase deliverableSigned target architecture + characterization test suite - 04Phase 4
Migration & parity
ATLAS stepsE5 Migration · E6 Parity validationTranslate 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.
Phase deliverableTarget code + parity audit per subsystem - 05Phase 5
Deployment & handover
ATLAS stepsE7 DeliveryProgressive go-live, IBM i ↔ target coexistence for a duration set at scoping, batched transactional cutover, signed discrepancy registry, ops handover to the client team.
Phase deliverableApplication in production + autonomous client team
Covered scope
The full IBM i ecosystem, from RPG to batch jobs.
COBOL/400 and OPM/ILE
COBOL programs hosted on IBM i, CL integrations, ILE modules. Migration to Java or .NET with preserved transactional semantics.
DDS, DB2 for i, SQL
DDS tables and DB2 for i SQL schemas. Migration to PostgreSQL, SQL Server, or Azure SQL with data and constraint parity audits.
CL (Control Language)
CL scripts for job orchestration, queue management, scheduling. Conversion to Bash, PowerShell, or cloud orchestrators (Azure Logic Apps, AWS Step Functions).
5250 programs and emulation
5250 screens modernized into React or Angular web interfaces. Screen logic preserved, progressive ergonomic redesign.
Subsystems, batch jobs, IFS
Full IBM i estate inventory: subsystems, nightly batch jobs, IFS, native storage. Mapping before migration, batch cutover plan.
Target technologies
Java, .NET, TypeScript, Azure: the target follows your ecosystem.
The target choice depends on the client ecosystem: Java 21 or 25 (LTS, with Spring Boot) for existing Java actors, .NET 10 for Microsoft ecosystems, TypeScript + Node.js for full-web architectures. Hosting on Azure, AWS, GCP, or on-premise based on sovereignty constraints.
Cell composition
An AS/400 migration mobilizes a specialized team.
Six distinct profiles; duration and headcount set at scoping, after the POC. Reproducing this team internally is rarely realistic — the RPG skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Duration
Set at scoping, after the POC
Volume
Headcount set at scoping, after the POC
Profiles
AS/400 ↔ Cloud architect
Bridge between both worlds, target design, technical governance
Target language Tech Lead
Java 21/25, .NET 10 or TypeScript depending on the architecture choice
Developers
Ideally with an RPG or COBOL background for pattern-by-pattern translation
DBA DB2/400 → PostgreSQL
Schema migration, triggers, materialized views, data parity audit
Cloud network engineer
IBM i / target cloud coexistence, security, integrations
QA & functional parity
Test bench, legacy/target comparison, ATLAS audit validation
Frequently asked questions
AS/400 modernization — what CIOs ask.
Which IBM i (AS/400) versions do you handle?+
IBM-supported releases: 7.5 and 7.6 (available since April 2025). We also migrate 7.3 (out of standard support since September 2023) and 7.4 (since September 2026), and older releases (V5R4, V6R1, V7R1), for which we plan an intermediate upgrade step or a source-code export for off-platform analysis.
How long does a typical AS/400 modernization take?+
Duration and headcount are set at scoping, after the POC: they depend on the number of RPG programs, the complexity of the 5250 screens and the criticality of the processing. The migration runs in coexistence mode (legacy + target in parallel, progressive cutover). The ATLAS methodology breaks the migration into transactional batches, each delivered with its parity audit.
Do we have to rewrite or can we emulate?+
Three approaches depending on context: (1) Pattern-by-pattern rewrite to Java/.NET — recommended to address long-term debt. (2) Cloud emulation or rehosting — fast cutover but preserves the debt. (3) Functional redesign — when the business wants to leverage the migration to rethink processes. ATLAS combines all three by module.
How is functional parity guaranteed after migration?+
Exhaustive pre-migration state capture: characterization tests (ATLAS step E4b), production transaction recording bench, data snapshots. After porting: parallel runs (legacy + target) on the same transaction corpus, field-by-field result comparison. Signed parity audit before cutover.
Does the Access team know IBM i specifics?+
Yes. Our teams pair experienced RPG and IBM i developers with architects of the target platforms, across the whole ecosystem: RPG ILE, free-form, embedded SQL, IFS, journaling, subsystems. On the tooling side: IBM Bob, IBM's development assistant for IBM i (available since 2026, successor to watsonx Code Assistant for i), which we follow closely.
How does coexistence work during the transition?+
Strangler fig pattern: the target system coexists with the AS/400 for a duration set at scoping. Transactions are routed to either based on migration state. Bidirectional synchronization of critical data. Transactional batch cutover with automatic fallback on discrepancy.
Where are your delivery centers?+
Main nearshore center in Tunis (UTC+1, European timezone). Presence in France via our subsidiary Vivantro for client relationships and local expertise. Co-delivery with Canadian partners for North American programs. This structure covers all data localization constraints (Quebec Law 25, EU GDPR).
Case studies
Related case studies
Public sector — North America
IT modernization and digital transformation for a North American public sector organization
View case study →
Multi-sector
Legacy migration POC (COBOL, Delphi, BizTalk, mainframe)
View case study →
Access capability — internal POC
CapabilityDelphi → TypeScript capability validated on internal POC
View case study →
Evaluating an AS/400 migration?
We start with an estate audit (4 to 6 weeks): RPG program inventory, dependency mapping, complexity analysis, target recommendation. The report is directly usable by the client, whether or not Access is chosen for the migration itself.