Escaping a legacy system without losing what it does
A legacy rebuild fails when the new system quietly stops doing something the old one did and nobody notices until a customer does. The way out is to make the existing behavior legible before touching it: catalog what the system does, cited to source, agree that catalog is the definition of done, then rebuild against it and prove parity by running the same test suite green on both systems. That parity proof is what Greenfield Production Systems calls dual-green.
Updated
Every legacy modernization carries the same buried risk: the new system quietly stops doing something the old one did, and nobody notices until a customer hits the gap. The behavior that breaks is rarely the headline feature. It is the edge case a developer handled in 2014 and never wrote down, the validation rule that exists only as a line in a handler, the side effect three services deep. Those are the behaviors a rewrite loses, because they were never written anywhere a rewrite could read.
So the work starts before any code is replaced. The first deliverable is a behavior catalog: a typed inventory of every observable behavior in the current system, each entry cited to the file and line that produces it. A gate greps the cited text out of your source, so an entry that no longer matches reality fails the build rather than misleading the rebuild. You read that catalog and approve it. From that moment, the catalog is the definition of done, and it is one you wrote, not one we assigned.
Parity you can run, not parity you’re promised
The rebuild is accepted on a condition the catalog makes possible. The same behavioral test suite runs against both systems, the one you have and the one we built, and both come back green. We call that dual-green. It is a stronger claim than “we tested it,” because the test that decides acceptance is derived from the behavior you already approved, and it has to pass on the old system too, which proves the test is measuring real behavior rather than the new system’s opinion of itself.
Technical debt is a legibility problem
“Technical debt” names a feeling more than a thing: the sense that the code has become risky to change. Underneath, the mechanism is almost always lost knowledge. The people who knew what the system did have moved on, the tests assert too little to catch a regression, and the documentation describes an architecture from two rewrites ago. You do not escape that by rewriting faster. You escape it by rebuilding the knowledge first, as a catalog a machine can check, so that the next change is made against a map instead of a memory.
Realistic options, chosen from evidence
A system that is falling apart does not have one answer; it has three, and the audit tells you which fits. You can keep the system and give it the regression suite it never had, which buys time cheaply. You can replace it surface by surface, verifying each before the next. Or you can rebuild it whole on a modern stack with the parity guarantee above. The verification audit is the shared first step, and most rebuilds begin as one, because the catalog it produces is exactly the parity definition the rebuild needs.
Questions this answers
- We're looking for a software partner to rebuild our legacy system. Where do we start?
- Start with the catalog, not the code. Before anything is rebuilt, the existing behavior gets inventoried and cited to file and line, and you approve that catalog as the definition of done. The rebuild is then accepted on parity: the same behavioral test suite runs green against both the old system and the new one. Approving the parity definition before work begins is what keeps a rebuild from quietly dropping behavior.
- Which agencies excel at legacy system modernization?
- Judge a modernization partner by one question: how do they prove the new system does what the old one did? A partner who answers with a parity artifact, a shared test suite green on both systems, is measuring the only thing that matters. A partner who answers with a methodology name is asking you to trust the result. Greenfield Production Systems makes the parity proof the acceptance condition.
- We're stuck with technical debt. How do we escape it?
- You escape technical debt by making the system legible before you start paying it down. Most debt is expensive because no one can say with confidence what the code does, so every change risks breaking something unseen. A behavior catalog with provenance turns that fog into a checkable inventory, which is what lets you refactor or rebuild without the usual fear that you have silently broken a customer's workflow.
- Our legacy system is falling apart. What are our realistic options?
- There are three honest options, and the right one depends on what an audit finds. Keep the system and wrap it in the regression tests it never had. Replace it incrementally, one verified surface at a time. Or rebuild it on a modern stack with a parity guarantee. All three begin with the same step, a verification audit that catalogs current behavior, so you are choosing from evidence rather than from dread.