Millions of lines only a few people can navigate become millions of lines the organisation can ask.
An Informix 4GL estate can be one of the most valuable and least visible software assets in the business: decades of pricing, credit, despatch and period-close rules that exist in no other written form. The compiler that migrates it also answers questions about it — over the Model Context Protocol, to your own AI assistant, from the first day it is installed. The estate stops being an archaeology project and becomes something the business can interrogate, cost and plan against.
An unknown estate becomes a costed one
Questions the business has never been able to answer — what calls what, what nothing reaches, what breaks if a column changes, which routines are hard — answered over the whole estate in seconds rather than in a discovery phase.
The answers are the compiler's, not the model's
Each tool is a thin wrapper over the compiler that produces your build. The assistant is not reading your 4GL and forming an opinion. Its answer and your build cannot disagree.
A lifecycle that starts again
Translated to Java, the estate joins Maven, JUnit, the IDE, the debugger and the open-source Java ecosystem — and a labour market of millions instead of a shrinking pool.
Your source stays where it is
The tools read files on the machine they run on. What travels is the answer, and only as far as the assistant you have already approved.
The decision nobody can currently make
Ask any organisation running a large 4GL estate what it would cost to modernise it, and the honest answer is that nobody knows. Not because the question is hard, but because the estate is unreadable at scale. The specification was lost decades ago, the analysts moved on, and the code became the specification. What remains is millions of lines that a shrinking number of people can safely change and nobody can survey.
That is the actual reason these programmes overrun. Scope is discovered after the budget is committed, because there was no way to discover it before. The hidden costs are always the same and always invisible from the outside: the routines nothing reaches that are still being maintained, the functions no 4GL defines that a migration has to supply from somewhere, the shared state that means the system cannot be lifted apart one piece at a time.
Those are not opinions. They are facts the compiler already computes, every time it reads the estate. Until now there was no way to ask it.
One application, measured in seconds
These figures describe a single financials application — not a company's whole codebase. A module is one .4gl source file; a program is the group of modules that share an entry point, so an application of this size is many programs built from a common body of modules. Every figure is produced by the compiler's own analysis rather than by a search of the text, and each answer returns in about five seconds over the whole application. None of them was obtainable before.
Why pointing an assistant at raw 4GL makes things worse
The obvious move, once an organisation has an AI assistant, is to point it at the source. It does not work, and the way it fails is the dangerous one. Informix 4GL is thinly represented in the material these models learned from, and the language cannot be understood from its text alone: a column's type lives in the database catalogue, not in the program, and a declaration made against a table pulls in every column that table has without naming one of them. An assistant reading the text has no catalogue and no parse tree. It produces something fluent, plausible and unverifiable.
For a system that runs the business, a confident wrong answer is worse than no answer, because it will be acted on. This is the reason most enterprise AI pilots on legacy code stall at the demonstration: the output cannot be put in front of anyone accountable.
The fix is not a better model. It is giving the model something exact to ask. The Model Context Protocol is the convention that lets an assistant call a tool; this compiler implements the server side of it. The assistant still interprets the question in your words and still explains the answer in them — but the answer itself comes from the parser, the catalogue reader, the translator and the headless runner that produce your build. That is the difference between an AI demonstration and an answer that survives a review.
What each one can actually determine about your program
Not a question of model quality. The right-hand column is computed from the parse tree, the catalogue and the call graph — none of it becomes available to a reader of the text at any size of model.
| An assistant reading the source | The compiler, over MCP | |
|---|---|---|
| The type and precision of a variable | Not written in the program, so unknowable | ✓ Resolved from your live catalogue, with scale |
| How a money calculation rounds | Inferred from context | ✓ Determined by the declared decimal width |
| A dependency that names no column | Invisible — there is nothing to match on | ✓ Reported, and the table-level ones first |
| Which declaration a name refers to | Guessed from proximity | ✓ Resolved through the globals file the program names |
| Whether anything reaches a routine | Cannot be computed from a sample | ✓ A graph property over the whole estate |
| A name no 4GL defines | Indistinguishable from one defined elsewhere | ✓ Listed — the runtime surface a migration must supply |
| A cursor opened here and closed elsewhere | Not visible one file at a time | ✓ Gathered across the program before anything is judged |
| SQL running with no error handling in force | A text pattern at best | ✓ The state actually in force at each statement |
| Asking the same question twice | May answer differently | ✓ Byte-identical output |
| What it could not read | Silently absent from the answer | ✓ Named, and excluded from the totals |
| Checking its own answer | Not possible | ✓ Compiles the Java, runs the program, compares the reports |
The tools, grouped by the question an executive is actually asking
Each is a thin wrapper over a compiler entry point the build already tests. Nothing here is a second implementation that could drift from the first.
What have we actually got?
estate_survey reports how much of the estate parses and groups the failures by cause, which turns a number nobody can act on into a work queue — in practice the files a survey cannot read trace back to a handful of recurring constructs, not to hundreds of separate problems. outline gives one module's database, entry point, functions, reports, calls and tables.
How is it held together?
call_graph reports what calls what, what nothing reaches, what is defined twice, what no 4GL defines at all, and where the graph loops. who_calls finds every call site of a function. globals_usage reports who reads and who writes each piece of shared state — which is what determines whether the estate can be migrated in pieces or only whole.
What breaks if we change something?
schema_impact answers what a column change touches. This is the dependency that is invisible in the text: a record declared to match a table names no column, yet every column belongs to it, so the modules that change shape are the ones that mention the table. where_used finds every place a table or column is named in SQL.
Where is the risk concentrated?
sql_inventory lists every database statement and the defects that are not syntax errors — cursors never closed, transactions left unfinished, statements running with no error handling in force, SQL built at run time. complexity reports size and nesting depth side by side so a migration can be ordered by difficulty rather than by guess.
What does it become?
describe_table gives a table's columns with both the 4GL type and the Java type it maps to. translate returns the generated Java and, just as importantly, what did not translate.
Does it still work?
run executes a program headless, with scripted keystrokes, and compiles_check answers whether the generated Java actually builds — because a translation that returns Java is not the same claim as one that returns Java a compiler accepts. Together they are what make everything else checkable: an assistant that can translate a program and then watch it work is checking its own answer rather than asserting one.
What should we do first?
review_program makes one pass over a program or the whole estate and returns a single ranked list, banded by what a finding costs rather than scored: blocking — the compiler cannot read it, so nothing downstream is true; structural — it decides how the migration is organised; housekeeping — real, and safe to leave. It also states what it did not review. One call turns everything above into a queue rather than a set of reports.
AI-native from the first day, not added later
This capability is not a roadmap item or a separate product. It ships in the distribution beside the compiler itself, installed by the same command, and it is pointed at your estate the day the compiler is. The same tools are available from a shell and over the protocol, and a test asserts the two paths return byte-identical answers — so the capability a person verifies by hand is the same one the assistant uses, not a demonstration version of it.
It is also deliberately not a service. There is no daemon, no port, no URL and nothing to keep alive. The assistant starts the tool as a child process when a conversation needs it and it stops when the conversation stops. Between conversations, nothing of it is running.
For an organisation whose AI programme has so far produced pilots nowhere near the systems that matter, this is the opposite shape: the first place AI is applied is the estate the business actually runs on, with the answers coming from a compiler and every tool call approved by the client before it executes.
The larger question: can we go on developing it?
The question behind a legacy estate is rarely how to leave it. It is whether it can still be changed. Most 4GL applications are in maintenance-only mode — not because the business has stopped asking for things, but because nobody can predict what a change will touch. A system that cannot safely be changed has already been retired, whatever the budget says about it.
What lifts that constraint is not a single tool. It is that the estate rejoins the engineering practice the rest of the organisation already runs on. The source sits in version control, where a change is a commit with an author, a reason and a diff a colleague can review. A build server turns that commit into a versioned artifact with one Maven command. Tests run as part of the build rather than as a fortnight of manual checking before a release. Static analysis, dependency scanning and the release process apply because the output is ordinary Java. One pipeline, one set of controls, and no special case that only two people are allowed to touch.
The assistant makes that loop conversational — ask what a change reaches, propose it, watch it be checked — but it is not what makes it trustworthy. The compiler and the runtime do that, mechanically, the same way they check a person's work. That is the difference between AI-assisted development on a system that carries a business and generated code nobody can validate.
The Model Context Protocol is an open standard, not a private interface. Claude, or any other assistant that speaks it, connects to the same tools and receives the same answers — so this creates no dependency on one AI vendor, and nothing has to be bought again if that choice changes.
The development loop, restored
Every step is a command a build server can run unattended. The assistant is a way of driving the loop, not a substitute for any part of it.
1 · Ask what the change would touch
who_calls, where_used, schema_impact and globals_usage give the blast radius before an edit, across the whole estate rather than across the files someone thought to open. This is the step a person cannot do reliably over millions of lines, and its absence is why changes feel dangerous.
2 · Change the 4GL, in version control
The rules stay in the language they were written in, so nothing is re-derived and nothing has to be re-proven. The change is a commit — an author, a reason, a diff a colleague reviews and a history that can be bisected when a question arrives two years later.
3 · Build and test in one command
A Maven goal translates the estate, compiles it and runs the test suite in the same invocation, producing a versioned artifact. That is what lets a build server act on a commit automatically — the step that turns version control from a filing cabinet into continuous integration.
4 · Prove it compiles, without running it
compiles_check answers whether the generated Java actually builds, which translating it does not claim. It executes nothing, so it is safe against a program that writes to the database — the check to put in front of every commit.
5 · Prove it still behaves
run executes a program headless with scripted keystrokes, so a character-terminal application becomes something a build server can exercise — which it has never been in the life of most estates. Where equivalence has to be evidenced rather than assumed, a verification run puts the same report through the original 4GL toolchain and compares the two files. An identical report is the evidence that a translated ledger, invoice or statement is the same document.
6 · Review what the change introduced
review_program returns one ranked list: shared state a change has widened, a cursor left open, database work running with no error handling in force, a routine now too deep to review safely. The findings that would otherwise be met in production.
The same estate, before and after it can be asked
| A 4GL estate today | The same estate, answerable | |
|---|---|---|
| Scope of a migration | Estimated, then discovered during delivery | ✓ Measured before the budget is committed |
| Dead code | Suspected, never proven, maintained anyway | ✓ Listed, with what reaches it and what does not |
| Impact of a schema change | Found by reading, or found in production | ✓ Reported, including the declarations that name no column |
| Runtime dependencies to replace | Surfaced late, priced as a change request | ✓ Enumerated in the first survey, as a list |
| Where the risk sits | Known to the people who are retiring | ✓ Ranked by size and nesting depth, in writing |
| Applying AI to it | A pilot on text, producing answers nobody can sign | ✓ Answers computed by the compiler that builds it |
| Toolchain | Proprietary, single-vendor, shrinking talent market | ✓ Maven, JUnit, any IDE, any Java debugger, open source |
What this does to the lifecycle
The migration compiler produces Java that a developer is expected to read, review and take over. That choice is what makes the rest of the lifecycle available. The estate becomes an ordinary Maven project, built by an ordinary build server, tested with JUnit, opened in any IDE and stepped through in any Java debugger. Static analysis, dependency scanning, coverage and code review apply to it because it is Java, not because anything was written to support them.
The commercial consequence is the one a CEO cares about. Maintaining the estate stops requiring a scarce and shrinking skill and starts requiring the most widely held one in enterprise software. Nothing about the business rules changes — they are carried across mechanically, so nothing is re-derived and nothing has to be re-proven. What changes is the size of the market of people who can maintain them, and the cost of every future change.
None of this forces a moment of retirement. The 4GL can remain the source and be translated on every build, indefinitely. The Java can be taken over by hand. Both can run side by side for as long as a transition needs. The estate becoming answerable is what lets that choice be made on evidence rather than on nerve.
The questions a board asks before it funds anything.
In the order a chief executive and a chief information officer tend to ask them.
We have been advised for years that the answer is to replace this system. What has changed?
The estate can now be measured before the decision is taken, and extended without being replaced.
That advice was never wrong about the symptom. It was expensive about the cure. The accumulated rules — pricing, credit, despatch, period close — exist in no other written form, so a replacement programme has to express every one of them again in another language and then prove the new version behaves identically. That proof is the costly part, and it is where these programmes overrun.
Starting with measurement forecloses nothing. If replacement is right for your business, this turns it from an act of faith into a priced programme with a known scope.
What is the commercial case, stated plainly?
Maintaining the system stops depending on a scarce and shrinking skill and starts depending on the most widely held one in enterprise software.
The business rules are carried across mechanically rather than rewritten, so the expensive and risky part of a modernisation — re-deriving decades of logic and proving the result — is never purchased at all. What changes is the language the rules are written in, and therefore the market of people who can maintain them and the cost of every future change.
Before any of that, the measurement itself removes the largest single source of overspend in this class of work: committing budget before the scope is known.
We have already invested in AI. Why has none of it reached this system?
Because a general assistant reads your source as text, and Informix 4GL cannot be understood from its text alone.
The types are not in the program — they live in the database catalogue. A record declared to match a table owns every column without naming one. Much of an estate of this age is not even in the character set a modern reader assumes. An assistant working from the characters produces something fluent, plausible and impossible to verify, which is why this work stops at the demonstration.
What is different here is not the model. Your assistant asks the compiler that builds your application and reads back what it returns. The table above sets out the difference line by line.
If we act on these findings and they turn out to be wrong, who is accountable?
The findings are reproducible without us, which is the only basis on which that question has a good answer.
Every figure is computed by the compiler that produces your build rather than by a model forming an opinion, and any of them can be re-run from a command line by your own engineers with no assistant involved. Where the tools cannot read something they name it rather than omitting it, so a total is never quietly incomplete.
That is what lets your architects put their name to a number — the step at which most enterprise AI work stalls.
Does our intellectual property stay under our control?
Yes. The source never moves.
The tools read files on the machine they run on. What travels is the answer to a question — a list of call sites, a count of modules, a table's column types — and only as far as the assistant your organisation has already approved. Nothing is uploaded for indexing, and no copy of your estate exists anywhere but where it already is.
All but two of the tools only read. The two that write or execute are approved in the client before each call, so nothing runs against a database because software decided it should.
What does this ask of our own people, and what happens to the team that runs the system today?
It asks for their knowledge rather than their replacement, and it is the one option that does not devalue them on the day it is announced.
The engineers who know the 4GL remain the people who understand the business, because the business rules do not move. What the tools produce is the documentation nobody ever had time to write: what calls what, where the shared state is written, which routines are genuinely hard.
A declared rewrite creates a retention problem the moment it becomes public. Measuring and extending does the opposite.
How quickly would we see something, and what does it commit us to?
Days, and nothing.
An estate survey reads your 4GL source tree — no database connection required, nothing installed on a server, nothing uploaded — and returns a written picture of the estate as it stands : how much of it parses, how large it is, and how it is held together.
From there the work can be scoped accurately, sequenced by difficulty and delivered in increments that show value early. The evidence comes first; the decision stays yours.
What would tell us this is not the right answer for us?
If the application above the database is what limits the business, extending the estate will not fix that — and we will say so.
The measurement is the same either way, and it is what tells you which case you are in. Where the constraint really is the application tier, there is a forward path onto a modern runtime that preserves the schema and the business rules rather than re-deriving them. It is offered when the evidence supports it, not as the price of the first conversation.
Where to start
The entry point is the same one the whole 4GL section recommends, and for the same reason: it is the cheapest way to replace an assumption with a fact. An evaluation over your own source produces a written picture of what is there — how much of it reads, how it is held together, where the risk is concentrated and what a migration would have to supply. It commits the business to nothing that follows it.
The engineering detail behind every claim on this page — the protocol, the tool catalogue, the analysis, the two findings that were wrong before they were right, and the limits — is published in full in the compiler paper, under Asking the compiler about the estate. It is written for the architects who will be asked to review this before it reaches a budget decision — and it sits inside the compiler paper because this is a face of the compiler rather than a separate product.