Modernise the Informix estate without rewriting the 4GL.

Three things change and one deliberately does not. The interface changes : a character-terminal application becomes a responsive browser application that runs on a phone, that a new joiner can use without a fortnight of training, and that a customer or a supplier can safely be given a view of. The reach changes : the operational data stops being trapped behind one application, because the analytical engines connect directly and a single governed query can join across the systems the business already runs. The governance changes : multi-tenancy, row and column security, a mandatory audit trail and full observability become properties of the runtime rather than initiatives to be funded separately. What does not change is the business logic — and that is the argument for approving it now. The accumulated rules are the expensive and risky part of any modernisation ; every year of delay adds more of them, and this is the route that does not touch them.

Yes, and that is a structural property of the approach rather than a promise about execution. Each of the five layers is independently deliverable, so the programme ships in increments and runs in parallel with the existing application instead of replacing it on a single date. The conventional alternative concentrates every decision into a big-bang cut-over at the end of a twenty-four to thirty-six month programme, and the organisation carries the accumulated risk until the day it goes live. Here the schema is imported first and the existing application keeps using it ; screens move in groups ; the business rules do not move at all. There is no point in the programme at which the organisation depends on a rewrite that has not yet been proven in production.

The customer-side team is a database engineer who knows the Informix estate and a business analyst who knows what the business expects of it, working alongside ours. That is a consequence of the architecture rather than a staffing preference : the screens are generated from metadata instead of hand-written, and the business rules are not rewritten, so the two roles that most modernisation programmes cannot hire enough of — full-stack developers, and 4GL engineers willing to spend three years on a rewrite — are not on the critical path. The engineers who know the 4GL stay valuable precisely because the 4GL stays, which also removes the retention problem that a declared rewrite usually creates the moment it is announced.

It is the same risk in every conventional Informix 4GL modernisation : twenty or forty years of business rules, most of them documented nowhere but the 4GL, are expressed again in another language, and the new version then has to be proven to behave exactly like the old one. That proof is the expensive part, it is where these programmes overrun, and it is a risk taken in exchange for a screen that looks current. It is absent here because the rules are not re-expressed — 4GL executes as 4GL on the platform runtime, with the decimal arithmetic Informix defined. Nothing is re-derived, so nothing has to be re-proven. What remains are the ordinary delivery risks of any programme, and they surface in increments rather than concentrating at a cut-over date.

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.

The main options for Informix 4GL modernisation that keep Informix as the database are Four Js Genero web-tier rendering, Querix Lycia, and Airtool. Four Js Genero adds browser delivery to existing Genero source without changing the application model — the 4GL continues to be the development language and Genero remains a runtime dependency. Querix Lycia renders 4GL screens in a browser via a thin-client layer, with the application source unchanged. Airtool separates the two questions that the other options answer together. The interface is rebuilt : the 4GL forms, menus, validations and report layouts are imported as metadata rows and the browser UI is generated from them at runtime, so there is no proprietary rendering runtime and no licence attached to displaying a screen. The business logic is not rebuilt : Informix 4GL is implemented on Truffle as a first-class language on the platform's GraalVM runtime, so the rules keep executing as 4GL. Informix stays as the OLTP target. Airtool is the only one of the three where the 4GL survives as a supported server-side language rather than as a source file a proprietary runtime must keep interpreting.

