When is legacy software actually ready to be replaced?
There is always that one system. A warehouse application that only runs in an ancient browser. A customer portal whose original developer left years ago and whose code nobody dares touch. Or the classic: a spreadsheet someone updates by hand every morning because three systems refuse to talk to each other.
As long as a system still just about does its job, it stays. That isn't even unreasonable. Replacing it costs money, time and attention you could spend on customers instead. But carrying on costs something too, and that bill is harder to see. It sits in manual work, in mistakes that have to be corrected afterwards, in the one colleague who knows which workaround to use, and in the things customers ask for that you simply cannot build.
So the question isn't whether old software has to go on principle. The question is which risk you are removing, and how the business keeps running while you do it.
Old is not the same as bad
A fifteen year old application can be a perfectly good fit for a process that has barely changed in fifteen years. If it runs reliably, it's properly secured, it can still be maintained and it isn't getting in anyone's way, there's no reason to touch it. Age on its own is not an argument.
It only becomes legacy when the system stops moving with the organisation. A web shop that falls over during a campaign. A planning tool with no usable integrations. Internal software that works fine as long as you know exactly which order to click things in. That's where it hurts: not in the technology itself, but in the dependency and the limits that come with it.
A few plain questions help bring that into focus. Can you still change the system within a reasonable timeframe? Is there someone who genuinely knows the technology, and is that someone more than a single person? Does it hold up against today's security and privacy requirements? And what happens if the supplier shuts down, or a server dies on a Friday afternoon? That's the real assessment, not the year it was built.
The signals that do mean something
One outage is not a reason to start a replacement project. A pattern is. When people work around the system every day, it has stopped being a tool and become an extra layer in the process. And when customers wait because data is being retyped by hand, that hits your revenue and your reputation, even though it never shows up on a dashboard.
The patterns we run into most often:
- Updates, security patches or support are no longer available, or only at a price that bears no relation to the value.
- A small change takes weeks, because the code is unclear and the documentation is from a previous decade or never existed at all.
- Integration barely works, while what you actually want is accounting, CRM and suppliers connected to each other, along with payment providers and anything else that matters.
- Exports, spreadsheets and double data entry are what keep the daily work upright.
Two signals get overlooked more often. The first is scalability. Software that just about keeps up at your current size can quietly become the bottleneck as you grow. A web shop with campaign peaks, a SaaS platform picking up users, a publisher with rising traffic: at that point slowness is not a technical detail. Visitors drop off, staff sit waiting, and an incident becomes far harder to recover from.
The second is ownership. Hosting with party A, the application with party B, an integration with party C. The moment something breaks, the passing around starts, and nobody picks up the whole problem. For a process your business depends on, that's too thin an arrangement.
Count the cost of doing nothing too
The question is usually framed too narrowly: what does replacing it cost? The more interesting one is what doing nothing will cost you over the next two or three years.
Make that concrete. Add up the hours that go into checking, correcting and entering things twice. Estimate what you lose to a slow platform, or to features customers expect that can't be built. Include the emergency work, and the external specialist you hire because hardly anyone knows the old technology any more.
Against that sit the investments: analysis, development, data migration, testing, training and maintenance. Those appear neatly on a quote, which is why they weigh more heavily in the conversation. The cost of the old system appears nowhere, but it keeps running every month. Put the two side by side honestly and the answer varies per case: sometimes it points towards replacement, sometimes towards a much smaller intervention.
That smaller intervention is the better option more often than people expect. If the core is still sound, you can put an API layer alongside it, refresh a worn out interface, or automate a handful of manual steps. You gain speed and usability without rebuilding the business logic from scratch.
Keep, modernise or replace
Keeping it is fine, provided the system is stable, secure and maintainable and the need isn't shifting much. Just make sure you have monitoring, backups, documentation and firm agreements about transferring knowledge. Keeping something without managing it isn't a choice, it's a delay.
Modernising fits when the core is valuable and the edges are worn. An administrative system that calculates reliably but can't connect to anything. An internal platform with solid logic and an interface nobody enjoys using. By renewing specific parts you keep control of budget and risk.
Replacing is the answer when the foundation itself is the problem. Security that can no longer be repaired, code you can't change with any confidence, or software that simply doesn't match how the business works now. In that case patching it up gets more expensive over time than rebuilding, however daunting the rebuild looks at first.
One more thing matters: how distinctive is this piece of software, really? If it contains something that genuinely sets your service, your planning or your customer experience apart, custom development is usually the sensible route. If it's a standard process nobody loses sleep over, an existing package with good integrations will do nicely. Custom software isn't a goal in itself, but it does make sense the moment off the shelf software forces you into detours.
Replacing without shutting the place down
The classic mistake is wanting to deliver everything at once. A big bang looks tidy, one date and one go live, but it actually increases the dependencies. Miss one exception in invoicing or in the stock integration and you're in trouble on Monday morning.
Working in phases gives you more grip. Start with an inventory, technical and functional: which processes are critical, which data is trustworthy, which integrations exist, and where do people get stuck every day? Don't just talk to management and IT, talk above all to the people who open the system daily. They know the exceptions that appear in no document anywhere.
Then pick a first delivery that's small and still worth something straight away. A new customer portal, an integration that removes double entry, or a tool for that one error prone process. Where it's needed, run old and new side by side for a while. That gives the organisation room to adjust, test against real situations and change course, while service carries on.
Data migration deserves a plan of its own. Old systems are full of duplicate customer records, empty fields and history nobody ever looks up. Carrying everything across blindly makes the new system needlessly complicated. Agree in advance what the operation genuinely needs, what only has to remain readable, and what can be archived or deleted under your retention rules.
Put hosting and maintenance on the table from the start as well. A new application that's been built cleanly but is poorly monitored, backed up or scaled mostly gives you a newer version of the same problem. Development, infrastructure and support have to line up, and when something goes wrong it should be obvious who picks it up and how fast.
What to ask before you start
A list of features isn't enough to start from. Such a list describes what people do now, not why they do it. So ask which steps in the process genuinely add value, which exceptions come up regularly, and what information is needed at which moment. Fairly often, a much requested feature turns out to be a workaround for something else entirely.
Ask as well what success looks like six months in. Less manual work? Orders moving through faster? Fewer support tickets? Availability that holds up during a peak? Measurable goals are what keep you from a project that gets delivered technically and changes almost nothing operationally.
A good technical partner won't turn up in the first meeting with a package or a big rebuild plan. First it has to be clear where the vulnerability sits, what can stay standing in the existing landscape, and how to keep the transition manageable. At LJPc we look at the application, the integrations and the hosting as one whole, because a solution is only worth something if it also holds up on a busy Tuesday.
Waiting until legacy software finally gives out is the most expensive way to replace it. Start when the risks become visible and there's still room to make choices. Then you're building from a position of control rather than panic, and the technology goes back to doing what it was meant to do: making the work easier.