Technical debt and legacy software: what it is and when to replace it
Technical debt is the accumulated gap between how a system is built today and how it would need to be built to keep serving your organisation well. Every system accrues it; it becomes a problem when the interest (the time and risk of every subsequent change) exceeds the value the system still delivers. This page explains where the concept comes from, which signals point to a system that is due for modernisation, and how to tackle it without bringing the organisation to a standstill. Wondering how to choose between building in-house and buying a package? See also build vs buy: choosing custom software or a package.
Request an independent assessment Go to the signalsWard Cunningham's debt metaphor
The term technical debt did not come from an academic paper, but from a 1992 experience report by software developer Ward Cunningham, written for the financial software company WyCash.
The original idea
Cunningham essentially argued that shipping first-pass code is like taking out a loan. A little debt speeds up development, as long as you pay it back in time through rewriting. The danger arises only when the debt is never repaid. He used the metaphor to explain to non-technical stakeholders at WyCash why time for refactoring had to be built in structurally, not to excuse careless work.
How the term is used today
In Cunningham's own formulation, it referred to the gap between your understanding of the domain at the time of building and the understanding you have now. In the broader, common usage today, the term mostly refers to brittle design: code and architecture that are hard to change, so each subsequent change takes longer than the last.
Three places where technical debt accumulates
In practice a distinction is made by where the debt sits, because that determines how costly and risky it is to repay.
Code debt
Messy or duplicated code, missing tests, quick patches that never got cleaned up. Usually the cheapest to fix: refactoring without changing the system's external behaviour.
Architectural debt
The system's structure no longer fits how it is used: a monolith that really needs to scale independently, or modules so intertwined that a single change ripples everywhere. This calls for a redesign, not a quick fix.
Infrastructure debt
The language, framework or platform the system runs on is end-of-life or almost no one knows it any more. This is where legacy systems such as Delphi, COBOL, AS/400 and WinCC typically end up.
When does legacy software become a risk?
Not every older system is a problem. It becomes urgent as soon as one of these four factors comes into play.
Security: an outdated language means greater risk
Microsoft and Google have independently reported that roughly 70% of the serious security vulnerabilities they patch each year trace back to memory-safety problems in languages such as C and C++. Systems that have run on these for decades and are no longer actively maintained accumulate that risk, with no new patches to offset it.
Knowledge: the people who understand the system are leaving
COBOL is the best-known example: the language still processes an estimated significant share of global banking transactions, while the generation of developers maintaining it is retiring and very few new COBOL developers are coming through. The same pattern applies to Delphi, AS/400 (RPG) and WinCC configurations: the knowledge often sits with one or two people.
Compliance: regulation changes faster than the system can keep up
Regulations such as the NIS2 Directive set requirements for security and incident reporting that a closed legacy system often cannot meet without significant changes. See also our guide to NIS2 and custom software.
Integration: the system doesn't talk to the rest
Modern tools expect an API. Many legacy systems were built before that was the norm and have no, or very limited, integration options, so every integration becomes a separate, fragile middle layer.
Seven signs it's time to modernise
No single sign is decisive on its own. If you recognise three or more, it is worth assessing the system.
Developers familiar with the language or platform are hard to find
Every maintenance vacancy takes longer to fill than the last, or goes to an ever-smaller pool of freelancers.
Every change takes more time than the last
A small adjustment unexpectedly affects other parts; testing demands an increasing amount of effort relative to the change itself.
The platform vendor stops providing support
No more security updates, or only extended support at a rising premium.
The system can't integrate with the tools the rest of the organisation already uses
Data is retyped by hand or swapped through loose exports instead of through an integration.
New legislation requires functionality the system doesn't have
Think of reporting obligations, logging requirements or access control that have to be bolted onto the system after the fact.
The underlying infrastructure has itself reached end-of-life
The operating system, database version or runtime the system runs on is no longer patched by its manufacturer.
Knowledge of how the system works sits in the head of one or two people
There is no up-to-date documentation, and if that person falls ill or leaves, the organisation grinds to a halt.
These are the signs in brief. A more detailed walkthrough, with a concrete check for each sign to help you gauge how urgent it is, is in when to replace your software.
Common legacy systems we replace
Every platform brings its own migration challenges. Four systems come up most often for us.
Delphi applications
Often Windows desktop applications from the nineties and early two-thousands, still fully operational but no longer suited to web or mobile use. Read more about modernising Delphi applications.
COBOL systems
Typical in banks, insurers and government: large, critical batch processing systems where the risks of downtime are high. Read more about replacing a COBOL system.
AS/400 (IBM i)
Widely used in wholesale, manufacturing and logistics for ERP and inventory processes, often with RPG program logic that has lasted for decades. Read more about replacing AS/400 with a modern platform.
WinCC (SCADA/HMI)
Siemens WinCC installations on the factory floor that handle process control and monitoring, where replacement must be done carefully to avoid interrupting production. Read more about replacing WinCC.
Replace or modernise: not an all-or-nothing choice
The choice is rarely between doing nothing and replacing everything at once. In practice, there are two routes.
Incremental modernisation
Parts of the old system are replaced step by step while the rest keeps running: first the front end or a specific process, then the next layer. This reduces the risk at each step and keeps the organisation operational, but requires an intermediate layer that lets old and new systems communicate.
Full replacement
The entire system is migrated to a new platform in a single project, including data conversion. This is cleaner architecturally, but requires careful planning of the transition, including a period in which the old and new systems are checked side by side.
What a modernisation project looks like in practice
Whether you choose to modernise incrementally or replace everything at once, a careful project essentially follows the same four steps.
Discovery
Map out exactly what the system does: which business rules are hidden inside it, which integrations exist, and where the knowledge about the system comes from. In legacy systems, much of that logic isn't documented anywhere, only in the code itself.
Prioritising by risk and value
Not every component is equally urgent. Parts that carry the greatest security risk or change most often are usually tackled first, not necessarily the parts that are easiest to replace.
Building alongside the existing system
An incremental approach creates an interface that lets old and new work together, so the existing system stays operational while the new component is built and tested.
Controlled transfer and validation
Data and functionality are transferred with a validation step: record counts, history and business rules are checked before the old component is definitively switched off.
Frequently asked questions about technical debt and legacy software
An independent look at your legacy system
We start by assessing what your current system does and where the real risks lie, before proposing a modernisation approach that suits your organisation.
Book a no-obligation conversationIs it time to rethink your processes rather than keep patching them? Read more about custom business automation on applatenmaken.com.