Recently someone said to me: “If it ain’t broken, don’t fix it.”
That sounds like a simple, perhaps somewhat old-fashioned statement. As if you should mostly avoid changing anything as long as the system is still running.
But in legacy environments I hear something different in it. Not: leave it alone because old is good enough. But: be careful, because nobody knows exactly why it works anymore.
And that is a very different problem.
Because when nobody knows how a system really fits together, replacing it is no longer a straightforward technical migration. You pull on a thread without knowing where it leads. Before you know it, Pandora’s box opens.
An old interface turns out to still be needed. A field that nobody uses feeds a report. A nightly script corrects data that three departments rely on. A strange delay prevents a machine from going into fault. An exception in the code turns out to be an old customer agreement. A manual Excel list turns out to be part of the real process.
And then you discover that the old system was not just software or hardware. It was memory. Not neatly documented, not elegantly designed, not always secure or future-proof — but filled with years of process knowledge.
That is why I find “If it ain’t broken, don’t fix it” actually not quite sharp enough. I would rather phrase it this way:
If it ain’t broken, first understand why it still works.
How legacy grows
In many organizations, legacy is primarily seen as a burden. Old programming languages, old databases, old servers, old PLCs, old SCADA environments, old interfaces, old screens that nobody is happy with anymore.
And sometimes that is justified. Old systems can be vulnerable. They may run on hardware that is no longer available, depend on software for which no patches are coming, and poorly meet modern security requirements, monitoring, or integration needs.
But that is only one side of the story. The other side is that such an old system has often moved along with reality for years. Not with reality as it was once depicted in a process diagram, but with reality as it actually was. An exception was added. Then another. A temporary workaround became permanent. A script that was quickly needed became business-critical. An interface that nobody liked stayed because three processes depended on it.
I have seen that up close myself. Years ago I worked on a control system at a power plant — de-icing of the air inlet. On paper it was a clear installation with a well-defined function. In practice there was an entire layer of logic around it that was documented nowhere: exceptions for certain weather conditions, manual overrides that operators had added over the years, timing dependencies that silently prevented the installation from getting itself into trouble. None of that was in a design document. It was in the system, and in the heads of the people who worked with it.
That is how legacy grows. Not because people are foolish or nobody was paying attention, but because organizations change, processes shift, customers ask for different things, legislation changes, machines get older, and people find solutions to get the work done.
Old is not automatically outdated
There is a misconception underlying many legacy discussions: that old technology is automatically outdated technology. That is not always true.
Much fundamental technology is still the same. A relational database is still a relational database. A TCP/IP network is still a TCP/IP network. In industrial environments too, many principles are surprisingly constant: measure, control, feed back, constrain, secure, log.
The shell changes — tooling, interfaces, architectural context. Think of event-driven architectures, zero trust, cloud-native patterns. But the underlying logic has often changed less than people think.
Sometimes the problem is not that the technology is fundamentally outdated, but that the world around the system has changed. The system once had to perform one task in a defined context. Now that same system must connect with modern applications, supply data to dashboards, meet new security requirements, be available to multiple departments, and fit within governance that did not yet exist at the time.
Then the system is not necessarily broken. It has simply ended up in a world it was never designed for.
The formal process is not always the real process
One of the greatest risks in modernization is starting from the formal process. People look at documentation, process diagrams, architecture schemas, at how things were once intended.
That seems logical. But in brownfield environments that is often not enough.
The real process is in behavior. In exceptions. In manual steps. In old scripts. In database values that were once temporary. In operator actions that have existed so long that nobody recognizes them as workarounds anymore. And often the legacy system is the only place where that real process is still visible — not beautifully, not completely, not neatly described, but present.
That is why an old system can be technically outdated and functionally still more mature than the new design. That is uncomfortable, but important. Because a modern system that only follows the formal process can be perfectly built and still fail in practice. Not because the technology is bad, but because it does not understand the real organization.
New technology does not resolve old ignorance.
Modernization can destroy knowledge
When you replace a legacy system without understanding what knowledge is in it, you don’t just throw away old technology. You throw away organizational memory.
That rarely happens in one big bang. It happens subtly. After go-live it turns out that certain exceptions no longer work. Reports are slightly off. Machines respond differently. Operators start doing extra checks. Users keep Excel lists. Departments build shadow processes. Operations receives notifications that nobody had anticipated.
And after a few months everyone wonders why the new system causes so much trouble. Not because modernization was wrong, but because the old system should have been read more carefully.
So how then?
Not by blindly replacing legacy. But also not by leaving everything as it is. The art is to first make the system readable, then manageable, and only then replaceable.
Start by observing — and by talking. Look not only at documentation, but especially at behavior. What comes in? What goes out? What exceptions are there? Which departments, machines, reports, or decisions rely on this system? And at least as importantly: talk to the people who work with it. The operator who has been running that machine for fifteen years. The administrator who once wrote that nightly script. The planner who runs an Excel export every Monday that nobody knew existed. The real process knowledge often sits not in code or configuration, but in people’s heads. And that knowledge disappears if you don’t involve those people before you start replacing.
Make the hidden process knowledge explicit. Much logic is no longer in documents, but in code, scripts, database fields, configuration files, operator actions, Excel lists, and old interfaces. Map that — not to document it for a drawer, but to take it along into the new design.
Put a safe shell around the system. Add logging. Add monitoring. Check backups. Restrict access. Segment the network. Make interfaces explicit. Possibly build an API layer, export layer, or middleware component. Not to make the old system prettier, but to make it manageable.
Then replace step by step. First one interface. Then one process step. Then one module. Where possible, let old and new run alongside each other temporarily. Compare output, behavior, errors, and exceptions — not only technically, but also functionally.
A big bang migration sometimes seems efficient, but in brownfield environments that is often false certainty. You discover the real complexity only when the new system must carry the old reality.
The rule is simple: do not replace a component whose function you do not yet understand. Or more sharply: you may only switch something off when you know why it was once switched on.
Modernization begins with understanding
Legacy is rarely only a technical problem. It is a combination of technology, process, history, and forgotten decisions.
Those who only look at the age of a system mainly see risk. Those who look more carefully also see knowledge. That does not mean old systems should remain as they are — some systems truly need to be replaced, some interfaces are dangerous, some dependencies are irresponsible, some technology is no longer secure or manageable.
But even then, good modernization does not begin with demolition. It begins with understanding.
What does this system actually do? Why does it work this way? What knowledge is stored in it? What must remain, what can go, what needs to be redesigned?
Legacy does not always arise because technology becomes outdated. Sometimes legacy arises because the world around the system changes. And precisely for that reason, modernization is not a matter of replacing old with new — it is carefully transferring working knowledge into a form that once again fits the current reality.
“If it ain’t broken, don’t fix it.”
But above all:
“If it ain’t broken, first understand why it still works.”