Everyone knows rewrites take longer than planned. What kills them is the thing nobody budgets for: the six months of dual-maintenance while the old system keeps paying the bills.
Every rewrite starts with the same sentence, delivered with the same earnest confidence: "It will take six months." We have sat in that room maybe forty times. We have said that sentence ourselves. The rewrite always takes longer. That part is not the interesting part.
The interesting part is what happens in the gap. For the entire duration of the new build, the old system is still running. It is still handling payments, still issuing credentials, still being patched on Fridays at four in the afternoon when something goes wrong. Nobody budgets for that. It does not appear on the Gantt chart. But it consumes roughly half of whatever engineering capacity you thought you had.
The dual-maintenance tax
We call it the dual-maintenance tax, and in our experience it runs between forty and sixty percent of your total engineering payroll for the life of the rewrite. If the rewrite is "six months" (which means eleven), and you have ten engineers, you are spending the equivalent of four or five full-time engineers maintaining the thing you are explicitly trying to replace. That number is almost never in the plan.
"The rewrite is not expensive because the rewrite is hard. The rewrite is expensive because the old system refuses to stop being a business."
The worst version of this is the rewrite that ships in pieces. You launch the new auth service alongside the old one. Now you have two auth services, both of them real, both of them receiving traffic, both of them needing security patches. Every bug you fix in production, you have to decide whether to backport. Every feature you launch, you launch twice.
What we do instead
When a client comes to us with a rewrite request, the first thing we do is try to talk them out of it. Not because rewrites are bad — sometimes they are the only option — but because the honest conversation about what a rewrite actually costs rarely happens until a consultant is already six months in. We prefer to have it on day one.
The second thing we do, if the rewrite is still the right call, is write down the dual-maintenance budget explicitly. A line item. A headcount. A named owner. Because if nobody owns it, everybody does, and that is how you lose your best engineers to a year of stabilization work they did not sign up for.
The third thing we do is make a ruthless decision about what does not get rewritten. The billing subsystem from 2017 that handles three million dollars a quarter and has not changed in two years? That stays. The admin panel nobody uses? Delete it entirely. Scope is the single biggest variable in rewrite cost, and scope is the thing teams are least honest about.
None of this is novel. All of it is hard to do when the pressure from the board is "ship the new thing." But the math is unforgiving, and the math is the thing we keep coming back to. A rewrite is a two-system engagement, and the cost of the system you are keeping alive is usually the cost that kills the project.