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 Dictionary database. 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 dictionary'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 Dictionary database. The runtime materialises the application surface from those rows. The development effort that once produced thousands of 4GL screens reduces to dictionary 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 dictionary 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 dictionary |
| 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 Dictionary 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.