The business case, on one page.
Written to be forwarded. What the migration changes, what it costs in kind if not in figures, what stops being paid for, what carries no risk of being repeated — and what we would need from you to put a number on it.
What stops being paid for
Runtime licensing. Today the application is licensed by concurrent session, socket, processor unit or user, and it recurs every year for as long as the application lives. After the migration it runs on a JDK, and that cost ends rather than moving.
What does not change
Informix. The engine, the schema and the data stay exactly where they are, reached the same way. This is a migration of the application source, not of the data tier, so there is no conversion, no second database and no cut-over of anything the business stores.
What the team gets, without being forced anywhere
Modern working conditions around the same rules : a build, automated tests, a debugger, and a language a very large number of people already write. Maintaining the application becomes an ordinary advertisement rather than a search for one of the few remaining specialists. And no obligation to convert everything — the rules that work can stay in 4GL and go on being edited there while new capability is written in Java, in one application. Whether the generated Java ever becomes the source is a decision taken later, or never.
What the exposure is
One payment for the licence, once, and an engagement quoted per wave from measurements of your own source. Nothing of ours sits in the running application afterwards, so there is no annual fee attached to keeping it alive.
The comparison that decides it.
The application is already being paid for every year. Those licences are metered by usage — by concurrent session, by socket, by processor unit, by named user — so the bill grows as the business does, and it arrives again next year whatever happens.
Our licence is one payment, sized by how much 4GL there is to translate, and it is perpetual. There is no charge per user, per session, per core or per CPU, now or at any later point. The question a board is actually deciding is whether a one-time cost that ends is worth more than an annual cost that does not — and for a large estate, comparing the one-time licence against a single year of what is currently spent simply to keep running is the most useful place to start. The assessment puts your own numbers on both sides of that comparison.
Recompiling into a newer 4GL is the third option, and it is worth naming because it looks cheaper. It replaces the meter rather than removing it : the estate ends on another proprietary runtime, licensed per seat or per server for the life of the application, and the same conversation returns in a decade.
Why the risk is smaller than the size suggests.
Nothing moves in one step. The estate is migrated in waves, subsystem by subsystem, each one proved against the original programs it replaces before it goes into production while everything else carries on unchanged. There is no date on which the business changes system.
Correctness is demonstrated rather than asserted : the same programs are run both ways on the same data and the output compared, to the cent on arithmetic and byte for byte on reports. That comparison runs on every build afterwards, so it becomes a standing check rather than a testing phase somebody remembers.
And if the supplier relationship ends, nothing stops. The generated code carries no licence, no key and no activation, and contacts nobody. Where procurement needs more than that, the compiler's own source is available through escrow with defined release events, or under an enterprise agreement — set out on the services page.
The operational return, in the terms it is usually felt.
The estate was built before automated testing was ordinary practice, so it is verified today the way everything was then : by people, at terminals, working through checklists. The cost of that is not the testing. It is the caution — changes are expensive to verify, so fewer are attempted, releases are batched into larger and riskier ones, and the judgement of whether a change is safe rests with the few people who remember how the system behaves.
Once the application is Java it is tested by the build, on every change, on the infrastructure the organisation already runs. Releases get smaller because each is verified, and knowledge moves out of individuals into tests that fail when they stop being true.
The hiring position changes at both ends, and this is usually the part a board feels first. Java is one of the most widely written languages there is — taught everywhere, documented everywhere, and written by an enormous number of people in every market you might recruit in. A system that today needs one of a shrinking number of 4GL specialists becomes a system any competent developer can be put on. And the people you already have can change it with evidence rather than memory.
In regulated sectors there is usually one more argument, and it is often the one that carries : the build produces a record, per release, that the pricing, credit and approval rules behaved as specified.
None of which requires committing to Java as the destination. The two languages coexist in one application : rules that are correct and well expressed in 4GL can stay in 4GL and keep being maintained there, while new work — an integration, a scheduled job, a service another system calls — is written in Java against the same data and the same rules. Adopting the generated Java as the source is a separate decision, available on the first day and on any day after it, and a perfectly reasonable answer to it is not yet.
What the application depends on the day after cut-over.
Every route out of Informix 4GL leaves the application depending on something. The useful question is what, and the answer here is short : a JVM the organisation already deploys, and Informix, unchanged, underneath it. We license the compiler. The Java it generates, the runtime library that Java calls and the applications built from them are not licensed, not metered, not node-locked and carry no seat count. Generated code needs no licence file, no key, no activation and no network access to run, and nothing in a translated application contacts us.
There is a plain test of that, and it is worth applying to any proposal including ours : ask what stops if the supplier does. Here, nothing. If a trial licence expires the compiler stops translating new 4GL, and everything it has already produced goes on running in production, on any number of machines, for any number of users, indefinitely. The tool can leave and the application does not notice, which is the property that makes this a migration rather than a change of supplier.
How this is bought : one model, two licence forms.
The licence is one payment, once, sized by how much 4GL there is to translate. It is perpetual. There is no charge per user, per session, per core or per CPU — not now, and not later when the application is carrying more of the business than it does today. An estate that doubles its users owes us nothing further. And nothing the compiler produces is licensed either : the generated Java, the runtime library it calls and the applications built from them run with no key, no meter and no licence server.
That is the opposite of what this market does. The incumbent licences are metered by concurrent session or by socket, and a modern 4GL replaces that meter with one counted in users or cores — both recurring every year for the life of the application, both growing as the business does. Ours is a one-time cost that ends. The one decision left is which of two forms the licence takes.
The two licence forms
Both are perpetual, both are one payment, and under both the running application depends on nothing of ours. They differ in exactly one thing : who holds the toolchain.
| Standard licence | Source code licence | |
|---|---|---|
| What you receive | The compiler, licensed perpetually to a named organisation. You run it ; we maintain it. | ✓ The source of the compiler and of the GraalVM execution engine, delivered up front, with a maintenance and support agreement that stands behind your engineering team. |
| What runs in production | Plain Java source you hold — application and runtime — with no licence, no key, no meter and no seat count. | ✓ The same plain Java — and a toolchain your own people can build, patch and extend. |
| The toolchain | Ours to maintain, under an optional maintenance agreement. Source code escrow with defined release events is available on top. | ✓ Yours. Your organisation holds the codebase and the engine that executes it, and maintains both with its own team for as long as the system lives. |
| Support | Versions and fixes : maintenance releases, defect resolution and compatibility with new Informix and JDK releases. | ✓ Full engineering support, behind your team : fine-tuning, evolution and new features built with your engineers on the codebase you hold — not only fixes to ours. |
| Right when | The standard purchase. Nothing of ours sits in the path of the running application, which for most estates settles the question. | ✓ Toolchain control is a board or procurement condition — the position of organisations that no longer accept a critical system resting on licence terms set elsewhere. Self-sufficiency, as a deliverable rather than an aspiration. |
And the three prices around it, stated plainly.
Around the licence : maintenance is optional and nothing stops if it lapses ; the assessment is charged and then credited in full against the licence if you proceed ; and the migration engagement is quoted separately, per wave, from measurements of your own source. We would rather price three things honestly than one thing vaguely.
These are six-figure decisions and it is more useful to say so than to be coy about it.
The relationship the model is built for is the one described on the company page : an engineering partner your team calls on, not a dependency your application cannot run without. The contractual instruments — the standard licence, escrow and the source code agreement — are set out on the services page.
Why now, and what you end up owning.
The case for acting while the application still works, what the organisation owns at the end, and how a programme starts.
Why do this now, while the application is working well?
Because that is the condition in which it goes well. A migration is verified by running the old system and the new one side by side on the same data, which requires the 4GL to be healthy, the business to know what correct looks like, and the timetable to belong to you. Estates that move while everything is working choose their own pace and prove every step ; the same exercise begun under pressure is the same exercise with the evidence removed. The application running smoothly today is the asset that makes this straightforward, not a reason to wait.
What do we own at the end, and what stays licensed?
Plain Java source, and the knowledge to change it. The compiler is the only licensed component and the licence is perpetual — it is a tool your team runs, not a dependency of the application it produces. The translated code and the runtime library it calls are Java source delivered into your repository with a perpetual right to use, modify and maintain them, so nothing in the running system requires a licence from us and there is no runtime tier to renew. That is the practical difference from converting to another vendor’s 4GL, where the runtime licence follows the application for as long as it lives. The licence itself comes in two forms — the standard licence, or a source code licence that delivers the compiler and the GraalVM execution engine as source, with support behind your own engineering team ; the comparison is set out above.
How does an engagement start?
With an assessment of your actual source. We translate a representative slice of your estate, report what carried across cleanly and what did not, and give you the counted work queue. That produces a scope you can put in front of a board, before you commit to a programme.
What we would need to put a number in front of you.
Two things, and the first is free. A count of the live estate — which means separating what is actually running from old copies, dated backups, modules no menu reaches, generated code and vendor libraries. That routinely takes a third off a reported figure, and it is work we do with you before anything is quoted, because it decides the scope and the price and it almost always moves in your favour.
Then a measured sample. A representative set of programs translated and run against your own data, which is what turns an estimate into a scope : coverage on your code rather than an average of somebody else's, and a counted list of everything needing a decision. That is the evaluation, it is designed with you before it starts so that both outcomes are useful, and the fee for it is credited in full against the licence if you proceed.
These are six-figure decisions and it is more useful to say so than to be coy. The number that matters is not ours in isolation ; it is ours set against a year of what is already being spent to keep the application running.