Replace the 5250 green screens, keep the DB2 for i data — and the decades of business logic underneath.
The IBM i (AS/400, iSeries, System i) estates that still run procurement, manufacturing, distribution and banking on RPG, COBOL and 5250 — modernised onto a metadata-driven runtime. The platform speaks DB2 natively, so the database migration is a read-and-import, not an ETL programme. DDS screens become metadata. RPG business logic rewrites as server-side JavaScript on the supervised runtime. The 5250 sessions become a browser.
Native DB2 connectivity — migration is read-and-import
DB2 for i is in the platform's seven-engine OLTP matrix. The schema imports as-is into the metadata repository ; tables, journals, file definitions and constraints are read directly through the platform's DB2 driver, not through a third-party ETL layer. No staging area, no per-table extract job, no schema re-modelling.
DDS screens become metadata
Display files (DSPF), printer files (PRTF), report layouts (RLU) and the field-level definitions inside them reify into the metadata repository as window, form, grid and report rows. The runtime materialises the application surface from those rows on Vue 3.5 / Vuetify 4 — no per-screen code is written, no DDS source is hand-translated.
RPG business logic rewrites as JavaScript on the supervised runtime
The procedural business rules that accumulated in RPG and COBOL over decades are rewritten in server-side JavaScript on the platform's GraalVM Polyglot runtime — modern syntax, the largest talent pool in enterprise software, the platform's standard library wired in by default. Embedded SQL that is set-based ports to DB2 stored procedures and triggers instead, where transactions enforce it. The classification is part of the engagement, not the customer's problem.
The Power hardware can stay — or not
The modernisation does not force the IBM Power LPAR to retire. DB2 for i continues as the OLTP target if the operational depth justifies it ; alternatively the schema lifts to PostgreSQL on commodity hardware when the licensing or talent-availability picture calls for it. The decision is independent of the modernisation programme itself.
The five-layer methodology, applied to IBM i
From the data model outward. Each layer is independently deliverable. Cut-over is incremental.
1 · Schema
The DB2 for i catalog (SYSTABLES, SYSCOLUMNS, SYSKEYS) is read directly through the platform's DB2 driver and imported into the metadata repository's table-object catalogue. Physical files, logical files, journals, constraints, identity columns, RRN-keyed access paths — all reify as rows the platform can recompile, against DB2 for i if the LPAR stays, or against PostgreSQL if the estate re-platforms.
2 · Business logic — split between database tier and JavaScript
Native DB2 stored procedures and triggers stay where they are. Embedded SQL in RPG IV / RPG /FREE and in COBOL that is genuinely set-based — joins, aggregations, multi-row updates — moves to the database tier as SQL routines and triggers, where DB2 transactions enforce it. The procedural business rules — record-by-record processing, conditional flow, accumulator patterns, external-system orchestration — rewrite as server-side JavaScript on the platform's GraalVM Polyglot runtime, with the standard library wired in by default. The institutional knowledge encoded in decades of RPG survives the migration intact ; the destination is the one each rule belongs in.
3 · DDS screens and reports become metadata
Display files (DSPF) are reified as window-plus-form metadata ; subfile-driven screens (SFL, SFLCTL, SFLPAG) port to platform grid components ; printer files (PRTF) reify as report layouts. The function-key footer (F3 exit, F12 cancel, F4 prompt) translates to platform keyboard shortcuts and visible toolbar buttons. The 5250 operator's muscle memory survives in shape ; the rendering modernises.
4 · Batch and middle tier — CL ports to JavaScript
CL command programs, the WRKJOBSCDE-driven scheduled-job surface and SBMJOB-launched batch all port to the platform's job scheduler, with their CL bodies rewritten as server-side JavaScript on the supervised runtime. The FTP, SMTP and SMB integrations that IBM i estates typically hand-rolled in CL now call into the platform's standard library — more than forty namespaces covering database, HTTP, cryptography, cloud, AI, document generation, image processing, OCR and mail.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The 5250 panels become responsive browser screens. Role-aware rendering, mobile-friendly layouts and accessibility are properties of the runtime, not of the per-screen DDS source. Operators who knew the function-key footer keep that footer ; users who never saw a green screen see a modern web application.
What changes for the operator
IBM i estates are usually three estates layered on top of each other : a DB2 schema that has been refined for thirty years and is operationally pristine, a body of RPG and COBOL with embedded SQL that encodes the business rules, and a 5250 green-screen surface that the operators have learned by heart. The modernisation preserves the first, refactors the second and replaces the third — moving the rules into DB2 routines where transactions enforce them, and reducing the screen surface to metadata the platform can interpret.
The team that delivers this is a database engineer who can read DB2 for i catalog tables and SQL, an RPG-fluent analyst who can read display-file DDS and the embedded-SQL flow, and a business analyst who knows what the function keys actually do. The methodology is methodical extraction, not greenfield design — the AS/400 estate is exactly the kind of asset where a rewrite would lose institutional knowledge that no current employee could re-derive.
A typical AS/400 migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Approach | Re-write in Java EE, .NET or a visual-builder framework | ✓ Move logic to the data tier; generate the UI from metadata |
| Database | Re-modelled out of DB2 into a different engine and ETL'd | ✓ Imported through native DB2 connectivity ; stays on DB2 for i or lifts to PostgreSQL |
| RPG and embedded SQL | Translated by hand into the target language | ✓ Set-based SQL into DB2 routines ; procedural rules rewritten as server-side JavaScript |
| DDS display files | Re-built screen by screen as web forms | ✓ Reified as window / form / grid / report metadata |
| CL and batch surface | Re-implemented in the target scheduler | ✓ Ported to the platform's job scheduler ; integrations to the standard library |
| Customer-side team | Full-stack developers, RPG experts as advisors | ✓ Database engineer + RPG-fluent analyst + our team |
| Cut-over | Big-bang at the end of a multi-year programme | ✓ Incremental, module by module, parallel run on the same DB2 |
Why IBM i estates are worth migrating now
IBM i is operationally one of the strongest platforms ever built. Backup, journal-based recovery, single-level storage, integrated security, decades of forward-binary-compatibility — most of the operational reasons enterprises adopted the AS/400 in the 1990s still hold. The pressure to migrate is almost never about the OS itself ; it is about the operational reality around it. The RPG talent pool is shrinking. Mobile and partner-portal access against 5250 screens is essentially impossible. Modern AI agents cannot operate against a 5250 data stream. The integration surface to SaaS, REST APIs and cloud services is the kind of thing IBM i estates spend disproportionate effort to bolt on.
The platform-modernisation approach is to preserve everything operationally excellent about IBM i — the DB2 schema, the business logic encoded in DB2 routines, the data discipline — and replace only the surface that limits the operator : the 5250 client tier, the per-workstation terminal-emulator overhead, the lack of native integration surface. The result is a system that runs in a browser, integrates natively, hosts AI agents against the same data DB2 for i has always trusted, and can lift to PostgreSQL when the customer wants to retire the LPAR.
What IBM i shops ask before they engage.
Does the modernisation force us to leave DB2 for i and IBM Power?
No. DB2 for i is a first-class engine in the platform's seven-engine OLTP matrix. The schema imports through native DB2 connectivity — the platform speaks DB2 directly, with no ETL layer between — and the LPAR continues to do the work if the operational depth justifies it. Customers who want to retire the Power hardware as part of the same engagement lift the schema and the database business logic onto PostgreSQL on commodity hardware ; the same metadata recompiles against either target.
What happens to the RPG and COBOL business logic that has accumulated over decades?
It splits between two destinations — the database tier for the set-based work, server-side JavaScript on the supervised runtime for everything else. Embedded SQL that is genuinely set-based — joins, aggregations, multi-row updates, batch transformations — ports into DB2 stored procedures and triggers, where transactions enforce the rules and the platform's compiler reasons about them natively. The procedural business rules that surround the embedded SQL — record-by-record processing, conditional flow, accumulator patterns, external-system orchestration, the CL command logic that orchestrates RPG programs — rewrite as server-side JavaScript on the platform's GraalVM Polyglot runtime. JavaScript carries three concrete advantages over a Java rewrite : the database connection is wired in by default with the platform's row and column security automatic ; the talent pool is the largest in enterprise software ; GraalVM compiles to native at runtime so the performance gap against Java is small enough that language choice is decided by team economics rather than raw speed. The classification — which rule goes which way — is part of the engagement, not the customer's problem. The platform helps automate the classification where the RPG follows recognisable patterns.
How do DDS display files actually port — they are the heart of the application surface?
Display files (DSPF) carry four concerns inside one source : field definitions (the variables the screen reads and writes), screen layout (positions, attributes, colours), subfile mechanics (SFL, SFLCTL, SFLPAG, SFLSIZ for grid-style screens) and function-key behaviour (CFnn, CAnn). Each concern reifies into its own metadata family in the repository — field metadata, layout metadata, grid metadata, keyboard-shortcut metadata. The runtime materialises the equivalent web screen on Vue 3.5 / Vuetify 4 with the function-key footer translated to a visible toolbar that operators can either click or trigger with the same keys. The muscle memory survives.
What about CL command programs, the WRKJOBSCDE scheduler and SBMJOB-driven batch?
CL command programs port to the platform's job scheduler as named jobs with their existing schedule, dependencies and parameter passing preserved. The WRKJOBSCDE entries — daily, weekly, monthly job streams — map to the platform's scheduling surface with the same operator-facing administration shape (next-run-time, last-run-status, manual-trigger, history). SBMJOB-launched batch and the data-queue patterns used for inter-job communication translate cleanly because the platform's scheduler is itself queue-based.
What about PASE, Java on IBM i, Node.js on i and modern application surfaces?
Estates that have already moved off pure RPG / 5250 — Java on IBM i, Node.js on PASE, web-served SQL through PHP — port even more cleanly because the DDS layer is no longer in the picture. The schema imports the same way through native DB2 connectivity ; the application code (Java, Node, PHP) extracts to server-side JavaScript on the supervised runtime ; the integration surface (HTTP, web services, MQ) ports to the platform's standard library. Customers running a hybrid estate — some RPG / DDS, some modern application code — modernise both surfaces in the same engagement.
Does the platform support DB2 for i specifically, or only DB2 LUW on Linux / Unix / Windows?
Both. The platform's DB2 driver covers DB2 for i (IBM i 7.1 and later) and DB2 LUW (Linux / Unix / Windows) on the same native connectivity surface. Catalog reads, schema introspection, the embedded-SQL extraction tooling and the platform's row-level security injection all work against DB2 for i directly. DB2 for z/OS — the mainframe variant — is not in the seven-engine matrix as a first-class target ; mainframe DB2 estates typically go through a re-platform step onto DB2 LUW or PostgreSQL as part of the migration, with the database business logic ported in the same engagement.
Related modernisation stacks
The five-layer methodology is the same across source stacks. The port-mapping detail is what differs.
From Informix 4GL & Genero
Schema imports as-is, SPL stays in the database tier, 4GL forms and menus reify as repository metadata. Informix stays as the OLTP target — or lifts to PostgreSQL when the workload calls for it.
From Oracle Forms
PL/SQL stays in the database tier, Forms triggers reify as repository metadata, the Forms Server and Application Server licences go away. The Oracle database stays — or lifts to PostgreSQL.
From Delphi
VCL forms and DataModules become repository metadata, Pascal business logic moves to stored procedures and triggers, the thick-client install-and-maintain model disappears at cut-over.
From PowerBuilder
DataWindows preserved as metadata, PowerScript moves to the database tier and to server-side JavaScript on the platform runtime, EAServer and two-tier deployment removed.
From custom J2EE
Bespoke Spring / EJB / Struts / JSF frameworks replaced by the metadata-driven runtime. Hand-written SQL, integration contracts and audit history are preserved.