Case study · Under contract Confidential
Legacy modernization
without rewrite risk
A mission-critical platform producing high-stakes, legally binding documents in a highly regulated, security-intensive domain.
The system worked and could not be replaced. It was also slow, fragile, and increasingly expensive to change. This is how the modern tier went in without the business ever having to bet on a rewrite.
Legacy modernization without rewrite risk
Replace one tier at a time. Prove the new output is byte-for-byte identical. Keep the old engine as the guarantee.
Before — the legacy pipeline
slow, fragile, hard to change — but its output is the legal record of truth
After — the modern tier
-
New API tier
Modern framework. Owns field mapping, auth, orchestration.
-
Warm Lambda render tier
Reuses the legacy engine’s own core library — so it produces the exact same bytes, not a lookalike.
-
Same finished document
Written to storage, served via short-lived URL.
-
Proven identical
Old and new run side by side; output compared byte-for-byte before the old tier is retired.
Meanwhile — the two systems coexist
The new API is engineered to run against both the legacy and modern databases, so migration happens incrementally and safely — no big-bang cutover, no day where everything has to work at once. The legacy engine stays available as the fallback and the proof.
This is the strangler-fig pattern: grow the new system around the old one, tier by tier, until the old one can be quietly removed.
Every company with a legacy system fears the rewrite. This is the alternative — modernization the business never has to bet on.
The constraint that shaped everything
The documents this platform produces are legally binding. Their layout is not a design preference — it is the record. A field that moves a few points, spacing that renders differently, a font substituted by a newer library: any of these is a defect, and potentially an invalid document.
That single fact rules out the normal modernization playbook. You cannot rewrite the generator with a modern library and verify it by looking at the output, because “looks right” is not the standard. Nor can you accept output that is merely equivalent. It has to be identical, and you have to be able to prove it.
Reuse the engine, replace the tier
The insight that made this tractable: the risky part was never the old engine — it was everything wrapped around it. The engine produced correct output. What made the system painful was the aging orchestration layer, the interpreted script gluing it together, and the absence of any modern interface to it.
So the new render tier does not reimplement the document generation. It runs the legacy engine's own core library inside a warm Java Lambda. Same library, same rendering decisions, same bytes — invoked by a modern API tier that owns field mapping, authentication, and orchestration, and writes results to storage behind short-lived URLs.
The old and new tiers ran side by side and their output was compared byte-for-byte before the old one was retired. Not sampled, not eyeballed — compared. When identical output is the requirement, the proof has to be mechanical.
No day where everything has to work at once
The second risk in any modernization is the cutover — the release where the new system takes over and everyone finds out together whether it was ready.
The new API tier was engineered from the start to run against both the legacy and the modern database, selectable per job. That one design decision turns a big-bang cutover into an incremental migration: work moves across a piece at a time, each piece verifiable on its own, and the legacy path stays available underneath the whole time — as the fallback, and as the thing new output is checked against.
This is the strangler-fig pattern: grow the new system around the old one, tier by tier, until the old one can be quietly removed.
Every company carrying a legacy system knows the rewrite conversation, and knows how those usually end — over budget, over schedule, and with a period where the new system is worse than the one it replaced. This is the alternative. The business kept running on software that already worked, while the parts that hurt were replaced underneath it, one at a time, each proven before the previous one was switched off.
This work is under NDA, so the details here stay general. I'm glad to walk through the architecture in more depth on a call.