Two regulated use cases taken off a 40-year mainframe COBOL estate and rebuilt in a modern Java/Spring platform, in about two weeks — with every rule proven against the mainframe before it shipped. 7× · Modeled
The client: a Fortune 50 transportation & logistics enterprise, running a Customs & Border Protection–facing estate on decades-old mainframe COBOL.
Engagement scope: two message-processing use cases — an outbound regulatory filing path and a three-stage inbound response chain. Critically, a modern Java/Spring target platform already existed — but the migration onto it had stalled at roughly 30% complete after 18 months of effort.
Both use cases forward-engineered from COBOL into the client's Java/Spring target and demoed in about two weeks — the first in roughly 48 hours — by a team of two. And it's engineered and evidenced, not generated and handed off.
GenAssist ingests both estates — the legacy being left and the target being built — into a digital twin the agent can interrogate. The work then runs as one repeatable loop: reverse-engineer the legacy's behavior, ground it in a source-anchored spec, forward-engineer traceable code, prove equivalence — and iterate. Click a phase.
The one decision that generates everything else. Drag the dial.
Intelligence accelerates discovery; source decides truth. No claim enters a
deliverable until it's checked against the actual code and given a file:line anchor.
This is what makes the velocity honest — you move fast because the grounding is cheap, not by skipping it.
Under standard agentic implementations, the same agent tends to write a feature, its test, and its equivalence report — so all three can share a blind spot. An independent, rule-by-rule conformance audit, run separately with the legacy source as the only oracle, breaks the circle.
The new services were built to slot into the client's existing platform rather than beside it — the same naming conventions, the same internal structure, and the same shared rule engine as the services already running there. The table below shows that fit, dimension by dimension.
| Dimension | What was checked | |
|---|---|---|
| Service naming & shape | New services follow the fleet's adapter-family naming and module layout | ✓ conforms |
| Package layout | Internal structure mirrors the standing adapters, package for package | ✓ conforms |
| Messaging & routing idiom | Same integration-routing framework and queue conventions as the fleet | ✓ conforms |
| Persistence idiom | Same ORM-based persistence pattern used adapter-locally across the fleet | ✓ conforms |
| Environment configuration | The fleet's three-profile configuration model, externalized identically | ✓ conforms |
| Shared rule engine | Reused, not forked — new rules join the existing engine's execution order | ✓ conforms |
| Error handling | The fleet's redelivery-then-dead-letter convention, so nothing is ever silently lost | ✓ conforms |
*-- main path: archive FIRST, then transmit --* 2100-ARCHIVE-FILING. MOVE WS-FILING-BODY TO ARCH-ROW-BODY MOVE 99 TO ARCH-SENTINEL-MAJ MOVE 99999 TO ARCH-SENTINEL-MIN EXEC SQL INSERT INTO ARCHIVE-STORE ... END-EXEC IF SQLCODE NOT = 0 PERFORM 9100-DB-RETRY-LADDER END-IF. 2200-TRANSMIT-FILING. PERFORM 2100-ARCHIVE-FILING CALL 'MQPUT' USING CUSTOMS-QUEUE WS-FILING-BODY.
@Transactional public FilingResult file(FilingMessage msg) { // archive FIRST — preserves the legacy ordering // guarantee: a filing is never lost in flight ArchiveRow row = archiveService .persist(msg, Sentinel.MAIN_PATH); customsPublisher.publish(msg.normalizedBody()); return FilingResult.filed(row.id()); } // publish failure → redelivery → dead-letter queue; // the archived row survives. Same guarantee, // modernized mechanism — disclosed as Modified.
One mainframe rule, followed end to end — from its COBOL source line to the verdict that proves it survived. Every one of the 55 rules carries a thread like this. Click any node to open it.
The delivered services were demoed live with an overlay showing every business rule firing — or deliberately holding back — as real messages flowed. This is that demo, re-created here so you can drive it: four scenarios, all of them real verified cases from the engagement. Pick one and run it.
States: fired — the rule executed · held back — the rule correctly chose not to act · idle — not on this message's path. The simulation is deterministic and runs entirely inside this page — no environment required.
The new services plug into the platform's existing shared regulatory rule engine — 181 rules across 13 agenda groups, run in a fixed execution order. The engagement's rules joined that order; the engine was not copied or modified. The jurisdiction spread below is the honest scope — this engagement's surface is the US slice, not the whole engine.
A modernization that ships only code has proven nothing durable. Each unit of work here shipped with its evidence — and a unit of work isn't done until its artifacts exist. The artifacts are what separate a verified modernization from a rewrite that merely looks correct.
~7×, roughly ~1,900 engineer-hours saved on this surface Modeled. The ~7× is a conservative figure: it credits only the behavior that was proven, and the manual comparator is a published industry benchmark rather than the client's timesheet. The client's own advance sizing of these two use cases — two to three months at a conventional delivery pace — points to the same order.
The engagement's realized rate — on the order of ~250–300 engineer-hours saved per 1,000 lines taken through the loop, roughly ~15 person-years per 100,000 lines — applied to inputs you control. Modeled · a decision aid, not a forecast.
An in-editor assistant answers "what's the next line of code?" Modernization asks harder questions: what does the mainframe actually do, did we keep it, and can we prove it? — questions that span two codebases and forty years of behavior locked between them.
The engagement runs a fixed shape — small, concrete, and de-risked by the loop itself. Week one is ingestion and behavior extraction: the phase where discovery time collapses.
Access, environment knowledge, and documentation become standing assets. Each subsequent module starts ahead of the last as the knowledge graph grows — the method compounds.
The delivered system was proven in a sandbox against real production payloads. Wiring it into the live production environment is a defined, scoped step in the production engagement.
That's the practice: modernization at agent speed, grounded so it survives an audit. Proven on a customs-grade estate — repeatable on yours.