At many companies, the order process runs on software that is older than the people who work with it. As long as everything works, nobody notices. Then the only colleague who understands the code retires, or a new integration turns out to take weeks.
Legacy systems are outdated applications or platforms that still play a business-critical role, while active support, knowledge, and further development are missing. They often run on an old programming language, database, or server and are hard to connect to modern software. The system still works, but changing or replacing it is expensive and risky.
Below are the seven signs of legacy software, the risks the Dutch National Cyber Security Centre (NCSC) describes, the choice between keeping, modernizing, and replacing, and a step-by-step approach that preserves your business logic.
Seven signs that you're working with legacy systems
Age alone says little about what counts as legacy. A 15-year-old application that is well tested, documented, and integrated can run just fine. Legacy becomes a problem the moment your organization depends on something nobody can safely change anymore. These seven signs come up most often:
- The knowledge sits with one person. One developer or administrator knows how the system works. When that person falls ill, leaves, or retires, the organization stops.
- Updates have stopped. The vendor has ended support, or the package only exists as an old version on an old server.
- Integrations take weeks. Every new connection to a webshop, ERP, or planning tool requires custom work, nightly file exports, or manual retyping.
- The language or database is outdated. Think of Visual Basic 6, old versions of Delphi, or an Access database with tens of thousands of lines of code.
- There are no automated tests. Every change is a gamble, because nobody can check what breaks elsewhere.
- You pay a high license fee for an old version. Upgrading is only possible with a rebuild, so you keep paying for software that has stood still.
- The system is a security risk. It runs on an operating system or framework without security updates, and the auditor is asking questions.
If you recognize three or more of these signs, it's time to map the dependency. An exploratory analysis of your legacy applications and the options for modernization shows where the risk is greatest and what needs attention first.
Ruud and the planning tool from 2006
Ruud is head of IT at a manufacturer of packaging machines with 120 employees. Production planning runs on an application that a now-retired colleague built in Visual Basic in 2006. Every night the system exports a CSV file to the ERP, and every morning a planner checks by hand that everything came through. When the company chose a new warehouse management system, the vendor asked for a real-time integration. The quote from the only external developer who still knew the code came to eight weeks of work. Ruud recognized five of the seven signs at once.
The risks of legacy software
The NCSC dedicates a section of its website to legacy systems. On a separate page it describes the risks of legacy systems. The core message: software without security updates contains known vulnerabilities, and attackers hunt for those.
Four other risks come with it:
- Continuity. An outage of an old system lasts longer, because knowledge, documentation, and sometimes even the hardware are missing.
- Compliance. Auditors for ISO 27001, the GDPR, or sector standards increasingly refuse to accept a server without updates.
- A stalled organization. New wishes, such as a customer portal or a dashboard, stay on the shelf because the old system can't share its data.
- Rising costs. Maintenance gets more expensive every year, while fewer people can help.
A legacy application that quietly does its job for years only gets noticed when it fails. By then there is no time left for a careful decision.
Legacy systems: keep, modernize, or replace
Replacing legacy software is rarely the only route, and often not the best one. In practice there are three options, each with its own moment.
Keep and isolate
The system keeps running and you limit the damage it can do. You place it in a separate network segment, make sure backups work, and document what it does. This option suits a system that changes little, needs no internet connection, and will be phased out in two to three years anyway. It buys time, nothing more.
Modernize step by step
You replace the system in parts while the old one keeps running. Each finished part takes over a piece of functionality. This option suits a system with a lot of unique business logic, such as pricing rules, planning rules, or calculations that hold years of experience. You want to keep that logic and renew the technology around it. For business-critical software this is the most common route, because the risk per step stays small.
Replace completely
You build or buy a new system and switch the old one off. This option fits when the process itself has changed, when a standard package now covers the work, or when the code is so hard to understand that reusing it costs more than starting over. Replacing calls for a tight data migration and a period with both systems running side by side.
| Situation | Best fit |
|---|---|
| The system rarely changes and will be phased out within a few years | Keep and isolate |
| A lot of unique business logic, used daily | Modernize step by step |
| The process has changed or a standard package covers the work | Replace |
| Nobody understands the code anymore and there are no tests | Replace, using the old output as a reference |
If you're torn between two options, an independent view helps. In a consultation about your architecture and technology choices we assess the code, the integrations, and the people around them with you. Sometimes our advice is to leave the system alone for now. After more than 30 years and 100+ projects, we've seen most variants before.
Fatima and the client records on an old server
Fatima is operations manager at a healthcare organization with 35 locations. Client registration runs on an application whose vendor shut down in 2019, on a server version without security updates for years. The last audit produced a finding with a 12-month deadline. A standard package was ruled out, because the registration is full of custom arrangements per location and per funder. She chose to isolate now and modernize in parts later. The first component renewed was the interface through which other systems retrieve client data.
Modernizing a legacy system without losing business logic
The biggest fear in modernization is that something gets lost that nobody ever wrote down. A line in the code that has decided since 2011 how a discount is rounded, for example. A good approach preserves that knowledge and replaces the technology around it in four steps.
Step one: take inventory
Map what the system does, which other systems rely on it, and what data it holds. Talk to the people who work with it, because they know the exceptions the documentation misses. The result is a list of functions, integrations, and data objects, with an estimate of importance and risk for each.
Step two: grow around the old system
This approach is called the strangler pattern, named after the strangler fig that grows around a tree until the tree itself becomes redundant. In plain terms: you place a new layer in front of the old system and redirect traffic piece by piece. If a new component falters, you switch back to the old one. The legacy system slowly dies off without a big bang.
Step three: interfaces first
Start where other systems retrieve or deliver data. Replace the nightly exports and direct database connections with an API or an integration layer. Our article on middleware and connecting systems without the spaghetti explains how such a layer works. Once the outside world talks through the new interface, you can replace the inside without other systems noticing.
Step four: then the modules
Replace module by module, starting with the riskiest or most frequently changed one. For each module, write tests that compare old and new behavior, so the business logic demonstrably stays intact. Each finished module goes live before the next one starts.
An example from aerospace
For ST Engineering, active in aerospace, we modernized an existing platform in stages: the backend moved from GoLang to .NET and the frontend from Vue 2 to Angular. Traceability and compliance came first, because every change in this sector must be accounted for. Part of our team worked on site with the client. The full story is in our article on software for aerospace MRO at ST Engineering.
Frequently asked questions
What is a legacy system?
A legacy system is an outdated application or platform that still plays an important role in daily operations, while active support, knowledge, and further development are missing. It often runs on an old programming language, database, or server and is hard to connect to modern software.
What are the risks of legacy software?
The main risks are security holes from missing updates, outages that last long because knowledge and documentation are missing, audit findings, and a stalled organization because new wishes don't fit the old system. The NCSC describes these risks on its website.
Do you always have to replace legacy software?
No. A system that changes little and will be phased out within a few years is often better isolated and properly secured. Systems with a lot of unique business logic are usually modernized step by step. Complete replacement fits when the process has changed or when a standard package covers the work.
How long does modernizing a legacy system take?
That depends on the size, the number of integrations, and the amount of business logic that must be preserved. By working in parts, the first renewed component, usually an interface, is often in production within a few months. The full modernization of a large system typically runs over several quarters, while the old system keeps running.
Key takeaways and next step
Legacy systems are rarely just a technical problem. They affect continuity, security, and the speed at which your organization can change. Remember:
- The problem is dependency on something nobody can safely change anymore. Age by itself says little.
- Three or more of the seven signs means it's time to map the dependency.
- Keeping, modernizing, and replacing are all legitimate choices, each for a different situation.
- Modernization starts with the interfaces and preserves business logic with tests.
The next step is an inventory: which systems, which integrations, which people. We do that with a team of 30+ engineers in Nijmegen and Sarajevo, ISO 9001 and ISO 27001 certified, and with the same people who keep the software running afterwards. Book a no-obligation conversation about your legacy systems and we'll tell you honestly which of the three options fits your situation.
