Oninit® 4gl2everywhere — Modernise the Database Without Rewriting the Applications
A working portfolio of compiled Informix 4GL applications is the business case for keeping Informix — and the obstacle to moving off it. The applications work, they are paid for, the people who can rewrite them are scarce, and every project to replace them turns into a multi-year program.
4gl2everywhere lets you separate the two decisions: keep the compiled 4GL portfolio exactly as it is, and run it against PostgreSQL, Oracle, MySQL, or another supported backend at the network layer.
The three paths
Most organisations modernising off Informix face three options:
| Option | What it means |
|---|---|
| Stay on Informix | Maintain the existing licence footprint and operational expertise. Accept growing licence costs as the vendor relationship matures and the available talent pool contracts. |
| Rewrite the applications | A multi-year programme. The development team's capacity is consumed by translation work rather than new business features. No measurable business outcome during the rewrite window; reversibility erodes once the rewrite is in flight. |
| Bridge the database | Keep the 4GL portfolio in place. Redirect the database layer through 4gl2everywhere. Database modernisation moves at its own pace; application modernisation, if it ever happens, moves at its own pace. The two decisions are no longer coupled. |
4gl2everywhere is the third path.
The business case
| Outcome | Mechanism |
|---|---|
| Lower licence cost | Move workloads off Informix and onto a less expensive database without rewriting the applications that drive them. |
| Faster modernisation | Database modernisation projects no longer wait on a parallel application rewrite. The rewrite is decoupled from the migration and can happen on its own schedule, if at all. |
| Lower risk | The 4GL binary, its build chain, its development team, and the operational runbooks all stay in place. Nothing on the application side is reshipped. |
| Vendor optionality | Compiled 4GL applications are no longer locked to one database vendor. The choice of backend becomes a configuration decision rather than an architectural one. |
| Reuse what you have | The bridge runs as a standard Linux service against industry-standard backends; no new platform, no proprietary runtime, no licensed adapter layer. |
What an adoption looks like
A typical engagement runs in three phases, each reversible at the listener-config level:
| Phase | What happens |
|---|---|
| Evaluation | Stand up the bridge with the built-in null backend. Route a representative set of 4GL clients to it. Verify the wire-protocol handshake, the per-session SQL trace, and the operational behaviour (graceful drain, SIGHUP reload, session caps) match expectations. No target database is touched. |
| Pilot | Pick one application and one target backend — commonly PostgreSQL on a staging environment. Run the application against the bridge; surface any dialect- translation gaps; iterate. Measure performance and correctness against the existing Informix baseline. |
| Production | Move the application's database tier to the new backend. The 4GL clients keep talking to what they believe is Informix. Operational tooling shifts to the target backend's standard set: backups, replication, monitoring, disaster recovery. |
Each phase is reversible — the listener configuration controls which backend any given 4GL client lands on. If a workload needs to return to Informix, that is a YAML edit and a SIGHUP reload.
What success looks like
- The targeted portion of the 4GL portfolio runs against the chosen backend with no application code changes and no client-side redeployment.
- The Informix licence count drops by the number of workloads moved.
- Database operations (backup, replication, monitoring, disaster recovery) move to the target backend's standard tooling.
- The development team's velocity is unaffected by the migration; nothing they ship requires retesting against a new database driver.
- A documented dialect-translation reference exists for any Informix-specific SQL the bridge had to rewrite, so future application changes are informed by the migration's lessons.
Comparison
| Option | Time to value | App-team disruption | DB flexibility | Reversible |
|---|---|---|---|---|
| Stay on Informix | n/a (status quo) | None | None | n/a |
| Rewrite the applications | Multi-year programme | High | Full at end | Difficult once in flight |
| 4gl2everywhere | Weeks to months | Minimal | Per-deployment | Yes — flip the listener config |
Beyond the technical
| Dimension | What changes |
|---|---|
| Vendor relationship | Compiled 4GL applications no longer dictate the database vendor. The choice of database becomes a procurement decision rather than an architectural one. Renewals, contract terms, and consolidation discussions open up. |
| Talent | Hiring shifts from finding scarce Informix-specific expertise to hiring against the chosen backend's standard skill set. Internal training programmes target widely-used technology rather than a niche one. |
| Operations | Database administration, monitoring, backup, and disaster recovery move to the target backend's standard operational tooling. The bridge itself is a thin Linux daemon with standard packaging (RPM, DEB) and standard integration (systemd, syslog) so it slots into existing observability without bespoke runbooks. |
| Strategy | Future application work has the option to bypass the bridge entirely and use the chosen backend directly — but only when there is value in doing so. Existing workloads keep flowing through the bridge until you choose otherwise. |
Why Oninit
Oninit has supported the global Informix community for two decades as "the Down System Specialists". 4gl2everywhere is built and supported by the same team that delivers the Oninit® Log Ripper change capture engine and the Oninit® MySQL-2-Informix proxy — the team with deep, production-tested expertise in the Informix wire protocol. Custom backends, dialect tuning, and migration-period support are all available on commercial engagement.
What it removes from your risk register
- "Our database modernisation is blocked on a 4GL application rewrite."
- "We can't move off Informix because the applications are pinned to it."
- "Replacing the database means redeploying every 4GL client we have."
- "The 4GL portfolio is too large to migrate quickly."
- "We can't pilot the migration without committing to it."
- "Once we start the rewrite, we're locked in."
- "Operations doesn't have the bandwidth to learn a whole new stack on top of a multi-year migration."