Why "just rewrite it from scratch" usually backfires
When a system feels old, slow, or painful to change, the instinct is to scrap it and build something new. It sounds clean. In practice, it's one of the riskiest moves a team can make.
A full rewrite forces a choice nobody likes. Either you run two systems in parallel for months while the new one catches up feature for feature, doubling your maintenance load the whole time. Or you pick a cutover date, flip the switch, and hope the new system handles everything the old one did on day one.
Neither option is comfortable, and the second one is genuinely dangerous. Old systems accumulate business logic nobody consciously designed. Someone fixed a tax-calculation edge case in 2019 and never wrote it down. Someone added a special rule for one large customer's odd invoicing format. A rewrite team, working from what the system is supposed to do rather than what it actually does, will miss dozens of these. They only surface once the new system is live and something breaks in production.
There's also a cost problem that rarely gets budgeted honestly. A rewrite has to reach full feature parity with the old system before it can fully replace it, and "full parity" for a system that's been running for years is a much bigger target than most estimates account for. Timelines slip, the parallel-running period stretches from months into a year or more, and the business ends up paying for two systems at once for far longer than planned.
That's why most experienced engineering teams treat "rewrite from scratch" as a last resort, not a first move. If you're weighing that decision for your own systems, it's worth talking it through with a team that has done this kind of software modernization work before committing to either path.
The real risk isn't the old code, it's the undocumented knowledge inside it
It's tempting to treat the age of a codebase as the problem. It usually isn't. Old code that has been running in production for a decade has, by definition, survived a decade of real-world edge cases. Every one of those survivals taught the system something, even if nobody wrote it down anywhere.
That knowledge lives in strange-looking conditionals, in comments that say "don't touch this," in one engineer's memory of why a report runs at 2am instead of 9am. None of it shows up in a requirements document. All of it shows up the moment you remove it.
The old code isn't the risk. Losing the business rules buried inside it, without realizing they were there, is the actual risk.
This is the real argument against a big-bang rewrite. It's not that new code is worse than old code. It's that a rewrite throws away the accumulated, undocumented knowledge all at once, and you don't find out what you lost until a customer complains or a report comes out wrong.
Picture a billing system that quietly rounds a specific fee down instead of up for one legacy contract type, because a customer complained about it years ago and someone patched it. Nobody wrote a ticket. Nobody put it in the spec. A rewrite built from the official requirements document will get the math "correct" and technically wrong, and the first sign of trouble will be an angry email from that customer's finance team.
Multiply that one example by however many years the system has been in production, and it becomes clear why "just rebuild it properly" underestimates the job every time. The goal of modernization isn't to erase the old system's quirks. It's to carry the ones that matter forward while cleaning up the ones that don't.
A practical modernization roadmap
A safer approach treats modernization as a series of small, verifiable steps rather than one large leap. In practice, that looks like this:
- Map what the system actually does today. Not what the documentation says, what it actually does, edge cases included. Talk to the people who support it and watch how it's really used.
- Identify the highest-risk or highest-cost part to modernize first. This is rarely the oldest-looking part of the system. Look for the piece causing the most bugs, the most support tickets, or the most fear whenever someone has to touch it.
- Build the new piece alongside the old one. Don't replace the whole system at once. Build the replacement component so it can run next to the original without disturbing it.
- Route a small, safe slice of real traffic to the new piece. Start with a low-stakes segment, like one internal team or a small percentage of requests, and compare its output against the old system's.
- Gradually expand until the old piece can be retired. Increase the share of traffic going to the new component as confidence grows, keeping the old path available as a fallback until it isn't needed.
- Repeat for the next piece. Once one component is fully modernized and the old version is switched off, move to the next highest-priority piece and start the cycle again.
Each step is small enough to reverse if something goes wrong, and none of them requires the business to stop running while it happens. A phase is "done" when the new piece has handled real production traffic for long enough that the team trusts it more than the old one, not when a calendar date arrives.
That last point matters more than it sounds. Teams under deadline pressure are tempted to declare victory early and switch everything over at once. Resist that. The whole value of this roadmap comes from verifying each slice before expanding it, and skipping that step just recreates the big-bang rewrite risk one component at a time.
The strangler pattern, in plain terms
The roadmap above is often called the "strangler fig" pattern, named after a vine that grows around a host tree, gradually taking over its structure, until the original tree is no longer needed.
Applied to software, new components grow up around the edges of the old system. Traffic gets routed to each new piece one at a time, verified, and expanded. The old system keeps doing everything it hasn't been replaced for yet. Nothing gets torn out until its replacement has already proven it works.
- No single risky cutover date the whole business depends on.
- Each piece is validated with real traffic before the old version disappears.
- If a new piece has a problem, traffic can be routed back to the old one while it's fixed.
- The old system eventually shrinks down to nothing and can be retired entirely.
It takes longer, calendar-wise, than a single rewrite project. But it removes the all-or-nothing bet that makes big-bang rewrites so risky in the first place.
A common way to implement this in practice is to put a routing layer, like an API gateway or a feature flag, in front of the functionality being replaced. That layer decides, request by request, whether traffic goes to the old system or the new component. Widening or narrowing that split is a configuration change, not a redeployment, which is what makes gradual rollout and instant rollback both possible.
What to modernize first
Teams often default to modernizing whatever looks oldest. That's usually the wrong starting point. The better question is which piece is both business-critical and the hardest to maintain.
- It causes frequent bugs. If a component keeps breaking or needing patches, it's costing the team time every month it stays as-is.
- Only one person understands it. A single point of failure in institutional knowledge is a bigger risk than old syntax.
- It blocks other work. If new features keep getting delayed because they touch this one fragile part of the system, it's actively slowing the business down right now.
A piece of code can be twenty years old and cause zero problems, in which case it can wait. Meanwhile a five-year-old component that three teams depend on and nobody wants to touch is exactly where modernization effort pays off first.
A simple way to sort candidates is to score each part of the system on two axes: how much the business depends on it, and how painful it is to maintain today. The piece that scores high on both is where you start. A piece that's painful to maintain but barely used can usually wait. A piece the business depends on heavily but that already runs smoothly doesn't need to be touched at all yet.
If it's not obvious where that priority sits in your own systems, a team with modernization experience can usually spot it within a week of looking. That's a conversation worth having early, before a roadmap gets built around the wrong starting point.