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 .NET Core 8 pattern by pattern, capturing business rules and running upstream characterization tests.
AS/400 / IBM i modernization
Their AS/400 had been running since 1995. Today it's a cloud-native Java application.
Access International modernizes AS/400 and IBM i estates (7.3 to 7.6) 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
< 100
new RPG developers trained per year worldwide
IBM
8:1
rewrite ratio from RPG Free Form to Java or TypeScript
18-36 months
typical duration for a 50-300k RPG-line AS/400 program
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 Core, 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 6 to 24 months, 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: three proven targets.
The target choice depends on the client ecosystem: Java 21 (Spring Boot) for existing Java actors, .NET Core 8 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, eight to twelve people, over eighteen to thirty-six months. Reproducing this team internally is rarely realistic — the RPG skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Duration
18 to 36 months depending on volume and criticality
Volume
8 to 12 people for 50-150k RPG lines
Profiles
AS/400 ↔ Cloud architect
1Bridge between both worlds, target design, technical governance
Target language Tech Lead
1Java 21 / .NET Core 8 / TypeScript depending on the architecture choice
Developers
3-6Ideally with an RPG or COBOL background for pattern-by-pattern translation
DBA DB2/400 → PostgreSQL
1Schema migration, triggers, materialized views, data parity audit
Cloud network engineer
1IBM i / target cloud coexistence, security, integrations
QA & functional parity
1-2Test 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?+
All modern versions: IBM i 7.3, 7.4, 7.5, and 7.6 (released 2025). For older versions (V5R4, V6R1, V7R1) we plan an intermediate upgrade step or a source-code export for off-platform analysis.
How long does a typical AS/400 modernization take?+
For an estate of 200 to 500 RPG programs: 9 to 18 months in coexistence mode (legacy + target in parallel, progressive cutover). For 1000+ programs: 18 to 36 months. 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 (LzLabs, Heirloom Computing) — 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 E5), 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 consultants cover the IBM i ecosystem for twenty years: RPG ILE, free-form, embedded SQL, IFS, journaling, subsystems. The new Watson Code Assistant for i (IBM 2024) is integrated into our production chains. Several IBM i Developer-certified profiles.
How does coexistence work during the transition?+
Strangler fig pattern: the target system coexists with the AS/400 for 6 to 24 months. 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 → .NET Core 8 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.