Old is not the same as broken. Plenty of businesses run on systems that are 15 years old and perfectly sound, and plenty have spent a fortune replacing something that only needed leaving alone. The decision to modernise should rest on four things. Whether the system still does the job, whether it can be kept running safely, whether it is blocking something the business needs, and what replacing it would actually cost. Age on its own is not a reason.
Here is how to work through it without being talked into a rebuild you do not need, with the option most people miss and the questions that settle it.
Why this decision goes wrong so often
Two sets of people have an interest in you replacing the system. The agency or vendor who would build or sell the replacement, and the engineers who would rather work on something new. Both are sincere. Both are biased. The founder, who has to pay for it, is usually the least equipped to judge.
The other failure runs the opposite way. A system that is genuinely dangerous, unsupported and blocking the business, kept alive year after year because replacing it feels too big. The business works around it until the workarounds are the business.
The job is to separate the two cases, and the four tests do that.
Leave it alone when
It does the job and the people who use it are not complaining. Boring, reliable software is the best kind, and a system that has run for a decade without drama has earned some respect.
It can still be supported. Security patches are available, someone understands it, and a failure would not be a crisis. If that is true, the risk is manageable, however unfashionable the technology.
The cost of change dwarfs the benefit. A system that is awkward but works is often cheaper to live with than a replacement that costs a year and a great deal of money to reach the same place. Be honest about what the replacement would actually deliver beyond ‘newer’.
The business is about to change anyway. If an acquisition, a pivot or a merger is coming, replacing a core system now means doing it twice.
Modernise when
It is unsupported. No patches, no vendor, no one who understands it. That is a security and continuity risk that grows every month, and it tends to surface at the worst time. An unsupported system that holds customer data is a breach waiting for a date.
It is blocking the business. Sales cannot get the feature, operations cannot get the report, the thing customers now expect cannot be built on it. Our piece on whether your platform will scale covers how that shows up. When growth is being capped by a constraint you can name, the constraint has to go.
It is quietly expensive. Manual workarounds, duplicated data, hours lost every week to things the system should do. Add those up honestly over a year and the business case often writes itself. A system that costs 15 hours a week in workarounds is costing more than most replacements.
It cannot connect. If the future depends on the system talking to others, including AI tools, and it cannot, the clock is running. Integration is where most of the next five years of value sits, and a system that cannot take part is a dead end.
The option people miss
Replacement is not the only move. Often the right answer is to wrap the old system, put a modern layer in front of it that handles the new needs while the core keeps doing what it does well. A modern interface over an old database. An integration layer that lets the legacy system talk to the new tools. A new module for the one capability that is missing, bolted alongside rather than replacing everything.
It is cheaper, faster and far less risky than a rebuild, and it buys time to replace the core properly later if you still need to. Many businesses find they never need to, because the wrapped system does the job for another decade.
The other missed option is doing nothing on purpose, with a date to revisit. Deciding to leave a system alone until a specific trigger, the vendor ending support, the business reaching a certain size, a named feature becoming essential, is a legitimate decision. Drifting is not.
What this looks like in practice
A 70-person distribution business on a 12-year-old stock and order system. The agency proposes a full replacement, 14 months, well into six figures. The four tests.
Does it do the job. Yes. Orders flow, stock is accurate, the warehouse team like it.
Can it be supported. Partly. The vendor still patches it, but only one person in the business understands the customisations.
Is it blocking the business. In one specific way. Customers want an online ordering portal, and the system has no way to expose that.
What would replacement cost. The agency’s number, plus the disruption of retraining a warehouse that runs on muscle memory, plus the risk of a migration going wrong in peak season.
The decision. Keep the core. Build a modern ordering portal that talks to it through an integration layer, four months, a fraction of the cost. Document the customisations and train a second person. Set a trigger, if the vendor announces end of support, revisit. Three years on, the portal is the business’s main sales channel and the old system is still quietly running the warehouse.
How to decide
Write down what the system costs you today, in money and in things you cannot do. Be specific. Hours of workarounds a week, features you have said no to, risks you are carrying.
Write down what it would cost to replace, honestly, including the disruption, the retraining, the migration risk and the months of reduced capacity while the team does two jobs. Most replacement estimates leave out at least half of this.
Then ask which risk you would rather carry. Most of the time the answer is clear once both numbers are on the page, and most of the time it is less dramatic than the people selling the replacement suggest.
The common mistakes
Replacing because it is old. Age is not a defect.
Keeping because it is familiar. Familiarity is not safety. An unsupported system is a risk however comfortable it feels.
Believing the estimate. Modernisation programmes overrun. Almost all of them. Our piece on why software projects overrun explains the pattern. If you decide to replace a core system, plan for it to take longer and cost more than the estimate, and run it with real governance from day one.
Ignoring the wrap. The middle option is the right one more often than either extreme, and it is the one the agency is least likely to propose.
Forgetting the people. The warehouse team who run on the old system are an asset. A replacement that ignores how they actually work fails on the floor whatever the code is like.
The honest trade-off
Wrapping and waiting carries its own risk. The old core gets older, the integration layer becomes its own thing to maintain, and the trigger you set might arrive sooner than you planned. It is still usually the better bet, because the risk is spread over time rather than concentrated in a single migration weekend.
A technology review gives you the honest starting picture, including the one thing agencies rarely offer, a straight view of whether the system needs replacing at all. Our forward deployed engineering work exists for the delivery when the decision is to go ahead.
Frequently asked questions
How do I know if a legacy system needs replacing?
Check four things. Is it still supported, is it blocking the business, is it quietly costing you in workarounds, and can it connect to what you need next. Age alone is not a reason.
Is it risky to keep old software?
Only if it is unsupported or nobody understands it. A supported, understood system that does the job is low risk, however old it is.
What is the alternative to a full rebuild?
Wrapping the old system with a modern layer that handles new needs while the core keeps running. It is usually cheaper and faster, and it reduces the risk of a big-bang replacement.
How much does legacy modernisation cost?
It depends entirely on scope, but the honest number is always higher than the first estimate, once disruption, retraining, migration risk and reduced capacity are included. Get those into the business case before deciding.
Should we replace before adding AI?
Not necessarily. Many legacy systems can be connected to AI tools through an integration layer. Replace only if the system genuinely cannot expose its data, which is rarer than vendors suggest.
Why do modernisation projects overrun?
Because the old system does more than anyone wrote down, and the dependencies only appear once you start. Plan for it, govern it tightly, and get an honest review before committing.