When the application tier is the constraint, not the database.
Sometimes it is not Informix that holds the business back — it is the character-mode screens, the ageing client, or the framework above the database that no one wants to maintain. When that is the real constraint, there is a route to modernise it that keeps the schema, keeps the stored logic, keeps Informix doing the work — and, because the platform executes on GraalVM, runs your 4GL business logic as 4GL instead of rewriting it. It is optional, it is incremental, and it is yours to time.
The schema stays
The data model is imported as it is. Tables, indexes, constraints, sequences — no re-modelling, no translation. The reference model continues to be the reference model.
The stored logic stays
Stored procedures, triggers and routines stay in the database tier and are preserved in place, not rewritten into application code. Decades of accumulated logic remain a native asset.
Informix keeps the work
The engine that has run the transactions continues to run them. The modernisation re-platforms the application surface above the database, not the database itself.
Incremental, never big-bang
Cut-over is phased and parallel-run. The business keeps operating through the change, rather than waiting on a single switch at the end of a multi-year programme.
Three ways to run 4GL
How the forward path works
The application surface — screens, menus, validations, report layouts — is imported and described as metadata that a modern runtime materialises at run time, rather than rewritten screen by screen. The stored logic stays in the database. Informix stays as the transactional engine, with a modern target available later if the estate ever wants to move, using the same imported model rather than a fresh re-authoring.
The team that delivers it is a database engineer who knows the estate and an analyst who knows what the business expects of it. The scarcity of full-stack developers that stalls most legacy programmes is not on the critical path.
The platform executes on GraalVM, and 4GL is a language on GraalVM.
This is the part that changes what a forward path can offer. The platform's server-side execution runs on a GraalVM polyglot runtime, which is the same runtime Informix 4GL has been implemented against as a language in its own right — registered under its own identifier, compiled to native instructions by the platform's compiler, sharing one heap with the JavaScript and Java beside it.
The consequence is that the business logic is not rewritten to reach a modern application. A pricing rule refined over twenty years goes on being the 4GL that already prices correctly, executing as a routine inside a modern server, while the screens above it become metadata and the interface becomes a current web interface. What gets replaced is the surface, which is where 4GL was always weakest ; what survives is the arithmetic and the rules, which is where it has always been strong.
That is a different proposition from a conventional modernisation, which asks an organisation to re-derive decades of rules in a new language and then prove the new version behaves like the old one. Here the rule is not re-derived, because it is not rewritten. The mechanism, the execution model and its limits are set out at 4GL on GraalVM.
This is not a language conversion. Most of the code stops existing.
It is worth being precise about what this is, because it is easy to mistake for a translation exercise and it is not one. A language migration takes an estate of two hundred thousand lines and returns two hundred thousand lines in another language : the same application, the same shape, maintained by the same number of people.
This is a different proposition. Screens, menus, validations and report layouts are described once as metadata and materialised by the runtime, so the per-screen code that made up most of the estate is not rewritten — it stops being code at all. What remains to maintain is the business logic that was always the point, and it is a fraction of what came in. The distance between the two is closer to the distance between a proprietary 4GL and a cloud platform than to the distance between two programming languages : four decades of architecture, not a change of syntax.
Which is right depends on the ambition. If the application is sound and the constraint is the language and the hiring market around it, a source migration to Java is the proportionate answer and it is documented here. If the constraint is the application surface itself — the screens, the delivery model, the cost of every future change — then rewriting it in a newer language preserves the problem.
Where the detail lives
The application-tier modernisation is delivered on the Airtool platform, and the methodology — the five layers, the port-mapping detail, the named alternatives for Informix and Genero estates — is documented there in full.
Read the Informix modernisation methodology at airtool.io/modernisation/from-informix, or the platform architecture at airtool.io/platform. When you are ready to scope it, start where everything here starts — with a read-only diagnostic run of what you run today.