Most of the time, do not rewrite it. The full rewrite from scratch is the single most regretted decision in enterprise software, and the alternative, incremental modernisation around the running system, is slower to feel heroic but far more likely to succeed. And sometimes the correct answer is to leave the legacy system entirely alone, because it works, it is paid for, and touching it buys you nothing.
Why the big rewrite fails
The full rewrite is seductive because the old system is genuinely painful and a clean slate feels like freedom. It almost never works out, and the reasons are structural rather than a matter of trying harder.
- The old system knows things you do not. Years of bug fixes, edge cases, and quiet business rules are baked into that ugly code. Every strange conditional is usually a scar from a real incident. A rewrite throws all of that hard won knowledge away and rediscovers it one production failure at a time.
- You are chasing a moving target. The business does not freeze while you rebuild. The old system keeps gaining features, so the new one must catch a target that is running away from it. Many rewrites never ship because they can never quite reach parity.
- Big bang cutover is enormous risk. Replacing everything at once means one terrifying switch where all the risk lands on a single day. Anything you missed becomes an outage in front of your customers.
The pattern is depressingly consistent: two years in, the new system still does not match the old one, the old one still needs maintaining, and now you are funding two systems and morale is gone.
The strangler fig alternative
The reliable approach is to grow the new system around the old one and let it gradually take over, the way a strangler fig grows around a host tree until the tree is gone. You put a layer in front of the legacy system that routes requests, and then you replace one capability at a time. Each piece moves to the new implementation while everything else keeps running on the old code.
You are never more than one small step from a working system. If a piece goes wrong, you route back to the old path and fix it, rather than betting the company on a single cutover.
This is less exciting and far more successful. It delivers value continuously instead of promising a big payoff years away. It keeps risk small and reversible. And it means that if priorities change halfway through, you stop with a system that is partly modernised and fully working, rather than a half built replacement that runs nothing.
How to find the seams
Strangling a system requires seams, the natural lines where you can insert a boundary and peel off a piece without unravelling everything. Finding them is the real skill.
- Start at the edges. The easiest first cuts are capabilities with clear inputs and outputs and few tentacles into the rest of the system. Reporting, notifications, a public API, a self contained workflow. Prove the pattern somewhere low risk before you touch the core.
- Follow the pain and the change. Modernise the parts that hurt most and change most often. There is no return on rewriting a module that works fine and nobody has touched in five years. Aim your effort where new work is constantly blocked by old code.
- Cut at the data boundaries. The hardest coupling is almost always shared data. Find the places where one area of the system owns its data cleanly, because those are where you can insert a boundary without a painful data migration on day one.
- Add a seam if there is not one. Sometimes you must first introduce an interface into the legacy code, route the current behaviour through it unchanged, confirm nothing broke, and only then swap what sits behind it. The intermediate step feels like wasted motion but it is what makes the replacement safe.
When to leave it alone
Here is the part that gets skipped: often the right decision is to do nothing. A legacy system is not a problem simply because it is old or unfashionable. Age is not a defect. If a system does its job, is reasonably stable, and is not blocking anything important, then modernising it is spending money and risking outages to reach a place no better than where you already are.
Leave it alone when all of these hold:
- It works and it is stable. Failures are rare and understood, and the people who support it can keep doing so.
- It is not blocking the business. New work is not routinely held up by it, and it is not the reason you keep losing customers or engineers.
- The risk of change outweighs the reward. The system is load bearing and poorly understood, and the realistic downside of disturbing it dwarfs any upside.
"Boring, old, and quietly doing its job" is a perfectly good state for a lot of software. Some of the most valuable engineering judgement is knowing which fights not to pick. Chasing modernity for its own sake is how teams create outages in systems that were serving customers just fine.
Making the call
When something genuinely does need to change, be clear about why, in terms of business outcomes rather than aesthetics. "It is old" is not a reason. "New features take three times longer here and it is costing us deals" is. Then choose the smallest change that addresses that specific pain, prefer strangling to rewriting, and keep every step reversible.
If you are weighing a modernisation and want an honest read on whether to strangle, rewrite, or leave it be, that judgement is most of what our custom software development work involves, and it pairs closely with how we think about software development methodologies. You are welcome to book a free consultation and talk through your particular system before anyone touches a line of it.