The rewrite will cost three times what you approved
The claim The estimate for a full rewrite is derived from the features you can see. The cost is driven by the features you cannot — the eleven years of edge cases, exceptions and q...
The claim
The estimate for a full rewrite is derived from the features you can see. The cost is driven by the features you cannot — the eleven years of edge cases, exceptions and quiet workarounds embedded in the system nobody has read end to end. That gap is why rewrites routinely land at two to four times their approved budget, and why the version that ships is frequently worse than what it replaced.
Why the estimate is structurally wrong
Estimating a rewrite means estimating a specification that does not exist. Your current system's behaviour is not written down; it is encoded in code that has absorbed a decade of decisions. The tax exemption for one class of customer. The invoice numbering scheme required by an auditor in 2018. The nightly file drop to a supplier's ancient FTP server, which nobody mentions because it has worked for years and its author left in 2021.
None of these appear in the requirements workshop, because nobody in the room knows they exist. All of them appear in week nine, one at a time, each as a small change that turns out to be load-bearing.
There is a second, harder cost: while the rewrite is in progress, the old system still needs maintenance. You are paying two teams — or one team split — and the new system delivers no value at all until the switchover. A twelve-month rewrite is twelve months without a single improvement your customers can see.
The arithmetic to put on paper
| Line | Rewrite | Incremental replacement |
|---|---|---|
| Approved estimate | $220,000 | $220,000 |
| Realistic outcome | $440,000–$660,000 | $240,000–$300,000 |
| Time before any customer benefit | 10–18 months | 4–8 weeks |
| Cost of stopping halfway | Total loss | Keep what shipped |
| Legacy maintenance during the work | Full, in parallel | Declining |
The row that should decide the meeting is the fourth. Priorities change, a key person leaves, a customer emergency consumes a quarter. Under a rewrite, work stopped at month eight produces nothing at all. Under incremental replacement, everything shipped so far is already in production and already earning.
What incremental replacement actually looks like
Put a routing layer in front of the existing application. Every request goes to the old system by default; you move one route at a time to new code behind the same URLs.
location /reports/ { proxy_pass http://new_service; }
location / { proxy_pass http://legacy_app; }- Start with a read-only, high-visibility area. Reporting, search, or the public catalogue. No writes means no data-consistency problem while you learn the domain.
- Move writes one entity at a time, with the new service owning the table and the old system reading through an API or a view.
- Delete the old code path immediately once traffic has moved and a week has passed. If you do not delete it, you now maintain two implementations forever, which is the failure mode of this approach.
- Keep a single database as long as it is bearable. Splitting the data store is the expensive part; defer it until a specific problem forces it.
Characterisation tests come first
Before moving any route, write tests that capture what the current system does — not what the specification says it should do. Feed a hundred real historical inputs through the old code path, record the outputs, and assert on them. Where the behaviour is wrong, the test documents the wrongness, and someone can then decide deliberately whether to preserve or change it. This is the step that converts undocumented behaviour into something you can safely replace, and it is the single highest-value week of the whole engagement.
When a rewrite is genuinely correct
Three cases justify it. The platform is end-of-life and unpatchable, and no supported upgrade path exists. The system is small enough that a full rebuild is under roughly six weeks, in which case the coordination overhead of incrementalism is not worth it. Or the business rules themselves are being replaced — you are not rebuilding what exists, you are building something different, and the old behaviour is explicitly not the target.
The question to ask in the meeting
Ask the team proposing the rewrite to name the three most surprising behaviours in the current system. If they can, they have read the code and their estimate deserves weight. If the answer is that the current system is a mess and nobody really knows what it does, that is not an argument for rewriting it. That is a description of the risk you are about to fund.