The options that keep Informix while removing the Genero dependency are Querix Lycia (a rendering wrapper that keeps the 4GL source but replaces Genero's web engine) and Airtool. Airtool imports the Genero form definitions, menus, validations and report layouts as metadata and generates the browser UI from them, preserves the SPL in the database tier, and runs the 4GL business logic on the platform's GraalVM runtime — so the Genero runtime licence and the Genero application model both go, while the 4GL rules themselves keep running. Querix keeps the 4GL source active under a different proprietary renderer. Both keep Informix as the OLTP database. For estates whose goal is to remove the Genero licence and modernise the application surface in the same programme without re-deriving the business rules, Airtool is the path ; for estates whose goal is web delivery with minimal change to the application codebase, Querix is the lower-disruption option.

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.

No, and consolidation is usually the wrong instinct. Interoperability is a property of the platform rather than a project you fund. Vertica, ClickHouse and BigQuery connect directly as analytical engines with native SQL generation — not generic dialect translation — so the high-throughput aggregation runs on an engine built for it while the transactional record of truth stays in Informix. Beyond that, the platform's federation layer answers a single SQL statement across multiple connected databases : a query that previously meant fetching from one system, fetching from another and joining the results in application code is expressed once and executed through the platform's own connection management, with no federation server and no ETL pipeline in between. The permission model is applied per connection, so a federated query that touches a second database is subject to the caller's rights on that database, not only on the primary. A report can therefore read an Informix order, its analytical history on ClickHouse and a record from a third system in one governed query. Informix stays where it is ; what changes is that it stops being the boundary of what a query can reach.

It is a configuration decision rather than a rewrite, and it is deliberately not the recommendation. Six other OLTP engines are supported — PostgreSQL, Oracle, DB2, SQL Server, MySQL and SAP HANA — and the same repository metadata recompiles against a different target without re-authoring the application surface, so a modernisation that ships on Informix can lift onto another engine later without touching the application tier. In practice most Informix estates should not : the engine is doing high-throughput OLTP work it is good at, replacing it introduces performance variability that the modernisation itself does not, and the reasons teams historically gave for leaving — reaching the analytical tier, joining across systems, getting a modern interface — are all answered without moving the data. The option exists so that the database is never the thing that blocks a decision. It is not a destination the programme has to be pointed at.

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.

You can keep writing it. 4GL is a supported server-side language on the platform, not a compatibility mode with a shelf life : a program is declared as a 4GL script and executes on the platform's GraalVM runtime alongside the JavaScript and Python beside it, in the same process, the same heap, the same request and the same transaction. Teams typically settle into a split rather than a policy — existing rules stay in 4GL because they are correct and proven, new integration, batch, orchestration and AI work is written in JavaScript or Python because the standard library and the talent pool are there, and both run against the same data under the same security and audit model. Nothing forces a rewrite, and nothing forces the next thing to be written in 4GL either.

They differ in what happens to the source, and that is the only question that matters. Compiling to Java translates the 4GL once, mechanically, into Java a developer can read — same function names, same comments, same module structure — packaged as a Maven project your team builds, debugs and owns. From that point the Java is the source and the 4GL is history. Running on GraalVM changes nothing about the source : the .4gl file remains the artifact, parsed and lowered to executable nodes and compiled to machine code once a routine is hot. Choose the Java route when owning a Java codebase is the objective and the team is ready to maintain it by hand. Choose the GraalVM route when the rules are the asset, the estate keeps its 4GL engineers, and the cost of the rewrite buys nothing the business can see. Both share one compiler front end, so the decision is reversible : the same source can be run today and compiled later, or compiled module by module while the rest keeps running. Both routes are documented in depth on the Informix engineering site — 4GL to Java and 4GL on GraalVM.

Not on this platform. The GraalVM route can be embedded in a host you assemble yourself — that is a supported way to use it, and the embedding model is documented at ifxtools.com — but the host is not trivial. It has to evaluate other languages, own a connection pool and a transaction manager, lend a physical connection to a running program, and it still leaves the interface, the integration surface, the analytics and the operational tooling to be built. Airtool is that host, supervised and already assembled : the 4GL executes on the connection the platform lends it, inside the caller's transaction and pool, under the platform's row and column security, its mandatory audit trail and its observability. Adding 4GL to the estate is a configuration decision, not an engineering programme.

They are refused by name, with the file and the line, rather than emulated. This is deliberate and it is the honest boundary of the approach : 4GL is structurally a terminal language — the character screen is in the language rather than in the styling — so rendering it in a browser frame produces a terminal in a browser, not a modern interface. The platform does not attempt it. The interface is the one layer that is genuinely rebuilt : form definitions, menu hierarchies, field validations, lookups and report layouts are imported as metadata rows, and the runtime materialises a responsive, role-aware browser surface from them on Vue 3.5 / Vuetify 4. Terminal output from a running program is directed to the server's console monitor and captured with the rest of the runtime's output. What executes on the platform is the business logic, which is where 4GL is strong, and what is generated is the interface, which is where it never was.

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.

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.

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.

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.