We do the migration with your team, not to your estate.
A translated codebase is only worth what the organisation can do with it afterwards. So the engagement is built around capability as much as code : your developers work alongside ours on your own source, learn the generated patterns while they are being produced, and own the result at cut-over. Support continues into the life of the Java application rather than ending at handover.
The deliverable is a team that owns its application again.
The risk a board should be asking about is not whether the translation is correct. That is measurable, and it is measured — translated programs are run against your original 4GL binaries on the same data and compared. The real risk is the one that shows up eighteen months later : the migration completed, the consultants left, and nobody inside the business can confidently change the code.
That outcome is not caused by bad translation. It is caused by treating knowledge transfer as a phase at the end, when the people who built the thing are already rolling off. So it is not a phase here. Your developers are on the code while it is being produced, reviewing output as it lands and making the decisions the compiler escalates. By cut-over, the people who will maintain the application have already been maintaining it.
Support across the whole path — and after it
Handover is the point at which modernisation programmes most often fail, so the engagement is written not to end there.
Before — a scope that survives a board review
We translate a representative slice of your estate and report what carries across cleanly, what needs a human decision, and the counted work queue behind it. The output is a scope with numbers in it, produced from your own source, before you commit to a programme rather than after.
During — side by side, on your code
Your developers work with ours on your estate. The generated patterns, the runtime library and the constructs that need a decision are learned in context — on the application they will own, not on a training example. Pairing, review and handover happen continuously rather than in a final week.
Cut-over — proven, not hoped
Before anything is switched, the migrated application runs against your original 4GL binaries on the same data and the output is compared. Parity is demonstrated to your team, on your estate. The go-live decision rests on evidence your own people have seen, not on our assurance.
After — lifecycle support
Support continues into the life of the Java application : reviewing changes, extending the runtime library where your estate needs it, advising as the codebase evolves. The relationship is designed to outlast the project — and to become unnecessary whenever you decide it should.
What your team actually learns.
Generated code is only maintainable if the people inheriting it understand why it looks the way it does. Three things are taught explicitly, because they are what a developer needs on day one after handover.
The shape of the output — one module to one class, one function to one method, in source order, so a change can be located from the 4GL anyone still remembers. The runtime library — why 4GL arithmetic, comparison and formatting resolve to named calls instead of Java operators, and what each of them guarantees. The escalation points — the constructs the compiler deliberately refuses to guess at, and how to decide them, so the team can keep translating after we have gone.
Estates this size are migrated in waves, and counted before they are quoted.
An Informix 4GL estate worth migrating is rarely under half a million lines and is sometimes ten million. Nothing that size moves in one cut-over, and nobody should be asked to commit to one. The programme runs subsystem by subsystem : each wave translated, proved against the 4GL binaries it replaces, and put into production while the rest of the estate carries on exactly as it is.
Which makes counting the estate the first piece of real work rather than a formality. Reported line counts include old copies, dated backups, modules no menu reaches, generated code and vendor libraries — and separating the live estate from all of that routinely takes a third off the number. We do that count with you before anything is quoted, because it decides the scope, the sequence and the price, and because it almost always moves in your favour.
What the count does not decide is the effort. That comes from how often the compiler needs a human decision, measured per thousand lines on a representative sample across subsystems rather than guessed at from a total. Two estates of the same size can be two years apart, and the only honest way to know which one you have is to measure it on your own source.
Three ways to run it — and the estate usually picks
We run the migration
Sound for an estate up to about a million lines, or for one subsystem of a larger one. You send the source ; we return the Java. We translate the estate, work through whatever the compiler flags for a human decision, prove the result against your own 4GL binaries, and hand over a codebase your team can build. The right answer when the 4GL developers have already gone, or when the team has no capacity to take this on alongside the day job.
Test it on your own 4GL →We run it with your team
The usual shape between one and three million lines. A joint engagement, with your developers alongside ours. They learn the generated code while it is being produced rather than inheriting it cold, and they carry the domain knowledge we do not have — which rules matter, which screens are used daily, which edge case is load-bearing. Most estates are migrated best this way.
Talk to us about a joint migration →You run it, we support you
The only shape that scales past about three million lines. Your team drives the compiler and we sit behind them : reviewing output, resolving the constructs that need a decision, and extending coverage where your estate needs it. The right answer when you have Java capability in house and want the knowledge to stay there.
Talk to us about supported self-delivery →If holding the toolchain is a procurement condition, there are established ways to do it.
Some organisations cannot depend on a supplier continuing to exist, and say so in the contract rather than in the meeting. That is a reasonable position for a system with a thirty-year horizon, and it is answered with instruments the market already has rather than with reassurance. Three arrangements, in ascending order of what they place in the customer's hands.
The standard licence
The compiler is licensed to a named organisation. What it produces is not : the generated Java, the runtime library that Java calls and the applications built from them carry no licence, no meter, no node lock and no seat count, and need no key or network access to run. For most estates this settles the question, because nothing of ours is in the path of the running application.
Source code escrow
The conventional three-party arrangement : the compiler's source, its build instructions, its documentation and its third-party dependencies are deposited with an escrow agent, and released to you on defined events — insolvency, withdrawal of support, or failure to meet the obligations in the agreement. On release you hold a licence to use, modify and maintain it for your own purposes. Insist that the deposit is verified and rebuildable ; an escrow deposit nobody has ever compiled is a document, not a remedy.
A source code licence
Where escrow is not enough, the compiler is available under an enterprise agreement that delivers the source up front rather than on a release event, with the rights to use, modify and maintain it internally. The usual limits apply and are worth stating plainly : it is for your own use, not for sublicensing, distribution or offering to third parties. A negotiated agreement rather than a standard purchase — worth putting on the table early if it is your position.
Cost, duration and commitment.
How the work is priced, how long it runs, and what happens if you want to stop or take it over.
What does it cost, and how is it priced?
The compiler licence is one payment, once, sized by how much 4GL there is to translate, and perpetual. Never per user, per session, per core or per CPU — the application owes us nothing after cut-over, however many people end up using it. Maintenance is optional. The assessment is charged and credited in full against the licence if you proceed, and the engagement is quoted per wave from measurements of your own source. These are six-figure decisions ; the useful comparison is against a year of what you currently pay in runtime licensing, which recurs where ours does not.
How long does a migration take?
It depends on the estate, which is why the assessment exists rather than a price list. The assessment translates a representative slice and returns a counted work queue, per program, so the timeline is built from measurements of your own source rather than from an average of somebody else's.
Can we stop, or take it over, part-way?
Yes, and the work is structured so that stopping is not a cliff. Translated output is complete Java source at every stage, and the compiler licence is perpetual, so the toolchain does not stop working if the engagement does. Taking delivery in-house mid-programme is a supported outcome, not a breach.
Who delivers, and what happens afterwards.
The team doing the work, the case where the 4GL knowledge has already gone, and life after go-live.
Who does the work?
Engineers who have built the compiler and migrated with it, working alongside your developers. The mix shifts deliberately over the engagement : heavier on our side while the patterns are unfamiliar, heavier on yours as they stop being unfamiliar. If your team is doing less at the end than at the start, the engagement has gone wrong.
What if our 4GL developers have already left?
This is the common case, and it is one of the reasons to act rather than to wait. The source is the specification, and the compiler reads it whether or not anyone remembers writing it. Where a construct needs a business decision we bring it to whoever knows the process today, in business terms rather than in 4GL.
What happens to support after the project ends?
It continues if you want it : reviewing changes, extending the runtime where your estate needs it, and advising as the application evolves. It is a separate arrangement from the migration itself, and it is optional — a team that no longer needs us is the intended end state, not a lost account.