Every few years, someone looks at the old system and says the words that feel so obviously right: let us just rebuild it from scratch. The code is a mess, nobody fully understands it, every change is painful, and a clean start promises to sweep all of that away at once. It is one of the most tempting decisions in software, and one of the most reliably expensive. The pain a rewrite promises to remove rarely disappears. It just moves eighteen months into the future and brings a great deal of risk along with it.
This is worth saying plainly because the instinct is so strong and so understandable. Working in an old, tangled codebase is genuinely miserable, and the fantasy of a fresh, clean version is powerful. But the decision to rewrite is usually made on that feeling rather than on the economics, and the economics are almost always worse than they look.
The old system knows more than you do
The single most underestimated fact about a legacy system is how much hard-won knowledge is buried inside it. That ugly, tangled code is not just badly written. A great deal of it is years of accumulated edge cases, bug fixes, regulatory quirks, and quiet accommodations for the messy realities of the business. Every odd little branch that makes no sense was, at some point, put there to handle a real problem that hurt someone.
A rewrite starts by throwing all of that away. The new, clean system does not know about the customer type that needs special tax handling, or the integration that returns dates in the wrong format, or the rule that only matters at year end. So it rediscovers every one of them the hard way, one production incident at a time, in front of real customers. The old system looked simple to replace precisely because you had forgotten how much it was quietly doing.
The business freezes while you rebuild
The second cost is the one that does the real damage. While the rewrite is under way, the old system still has to be kept alive, because the business runs on it. So you are now paying to maintain the old thing and build the new thing at the same time, with the same team. And crucially, you largely stop shipping anything new, because everyone is pouring their effort into catching the rewrite up to where you already were.
That means a year or more where the business cannot meaningfully improve its own software, while competitors keep moving. You are running hard just to end up roughly where you started, with a system that does what the old one already did. Rewrites are also famous for the second-system effect, where the team, freed from the old constraints, gilds the new version with everything it always wanted, so the project balloons well beyond the original and overruns its estimate by a wide margin. A striking number of rewrites run out of money or patience halfway, leaving the company maintaining two half-finished systems instead of one working one.
The safer default: modernise in place
The uncomfortable truth underneath all this is simple. If you understood the old system well enough to rewrite it cleanly, you probably understand it well enough to fix it in place. And fixing it in place is almost always the better bet.
The approach that works is incremental. You wrap the existing system and put stable interfaces around its parts, then rebuild one module at a time behind those interfaces while everything else keeps running untouched. The business keeps shipping improvements the whole way through. The embedded knowledge is preserved and migrated deliberately rather than discarded and rediscovered. And there is never a single terrifying cutover where you flip a switch and hope, because the replacement happens quietly, a piece at a time, each step small enough to reverse if it goes wrong. It is slower and far less dramatic than a grand rewrite. It is also the version that actually finishes.
When a rewrite really is the answer
None of this means a full rewrite is never right. Sometimes the platform underneath is genuinely dead: a language or runtime that is unsupported, insecure, and impossible to hire for, where no amount of incremental work can save it. Sometimes the business has changed so fundamentally that the old system models a world that no longer exists, and patching it just entrenches assumptions you have outgrown. In those cases, rebuilding is the honest choice. But even then, the smart version spreads the work out, replacing the old system in stages rather than betting the whole company on one big-bang switch. The goal is to avoid the moment where everything depends on a single cutover going perfectly.
Escape the pain without betting the business
A company wanted to rewrite a ten-year-old order system that everyone hated. Instead of starting over, we wrapped it and replaced its worst part first, the pricing logic, behind a clean interface, while the rest kept running exactly as before. Then we did the next piece, and the next, shipping improvements every month. Two years on, most of the system had been quietly replaced, the business had never once frozen, and there was never a day where anyone had to hold their breath and flip a switch. The pain got fixed. The company was never put at risk to fix it.
The urge to rewrite is really the urge to escape pain, and that urge is completely valid. The mistake is believing that starting over is the way to escape it. Far more often, starting over relocates the pain to a worse place and adds the risk of not arriving at all. Unless the platform beneath you is truly dead, the boring, incremental path is not the timid choice. It is the one most likely to leave you with a system you are glad to own.
If you are staring at a legacy system and weighing a rewrite, the most valuable thing you can do first is pressure-test whether you actually need one, or whether modernising in place would get you there with far less risk. Our team does exactly that kind of legacy modernisation, replacing old systems safely and incrementally rather than betting the business on a big-bang rebuild. Book a discovery call and we will help you find the lower-risk route.
Frequently asked questions
Should we rewrite our legacy system or improve it?
In most cases, improve it incrementally rather than rewriting from scratch. A full rewrite throws away years of embedded knowledge, freezes the business while it runs, and almost always takes far longer than estimated. The safer default is to modernise in place, replacing the system piece by piece behind stable interfaces while it keeps running and shipping. A ground-up rewrite is justified only when the platform is genuinely dead or the business has changed so fundamentally that the old model no longer fits.
Why do software rewrites fail?
They fail because the old system quietly holds years of hard-won knowledge, edge cases, bug fixes, and regulatory quirks, that a rewrite discards and then rediscovers one production incident at a time. They fail because the business freezes while the rewrite runs, unable to ship new features for a year or more. And they fail because a rewrite is almost always bigger than it looks, so it overruns its estimate, runs out of budget or patience halfway, and leaves the company maintaining two half-working systems instead of one.
When is a full rewrite justified?
A full rewrite is justified when the underlying platform is genuinely dead, an unsupported language or runtime you can no longer hire for or secure, or when the business has changed so fundamentally that the old system models a world that no longer exists. Even then, the rewrite should be done incrementally wherever possible rather than as a single big-bang cutover, so the business keeps running and the risk is spread out instead of concentrated into one switch-flip.
What is incremental modernisation?
Incremental modernisation is replacing an old system piece by piece rather than all at once. You wrap the existing system, put stable interfaces around its parts, and rebuild one module at a time behind those interfaces while everything else keeps running. The business keeps shipping improvements the whole time, the embedded knowledge is preserved as you go, and there is never a single high-risk cutover. It is slower and less dramatic than a rewrite, but it is far safer and it actually finishes.