Why your legacy rewrite keeps getting cancelled

The pattern is remarkably consistent. A critical system is twenty years old. Engineering proposes a rewrite. Finance asks what it costs and when it delivers. The answer is eighteen months and several million dollars, with essentially no value delivered until the end. The proposal dies. Two years later someone proposes it again.

Engineering usually reads this as executives lacking appetite. It is more accurate to say executives are correctly pricing an asymmetric bet: enormous downside concentrated on a single date, upside that arrives only if everything goes right, and no way to stop partway once committed. Nobody should approve that. The right response is not a better business case; it is a different risk profile.

It is worth saying plainly how normal this is. The U.S. Government Accountability Office reviewed 65 federal legacy systems and singled out the ten most critical: they ranged from 8 to 51 years old, several running COBOL on hardware the manufacturer no longer supports, and one carried 168 high or critical security vulnerabilities. Of roughly $90 billion in annual federal IT spending, about 80% goes to operating and maintaining what already exists. Eight of those ten agencies had no complete modernization plan, which GAO tied directly to cost overruns, schedule delays and outright failure.

If the largest IT buyer in the world cannot make the big-bang version work reliably, the problem is not local to your organization and it is not going to be solved by a more persuasive deck.

The big-bang problem¶

A big-bang replacement asks the organization to run two systems in development for a long time, then switch on one day. Three things reliably go wrong.

• The old system keeps changing. Regulation moves, customers demand things, bugs get fixed. Your replacement is aiming at a target that will not hold still, and every change must now be made twice.
• Nobody knows what the old system does. The requirements were never written down and the people who knew have left. What gets rebuilt is what someone remembers, which is a subset, and the missing part surfaces at cutover.
• Cutover is unrehearsable. Data migration at full volume, under real load, with real edge cases, happens for the first time on the night it matters.

Change the shape, not the ambition¶

The strangler-fig pattern, named by Martin Fowler after the vine that grows around a tree until the tree is gone, replaces the single date with a long series of small, reversible ones. You put a routing layer in front of the legacy system, then move functionality behind it one capability at a time. Fowler’s argument for it is the one executives are already making: replacing a serious system takes a long time, users cannot wait that long for new features, and much of the existing behaviour is hard to pin down in the first place.

Each slice is independently valuable, independently deployable and independently reversible. If slice seven goes badly, you roll back slice seven on a Tuesday afternoon. The legacy footprint shrinks continuously, and the project can be paused at any point without leaving the organization stranded between two half-systems.

The four things that make it work¶

1. Archaeology before architecture¶

Before designing anything, produce a truthful map of what exists: which programs actually execute, which tables are genuinely read, which jobs are load-bearing. On a recent state-agency engagement, 31% of the codebase had not run in over a year. You do not migrate that. You delete it, and the project gets a third smaller before it starts.

2. Characterization tests¶

Undocumented systems need a test suite that captures what they currently do, including the bugs the business has quietly come to rely on. Michael Feathers called these characterization tests, and they are the single highest-leverage artifact in a modernization. They convert 'we think it works like this' into a fact that fails loudly when violated.

3. An anti-corruption layer¶

Legacy data models encode decades of accumulated compromise. If new components speak that model directly, you have not modernized anything; you have re-expressed the old system in a newer language. An anti-corruption layer is the translation boundary that keeps the legacy shape from propagating into the replacement. Decide early whether it is permanent or gets retired once migration completes, because that answer changes how much you should invest in it.

4. Reconciliation as a first-class deliverable¶

During transition both systems hold data. Automated reconciliation (comparing record by record, nightly, with discrepancies raised to a named owner) is what lets you cut over on evidence rather than on hope. It is also what lets you say yes when someone asks whether the numbers still match.

What it costs you¶

Incremental migration is not free relative to a rewrite that goes perfectly. You maintain a routing layer, you sometimes write adapter code that gets deleted later, and total engineering effort is often modestly higher. You are buying optionality, and optionality has a price.

It is a price worth paying, because the alternative isn’t a rewrite that goes perfectly. The alternative is the third cancelled proposal, and another two years on a system nobody can change.