Anyone can rewrite it. We prove it behaves the same.
Independent proof, field by field, that your new system behaves like the old one. Whoever wrote it, including AI. Evidence your auditor can replay.
COBOL · CICS · VSAM · IMS · HLASM · PL/I · JCL · Db2
Oracle · PostgreSQL · AlloyDB · SAP ASE · and the applications that sit on them.
The candidate produced no output. Most tools would report this as a pass.
We return indeterminate, because nothing was verified.
Your team, our team, an AI. The standard does not move.
So we tested that on ourselves. We pointed the platform at a 1.4 million line ERP maintained on both Oracle and PostgreSQL, and asked it to work out the rules that translate one to the other — once with conventional analysis, once with AI agents.
The AI returned fourteen rules in a single response. One of them corrected 367 files. Another corrupted 86. A third matched nothing at all. Same response, same format, same confidence.
367 files corrected
Its best rule fired on 373 files and improved 367 of them. Exactly what you want from an AI writing your migration.
86 files corrupted
Its worst rule fired on 97 and damaged 86. Well-formed, plausible, and wrong in a way no reviewer catches by reading it.
Both caught
Not by being smarter than the AI. By running every proposed change against the real system and refusing the ones that made things worse.
This is why we are indifferent to who writes the code. Generation is cheap and getting cheaper. Telling a good change from a convincing one is the part that still has to be proved — and it is not something you can ask the writer to do for itself.
AI agents do the conversion. A fixed program decides when it's done.
Lightyear's factory turns a legacy program into modern code with AI agents, then runs the old and new versions on the same data. Nothing is finished until the Verdict Engine, a deterministic program rather than a model, says the results match and the tests were strong enough to trust that match.
Scope the job
Works from a map of your estate: what the program reads and writes, which business rules it carries, and what "the same" means. The rules are locked before any code is written.
Write the new code
Writes the replacement in a sealed workspace, with a fixed budget of attempts. It never sees the expected answers.
Compare every field
Runs old and new on the same inputs and compares every field. The answer key is the legacy program itself, run for real, not someone's description of it.
Fix it, or stop honestly
Differences go back to the builder by field name, never with the right value. When the budget is spent, the run stops and the failure is kept as evidence.
People decide what machines shouldn't
The factory does the repetitive work on its own. The decisions that carry risk stay with a named person, and each one is signed and kept with the evidence.
One business process, run on Oracle and PostgreSQL. The whole run is public and replayable.
One field fails. The builder fixes it. The judge decides.
Here is stations 2 to 4 in motion. The judge reports which field differs, the builder AI repairs its own code, and the second run passes. Because the Verdict Engine is a fixed program, every verdict replays the same way.
One judge for every technology you are leaving behind.
Mainframe, Oracle, Db2, Sybase or the services on top of them: every modernization comes down to the same inputs, run through the old system and the new one, compared and signed. We publish exactly which platforms our judge is qualified on, and the evidence behind each one.
See the coverage catalogueBuilt for the people who have to sign off
A regulated business can't take a vendor's word for it, or an AI's. So the controls are part of the product, not a promise on a slide.
Runs in your cloud
Lightyear runs inside your environment and only reads. Nothing is ever written back to your legacy estate.
The AI never sees the answers
Expected results stay with the judge. The AI that builds the code is told which field differs, never the right value.
Evidence anyone can replay
Every verdict is signed. Your auditor can replay it offline, months later, without us in the room.
Security pack on request
Architecture, data flows, access control and retention, written for your security review before the first capture.
Howard Weale
Howard led the mainframe practice at Google Cloud and brought Dual Run to market: Google Cloud's way of running a mainframe and its replacement side by side and comparing the results. Lightyear takes that idea further, with a comparison that is independent, field by field, and replayable by anyone.
One process. Four weeks. A verdict you can take to the committee.
The Verification Sprint is the way in. We take one batch job or business process, run the original and the replacement on the same inputs, and hand you signed evidence of where they agree and where they don't.
At the end you know whether the replacement behaves the same, what it would take to get there, and how much of your system nobody has ever tested. Then you decide what comes next.
Verification Sprint
- One batch job or business process, verified against the system it replaces: a replacement you already have, or one our factory builds during the sprint
- Every difference named, field by field, with its cause
- Your risk number: how much of that process's logic no test you own has ever exercised
- A signed evidence pack your auditor can replay offline
- Read-only, inside your cloud, from day one
Judge the evidence first
Look at a real evidence pack, or send us one job and get a signed verdict back. No call needed.