Every platform team has the meeting. Someone says the codebase is slowing them down, someone else says the word 'rewrite,' and the room splits into two camps: the people who are tired of the old system and the people who are afraid of the new one. The decision usually goes to whoever argues loudest. That's the trap — the rewrite question is an engineering measurement problem, and it gets answered as a political one.
Rewrites are seductive because greenfield feels fast. You picture the clean architecture, the tidy module boundaries, the tests you'll definitely write this time. What you forget is that the old system isn't just code — it's hundreds of edge-case fixes, each one a bug a real customer reported and a real engineer patched. A rewrite has to rediscover all of those, in production, while the business waits for features it's not getting.
So before we let anyone say the r-word in an audit, we look at four numbers. Deploy frequency — are you shipping weekly or monthly? Change failure rate — how often does a deploy send you scrambling? Time-to-first-feature for a new hire — two days or two months? And code ownership — what percentage of the hot paths were written by people who still work here? Those four numbers tell you more about the health of a system than any architecture diagram ever will.
Here's the rule of thumb we give clients: if you can name the architectural boundary that's wrong, refactor behind it. Bad data layer, fine — wall it off and replace it piece by piece. If the problem is that nobody can name the boundaries at all, a rewrite won't save you either. It will just re-randomize the mess with newer dependencies, and you'll be back in the same meeting in three years.
There are exactly three situations where a full rewrite is the right call. The platform itself is abandoned — framework end-of-life, dependencies nobody maintains, a runtime you can't hire for. Or the business changed so fundamentally that the data model doesn't describe reality anymore. Or you're an order of magnitude past the scale the architecture was designed around, and every fix is load-bearing duct tape. If none of those are true, you're not looking at a rewrite. You're looking at a refactor with better marketing.
The middle path most teams miss is the strangler pattern. You don't replace the system — you grow the new one around it. New capabilities go into the new service, traffic migrates route by route, and the old system shrinks until somebody notices one day that it hasn't been deployed in months. It is deeply unheroic work. It's also how almost every successful 'rewrite' we've shipped actually happened.
This is most of what a technical audit is, honestly. Two weeks inside the codebase, scoring it against these dimensions, talking to the people who have to live in it. The deliverable is never 'rewrite' or 'don't rewrite' — it's a sequenced plan. Sometimes that's 'rewrite the billing service, keep everything else.' Sometimes it's 'no rewrite, you need tests around the three files everyone is afraid of.' The plan is different every time. The framework isn't.
The honest answer to 'should we rewrite' is almost always: less than you think, sooner than you think. Small, continuous replacement beats heroic replacement every single time we've measured it. And if you're staring at this decision right now and want a second set of eyes — that's literally what our audits are for. Two weeks, and the meeting gets a lot shorter.
