Legacy Is About Context | join.tech Blog
← See more blog posts
BLOG<br>Legacy Is About Context
Author: David Schmid
Date: 21.07.2026 •<br>Last Update: 21.07.2026, 17:03
Categories:<br>Modernization, Software Architecture, Systems Thinking
A few years ago, I was asked to look at a system that everyone agreed<br>needed to be replaced.
The software was more than 20 years old.
Documentation was incomplete.
Parts of the technology stack were decades old.
The verdict seemed obvious:
"This is legacy software."
It had to be replaced.
After a few days, however, it became clear that the software itself<br>wasn't the biggest problem.
Nobody could explain everything connected to it.
Table of Contents
The Myth of Legacy Software
Old Does Not Mean Unmaintained
Software Accumulates Context
Hidden Dependencies
Technical Debt and Knowledge Debt
Legacy Is Accumulated Context
Case Study: ASAL 2.0
Start With Discovery
Conclusion
Need an Independent View?
About the Author
References
The Myth of Legacy Software
The word legacy has become almost synonymous with<br>bad.
Old code. Old databases. Old operating systems. Old programming<br>languages.
But age alone tells us very little about the quality of a system.
Some 50 year old COBOL systems still process critical transactions<br>every day with remarkable reliability. At the same time, plenty of<br>"modern" systems become difficult to maintain after only a few years.
When we describe software as legacy, we often mix up three different<br>questions:
How old is the system?
How difficult is it to change?
Does it still serve the organization?
A system can be old and easy to operate. It can be difficult to change<br>while still providing enormous business value. It can also be<br>technically modern and no longer fit the needs of the organization.
Only the third question directly justifies replacement.
The second suggests, that we should improve the ability to change the<br>system safely.
The first question, its age, tells us almost nothing on its own.
Referring to Micheal Feather's work on legacy code, the practical<br>problem is not that code is old, but that changing it is risky because<br>of a lack of reliable feedback and an incomplete understanding of its<br>behaviour.
From an architectural perspective, Gregor Hohpe makes a similar point:<br>architecture should be judged against the expected rate of change,<br>meaning that a stable system in a stable business domain may not need<br>the same flexibilty as a product that changes every week.
Old Does Not Mean Unmaintained
Another distinction worth making is between old and unmaintained<br>software.
A programming language, database or system dependency may be old while<br>still being actively maintained, supported and widely used. At the<br>same time, a relatively new library may already be abandoned and no<br>longer receive bug fixes or security updates.
The real concern is therefore not only when a technology was created,<br>but whether it is still maintained and whether the organization can<br>operate it responsibly.
A system can also become outdated if teams stop improving it,<br>documentation is neglected and necessary upgrades are postponed. The<br>system continues to operate while its condition gradually<br>deteriorates.
There can be different reasons for this, but often it comes down to<br>whether an organization is willing to invest in the old system. This<br>is especially common when a replacement has already been announced.
In that sense, calling a system legacy can become a self-fulfilling<br>prophecy: we stop investing in it because we plan to replace it, then<br>point to the resulting problems as evidence that it must be replaced.
Software Accumulates Context
What at first glance might look like a single application may be only<br>the tip of the iceberg, with a much larger network of technical and<br>organizational relationships hidden beneath the surface.
Martin Fowler's work on enterprise application architecture shows this<br>complexity from a technical perspective. Enterprise software often<br>combines business logic, data access, integration and transaction<br>management.
Following Donella Meadows' system thinking, a system is not defined<br>only by its individual components, but also by the relationships<br>between them, the feedback loops they create and the purpose they<br>serve.
The longer a system operates, the more context accumulates around it:
Someone knows how to restart it.
Someone checks a report every morning.
Someone understands which errors can be ignored and which require<br>immediate attntion.
Someone has built a process around behaviour that may never have been<br>formally documented.
And so on.
Eventually, the software itself becomes only one part of a much larger<br>system.
And every one of those relationships becomes a potential source of<br>risk during change.
The boundry around an application is often drawn for convenience. In<br>reality, it may also include people, procedures, incentives and<br>external organizations.
This is why replacing one technical component...