Rewrites do not usually fail in the way people expect. The new stack is generally fine and the team is generally competent. What kills the program is structural: a scope defined by the old system's feature list, business rules nobody can produce on request, and an organization whose attention runs out long before its funding does.
Rewrites fail for organizational reasons, not technical ones
When a rewrite is written up afterward, the story is usually technical. The framework was a poor fit. The data model fought us. Those are consequences. The decision that determined the outcome was made much earlier, when someone agreed that the new system would do everything the old one did and would be evaluated only when that was true. That agreement sets a finish line two years out, removes any interim moment where the business can judge progress against something other than a burndown chart, and puts the program's entire value at the end, exactly where organizational attention is weakest.
The failure modes inside the software
Rebuilding the feature list instead of the business capability
The fastest way to scope a rewrite is to inventory the old system's screens and rebuild them. It is also the most expensive, because a fifteen-year-old system contains a great deal of accumulated accident: screens built for one customer, workflows shaped around a constraint that no longer exists, reports that three people ran once. Rebuilding them faithfully carries the old system's mistakes forward at full price.
Early signal: the requirements artifact is a screen-by-screen mapping of the old system, and nobody can state what the business does in terms independent of the current software. Countermeasure: define the domain first (work orders, inventory, dispatch, invoicing) and make each capability the unit of scope, delivery, and cutover. Then ask, per screen, which capability it serves. Many serve none.
The rules nobody can enumerate
Every long-lived operational system holds rules that exist only in code, often in one conditional inside one method. A pricing exception for a customer acquired in an old deal. A status transition that is illegal on the last day of the month. These were never documented because nobody knew they were decisions. Interviews will not recover them: the people who could describe them left, and the people who remain have internalized the behavior as how things work.
Early signal: discovery produces a clean, tidy rule set everyone agrees with quickly. Real domains are not tidy; fast unanimity means the hard cases have not been raised. Countermeasure: treat the legacy code and production database as primary sources rather than the interviews, then run the new implementation against real historical transactions and compare outputs. Differences are either new-system bugs or rules nobody knew existed, and both are worth finding before a customer does.
The feature-parity trap
Parity is an appealing finish line because it is easy to explain and appears safe. It is neither. It guarantees a long stretch with no delivered value, hides the new system's advantages until the end, and forces the team to rebuild functionality the business would have dropped if anyone had asked. It is also a moving target: the legacy system keeps changing while you chase it.
Early signal: progress is reported as a percentage of the old system rebuilt. Countermeasure: replace parity with capability-level sufficiency. A capability moves when the new implementation handles that capability's volume, edge cases, and users well enough to run the business, not when every legacy field has a new home. Some legacy behavior should be retired deliberately, with a recorded decision, rather than reimplemented by default.
The failure modes inside the organization
The two-team split that starves the legacy system
A common structure puts the strongest engineers on the new platform and leaves a smaller group to keep the old one running. The effect is that the system the business actually depends on stops receiving investment, and the people maintaining it understand that their work is scheduled for deletion. Attrition follows, and the institutional knowledge you needed most walks out mid-rewrite.
Early signal: legacy-side hiring is frozen, or maintenance is deferred with the phrase "that gets fixed in the new system." Countermeasure: keep one team accountable for the business outcome across both systems, rotate people between them, and fund legacy maintenance well enough to keep it stable for the full transition.
Funding that outlasts attention
Budgets are approved annually; executive attention is not. A rewrite funded for two years typically holds senior interest for two or three quarters, after which the sponsor is absorbed by something newer. The program is not cancelled. It is ignored, and decisions that need an executive stop being made, so the team resolves them by guessing.
Early signal: the steering meeting is rescheduled twice, then becomes a written status update. Countermeasure: structure the program so it produces something the sponsor can see in production every six to eight weeks. Attention follows visible change. A program that only reports progress will lose the argument to any program that ships.
Eighty percent done for eighteen months
The mechanism behind the industry's most recognizable pattern is simple. The first eighty percent is well-understood functionality, estimated confidently and delivered roughly on time. The last twenty percent is everything deferred: historical data migration, permissions, reporting, the integrations nobody owns, the edge cases found in testing. That remainder is frequently larger than the eighty percent.
Early signal: the completion percentage stops moving while the team is visibly busy. Countermeasure: pull the hard twenty percent forward. Migrate real data in week two, not month fourteen. Build permissions and multi-entity scoping into the first capability, because they touch every query and every screen and cannot be retrofitted cheaply. If the first slice includes the genuinely hard parts, the estimate for the rest means something.
The rewrite as a proxy for a leadership disagreement
Sometimes the rewrite is not about the software. Two executives disagree about product direction, customer segment, or who owns the roadmap, and a rewrite is the one initiative both can endorse without resolving it. Engineering then takes contradictory requirements from equally legitimate authorities and rebuilds the ambiguity into the new architecture, which becomes as hard to change as the old one. Our own industry is complicit here: this work is easy to sell and comfortable to staff, and the honest response is to decline it.
Early signal: two stakeholders describe the purpose of the rewrite in ways that cannot both be true, and neither will arbitrate. Countermeasure: refuse to start the build. Run a short assessment that forces the strategic question into the open and produces a written decision on scope and ownership. Without it the rewrite fails regardless of who builds it, and saying so is more useful than taking the work.
Failure modes at a glance
| Failure mode | Early signal | Countermeasure |
|---|---|---|
| Rebuilding the feature list | Requirements are a screen-by-screen map of the old system | Scope by business capability; audit which screens serve none |
| Undocumented rules | Discovery produces a tidy rule set everyone agrees with quickly | Treat legacy code and production data as the source; replay historical transactions |
| The feature-parity trap | Progress is reported as percent of the old system rebuilt | Set capability-level sufficiency as the bar; retire behavior deliberately |
| Two-team split | Legacy fixes deferred to "the new system"; legacy hiring frozen | One accountable team across both systems; fund legacy maintenance throughout |
| Funding outlasts attention | Steering meetings become written status updates | Ship something visible in production every six to eight weeks |
| Eighty percent for eighteen months | Completion percentage stalls while the team stays busy | Pull migration, permissions, and reporting into the first slice |
| Proxy for a leadership disagreement | Two stakeholders give incompatible reasons for the rewrite | Do not build; run an assessment that forces a written decision |
What the version that works looks like
The rewrites that finish share a shape. The new system runs alongside the old one rather than replacing it on a date. Data compatibility is preserved so both operate against a shared source of truth. Capabilities move in prioritized slices, each validated with real usage before the next begins. Every cutover has a fallback, so the worst outcome of a bad slice is a reverted slice rather than a stopped business.
Real businesses use the platform every day, so a big-bang rewrite was never acceptable. The new product was built alongside the old one, preserving data compatibility and shifting workflows incrementally with a clear fallback path at each stage.
This is slower per capability and faster overall, because the expensive discoveries happen while they are still cheap to act on. In a coexistence migration a wrong assumption costs one slice; in a big-bang cutover it surfaces on go-live weekend with every customer watching.
When not to rewrite
Some systems should not be rewritten, and the honest answer is to say so. If the complaints are about the interface and the cost of change is acceptable, you have a front-end problem. If the pain sits in two or three modules, extract those and leave the rest alone. If nobody can say what the business will be able to do afterward that it cannot do now, a rewrite will cost a great deal to prove the answer is nothing.
The test we apply is the cost curve. In a healthy system, features get cheaper to add as the infrastructure matures. When they get consistently more expensive (a change that took a week two years ago now takes a month, and each release carries more risk), that curve is the argument for a rebuild. Anything less specific is dissatisfaction, and dissatisfaction is not a business case.
Checks that keep a rewrite honest
- 1
Name the first capability to move and the date it goes live with real users. If that date is more than three months out, the plan is too coarse.
- 2
Migrate real production data before building the second capability, and reconcile the results against legacy output.
- 3
Write down which legacy behaviors are being retired on purpose, and have that list signed by someone who can defend it later.
- 4
Hold a standing review that asks one question: what reached production since we last met? Treat two consecutive empty answers as an escalation.
- 5
Fund legacy maintenance through the end of the transition, and staff it with people who are not waiting for the project to delete their job.
Common questions
- Is it ever right to do a big-bang cutover?
- Occasionally, when the system is small, the user base is internal, and the business can tolerate a bad weekend. Above that threshold the risk compounds quickly, because every deferred discovery arrives at the same moment. For an operational system that customers or field staff depend on daily, coexistence is worth the additional cost of running two systems.
- How long should a rewrite take?
- The wrong question, because the total duration is not something you control up front. What you control is when the first capability reaches production, and that should be measured in weeks. A program with an eighteen-month first delivery has already accepted every failure mode on this page.
- How do we find the business rules nobody remembers?
- Read the code and the data, not just the documentation and the interviews. Then run the new implementation against a large sample of historical transactions and compare the outputs field by field. Every discrepancy is either a defect or an undocumented rule, and the exercise typically surfaces more of the latter than anyone expects.
- Should we keep adding features to the legacy system during a rewrite?
- Yes, for anything the business genuinely needs before the relevant capability has moved. Freezing the legacy system is a common instinct and it usually backfires: the business routes around the freeze with manual process and spreadsheets, which creates a second undocumented system you will also have to migrate.
- What does a rewrite proposal look like when the vendor is being straight with you?
- It names the first capability, the date it ships, and the assumption that would break the estimate. It includes data migration in the early phases rather than at the end, and it says which legacy behaviors will not be rebuilt. If a proposal promises feature parity on a fixed date before anyone has read the legacy code, it is priced on a guess.
- Our rewrite is already stalled. What now?
- Stop adding scope and find one capability that can reach production within a quarter, even a small one. Restoring a delivery cadence is the only thing that rebuilds sponsor attention, and sponsor attention is what unblocks the decisions that are usually the real cause of the stall. If the underlying problem is an unresolved disagreement about direction, no amount of engineering will fix it.