When should you replace your software?
There is rarely a single moment when legacy business software becomes unusable. Usually small signals accumulate until maintenance costs more than it delivers. Seven concrete signals to watch for, and what they say about how urgent replacement is.
7 signs that replacement is closer than you think
None of these signals is, on its own, a reason to replace immediately. Together, however, they form a pattern: the more you recognise, the greater the chance that further maintenance is a temporary fix for a problem that is becoming structural.
Many organisations work to a fixed replacement schedule, for example "we evaluate the core system every seven years". That works well for budget planning, but says little about the actual condition of a system. A fifteen-year-old application that runs stably, is well documented and whose knowledge is widely shared may be healthier than a five-year-old application that already shows three of the seven signals below. The signals say more about urgency than the age of the system.
A simple integration becomes a separate project
New requirements almost always call for an API these days: an accounting package that wants to receive invoices automatically, a customer who requests real-time stock data, a regulator who demands digital submission. If your system can only supply a file via a nightly batch export, every new integration becomes a manual custom project rather than a configuration taking a few days. This often only becomes apparent when a customer or partner makes the integration a condition, and the delay has an immediate commercial impact.
The knowledge of the system fits in one head
Systems built in languages such as COBOL, Delphi or RPG (the language behind an AS/400) have not been taught as mainstream subjects for decades. For COBOL, this pattern is well documented: the average age of active COBOL programmers is around 60, while the number of open vacancies for these languages continues to grow. The person maintaining your system now is often the same person who helped build it years ago.
Patches and security updates stop or must be purchased separately
Operating systems and databases underpinning many legacy applications eventually reach the end of their support lifecycle. Windows Server 2012 and 2012 R2, for example, reached the end of mainstream support in October 2023; the last paid security updates (Extended Security Updates) expire definitively in October 2026. If your application runs on a platform in that phase, known vulnerabilities remain permanently open after that date.
Shadow processes emerge alongside the official system
Employees build their own Excel files, Access databases or shared spreadsheets to do what the system no longer supports smoothly. Data ends up fragmented across several unconnected sources, and reports have to be merged by hand before a manager can use them. Often only the author of such a spreadsheet knows which assumptions are built into it, which makes it especially fragile once that person goes on holiday or changes jobs.
Performance stalls as volume grows
Nightly batch processing that increasingly runs close to the opening time of the next working day, or reporting that runs on a single database server with no ability to scale horizontally. Growth in transactions, customers or employees exposes a design that was originally built for a smaller scale. The first response is often a bigger server or more memory, which temporarily eases the problem without addressing the underlying architectural choice.
Maintenance structurally costs more than replacement would
Hourly rates for scarce legacy specialists are often higher than standard development rates, precisely because the scarcity described in signal two drives up the price. On top of that, every change takes disproportionate time, as nobody fully understands the entire system any more and each modification has to be investigated before anything can be changed. What looks like a small adjustment on paper often means days of archaeology in the existing code first.
Users are actively avoiding the system
Staff only log in when there is no alternative, deliberately look for workarounds, or ask a colleague to make a change "quickly in the live system". That is a stronger signal than a technical error message, because it means the people who use it every day have already written it off.
Several signals recognised? These are the next steps
If you recognise three or more of these signals, a no-obligation conversation about your options is more useful than another emergency fix. Depending on the system you are replacing, that process can look very different.
Does it run on Delphi?
Delphi applications often contain solid business logic that is worth keeping, just not in its original form.
Modernising a Delphi application →Does it run on a Cobol mainframe?
With Cobol systems, the risk usually lies not in the code itself, but in the dwindling group of people who can still read it.
Replacing a Cobol system →Does it run on an AS/400?
An AS/400 often keeps running stably for years, until the knowledge around it disappears and every change means downtime.
Replacing an AS/400 with a modern platform →Does it run on WinCC?
With industrial control systems (SCADA/HMI), there is often also the question of how to connect securely to modern cloud and IoT integrations.
Replacing WinCC →Do you recognise these signs, but run your system on a different platform from those above? We can still guide you through custom software development, from initial analysis to going live.
Would you first like to understand why these kinds of risks arise? Read our background page on technical debt and legacy software.
A first, no-obligation step is usually a technical intake: which parts of the current system are still healthy, which contain useful business logic worth carrying over, and which are simply outdated. That intake determines whether a full replacement is needed, or whether a phased approach with a modern interface layer around the existing system is sufficient.
Frequently Asked Questions
Go through the seven signals and count how many you recognise. With one or two signals, targeted maintenance is often still sensible. With three or more, especially combined with rising maintenance costs, a replacement project deserves serious consideration.
In practice, a phased approach is often wiser than a full big-bang replacement. Decoupling critical components first behind a modern interface, then replacing the rest of the system in stages, limits risk and keeps the organisation running throughout the project.
Data analysis and migration are usually a separate sub-project: first mapping which data is usable and which historical clutter has been carried along for years, and only then migrating. That way you don't automatically carry the data quality problems of the old system into the new one.
Sometimes, yes. A system that runs reliably, needs no integrations and whose knowledge is spread across more than one person can last for years. Delaying becomes risky once several warning signs appear at the same time, because costs and risks then tend to rise faster than in a straight line.
A single signal is usually not reason enough for a full replacement project, but it is reason to keep monitoring it. Signals two (knowledge) and three (support ends) deserve particular attention, as they rarely improve on their own.
Yes, with larger systems this is often the most sensible route. A stable core component can keep running temporarily behind a new interface layer, while the parts showing the most signals are replaced first.
With the process. A replacement that merely puts the old screens in a new coat of paint often carries the bottlenecks of the old process across unnoticed. Mapping out how the work actually runs today, including the shadow processes from signal four, prevents this.
Not sure whether your system is ready for replacement?
Briefly describe which signals you recognise and what your current system looks like. We will gladly think along with you, without obligation, about what a realistic first step would be.
Already know what should take its place? applatenmaken.com sets out which custom software we build by sector and process.