Modernise Informix 4GL estates on a metadata-driven runtime.
The Informix 4GL applications that still process billions of transactions a year — with their stored procedures, triggers and screens accumulated over decades — migrated to a modern, AI-ready platform without translating the business logic into code. The database stays Informix if you want it to. The application surface becomes metadata.
The deepest Informix shop you will find
Three decades of Informix engineering — IDS, CDC, data blades, Java extensions, full DBA-grade operations. We know what the engine does, and we know which application patterns it supports natively.
The schema stays
The Informix schema is imported as-is. Tables, indexes, constraints, full-text indexes, sequences. No re-modelling. No translation. The reference data model continues to be the reference data model.
The SPL stays
Stored procedures, triggers, user-defined routines stay in the database tier. SPL is preserved, modernised in place, never re-platformed into Java imperative code. Three decades of accumulated business logic is preserved as a native asset, not as a translation risk.
The 4GL screens become metadata
The 4GL form definitions, menu structures, field validations and report layouts are imported and reified as metadata rows in the Metadata Repository. The runtime materialises the application surface from those rows. Zero hand-written screen code.
The five-layer methodology, applied to Informix 4GL
From the schema outward. Each layer is independently deliverable. Cut-over is incremental.
1 · Schema
Informix tables, indexes, sequences, constraints, full-text indexes — imported into the metadata repository's table-object catalogue. Type mappings are applied automatically. Foreign keys, defaults, check constraints become rows the platform can recompile against the same Informix engine or against any of the platform's other target engines, when the workload calls for it.
2 · SPL and triggers
The schema-code processor imports user-defined routines, stored procedures, triggers and built-in extensions in the order their dependencies require. Per-object timestamps track change history. Cross-include resolution preserves the existing modular structure. Performance characteristics carry forward.
3 · 4GL forms become metadata
4GL form definitions, menu hierarchies, field validations, lookups, report layouts and screen-level business rules are read and reified as rows in the Metadata Repository. The runtime materialises the application surface from those rows. The development effort that once produced thousands of 4GL screens reduces to metadata maintenance.
4 · Batch and middle tier
Server-side JavaScript on the platform's GraalVM Polyglot runtime, with the platform's standard library, handles what 4GL programs once handled outside the database — scheduled batch, integration, file handling, document generation, AI orchestration.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The character-mode or thin-client 4GL screens become responsive browser UI without per-screen development. Mobile delivery, role-aware rendering and accessibility are properties of the runtime, not features to be added.
What changes for the operator
The Informix estate keeps doing what it does well — high-throughput OLTP with the data metadata repository you already trust. What changes is everything above the database: the application tier becomes a metadata description that the platform interprets at runtime, integration becomes a first-class concern handled by the platform's gRPC microservice mesh, and observability becomes a SELECT against in-memory MemDB schemas.
The team that delivers this is a database engineer who knows the Informix estate and a business analyst who knows what the business expects of it. The full-stack developer scarcity that kills most legacy modernisations is not on our critical path.
A typical Informix 4GL migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Database choice | Locked at project start (usually away from Informix) | ✓ Open. Informix stays if you want it; PostgreSQL or another target if the workload calls for it. |
| Schema strategy | Re-modelled in the target dialect | ✓ Imported as-is into the metadata repository |
| SPL and triggers | Translated into application code | ✓ Preserved in the database, modernised in place |
| 4GL screens | Re-written by hand, one at a time | ✓ Imported as metadata; UI is generated at runtime |
| Customer-side team | Full-stack developers, Informix experts, project managers | ✓ Database engineer + business analyst + our team |
| Cut-over | Big-bang at the end of 24–36 months | ✓ Incremental, parallel-run, business runs through migration |
| Performance after go-live | Variable; often degraded vs the Informix baseline | ✓ Predictable. The OLTP engine you trusted continues to do the work. |
Why the Informix estate is worth preserving
Informix is one of the most under-appreciated production databases in the enterprise software market — quietly running mission-critical OLTP for a generation of customers who chose it because it works. The modernisation question is rarely "should we leave Informix?" — it is "how do we modernise the application surface without abandoning the engine that does the work?"
Our answer is the same answer we apply to every source stack: preserve what is valuable, modernise what limits the business. The schema is valuable. The SPL is valuable. The 4GL screens are a cost. The platform handles the screens; the database keeps running.
The same methodology applies to Four Js Genero — the modern Informix 4GL successor. Genero developers ship the same XDBL the runtime takes from any other source stack ; the form definitions, menus, validations and report layouts become repository metadata, the SPL stays in the database, and the business logic that has accumulated under decades of Four Js Genero engineering is preserved in place rather than rewritten.
What Informix shops ask before they engage.
Does the modernisation force us off Informix?
No. Informix stays as the OLTP target if the existing operational depth justifies it. The platform's Tier-1 DBA team — IDS, CDC, data blades, Java extensions — continues to operate the engine in place ; only the application tier is modernised. Informix is one of the most under-appreciated production databases in the enterprise market, and customers who chose it because it works are not asked to abandon it as the price of admission.
If we wanted to leave Informix in the future, what would the natural target be?
PostgreSQL. It is the platform's default modern OLTP target, deeply tested by the platform team, and the natural move for Informix estates that want to escape the engine's licensing or talent-availability constraints without changing application semantics. The same repository metadata recompiles against PostgreSQL without re-authoring the application surface ; the modernisation that ships on Informix this year can lift onto PostgreSQL next year without touching the application tier. Other supported engines remain available where a customer's commercial landscape requires a specific target — but PostgreSQL is the recommendation for Informix shops planning their forward path.
What happens to SPL, triggers and user-defined routines?
They stay in the database tier and are modernised in place. The schema-code processor sequences user-defined routines, stored procedures, triggers and built-in extensions in dependency order, with per-object timestamp tracking and cross-include resolution. Three decades of business logic encoded in SPL survives the modernisation intact — not translated into imperative Java, not re-platformed into application code.
How do 4GL forms and menus migrate?
4GL form definitions, menu hierarchies, field validations, lookups, report layouts and screen-level rules are imported and reified as rows in the Metadata Repository. The runtime materialises the application surface from those rows on Vue 3.5 / Vuetify 4 — responsive, role-aware, mobile-ready. The development effort that once produced thousands of 4GL screens reduces to metadata maintenance.
What about Four Js Genero — does the same methodology apply?
Yes. Genero is the modern Informix 4GL successor and the same five-layer methodology applies : the form definitions, menus, validations and report layouts become repository metadata, the SPL stays in the database, and the business logic accumulated under decades of Genero engineering is preserved in place rather than rewritten.
Do CDC streams and data-blade extensions survive the modernisation?
Yes. Informix CDC capabilities are preserved — including streaming to the analytical tier (Vertica, ClickHouse, BigQuery) through the platform's native multi-engine SQL generator. Java extensions and data blades continue to operate against the same engine ; the modernisation does not require their reimplementation.
How does the performance compare with the Informix baseline?
Predictable. The OLTP engine that has been doing the work continues to do the work — the modernisation re-platforms the application tier, not the database tier, so the throughput characteristics customers chose Informix for are preserved by construction. The variability that surfaces after typical engine-swap migrations is not present.
Can we scale reads onto Informix HDR / SDS / RSS secondary replicas without changing application code?
Yes. The platform's data-access layer classifies every query as read or write at compile time and routes read traffic to the configured Informix secondary replicas — HDR primary / secondary, Shared Disk Secondary, Remote Standalone Secondary — automatically and transparently. Routing is a system-configuration choice declared once in the platform's connection topology ; the application does not change a line of code. Adding a replica is a configuration step, not a migration. The same capability applies to PostgreSQL streaming replicas and Oracle Data Guard standbys — read-scaling is a runtime property of the platform, not an application discipline the customer's engineers have to remember.
What about reporting — what do we get versus Informix ACE Reports or our existing report writer?
An enterprise reporting and analytics surface far beyond what ACE Reports — or any 4GL-era report writer — was designed to deliver. The platform integrates three columnar analytical engines (Vertica, ClickHouse, BigQuery) for high-throughput aggregation, with native SQL generation rather than generic dialect translation. Interactive dashboards carry drill-down, drill-across and cross-filtering : click a slice of a pie, every related chart, table and KPI updates against the same governed query. Cubes, dimensions and measures live as repository metadata ; reports compose in the same authoring tool that produces operational screens. PDF, Excel, browser-grid and printable layouts render through the platform's document-processing microservice. Row-level and column-level security applies to every report by construction. PowerBI, Tableau and Looker are the realistic comparators on the interactive-BI dimension — not the 4GL-era reporting tools the Informix estate is currently constrained by.
Related modernisation stacks
The five-layer methodology is the same across source stacks. The port-mapping detail is what differs.
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.
From IBM i (AS/400)
DB2 for i schema imports through native DB2 connectivity, RPG and DDS reify as repository metadata, the 5250 green-screen surface becomes a browser. Stays on DB2 for i — or lifts to PostgreSQL.