In almost every mid-market company there is that one system. It has been running for twelve years. No one wants to touch it. The developer who built it left long ago. And yet a large part of the day-to-day business depends on it. You know that at some point you have to do something. You just do not know what — and above all, how to do it without the shop standing still for a week.
This article is the honest guide to that. Including the uncomfortable truth about why the obvious reflex — "throw everything away and rebuild it" — almost always fails, and what works instead.
The term legacy sounds like rubbish. It is not. An old system is software that has been working for years and does real work. That is an achievement, not a failure. The actual problem is rarely the code itself — it is that the knowledge about it has been lost and that changes have become risky.
An old system becomes a real problem precisely when one of four conditions occurs: it can no longer be changed safely. It can no longer be connected to other systems. It can no longer be operated because the technology is reaching end of life. Or the knowledge has shrunk to a single person.
If none of these four conditions is met, the most honest recommendation is often: leave it alone. "It is old" is not a business problem. "We can no longer react" is one. Modernize because of a concrete pain, not because of a gut feeling.
The obvious reflex: "Let us throw the old thing away and build it cleanly anew." It feels right. It is almost always wrong. This is not mere opinion: the failed "big rewrite" is one of the most extensively documented experiences in the software industry — from Joel Spolsky's classic "Things You Should Never Do" to Martin Fowler's work on incremental replacement (sources at the end).
Three reasons why the big-bang rewrite fails:
The honest consequence: the big bang is the most expensive and riskiest option. There is almost always a better way.
The proven strategy is to replace the old system step by step, instead of replacing it with a bang. The image behind it: you build the new thing around the outside and cut the old one's tasks away piece by piece, until there is nothing left that it still has to do.
Concretely this means: you put a clean interface in front of the old system. New functionality is created in the new one. Existing functions are extracted and replaced one by one, in the order of their pain. The old system shrinks instead of exploding.
The decisive advantage: each step delivers value and is, in itself, small and reversible. If a step goes wrong, you have a small problem, not a corporate crisis. This interface layer is usually the very first, lowest-risk modernization step — we have explored this topic in depth in API development in Munich.
Here too the honest counter-direction. Not every old system needs modernizing.
When it runs stably and nothing has to change. A self-contained system that reliably performs a closed task and gets no new requirements is not a modernization case. It is a working tool. Let it run.
When the underlying process is going to be abolished anyway. Never modernize a process that will no longer exist in a year. First the business decision, then the technology.
When the honest answer is "replace with standard software". Sometimes the modernization is not a development project at all but a purchasing decision: the old system no longer does anything company-specific today, a standard product can take it over. We generally make this assessment in the guide to custom software development.
A good partner checks these three cases first — before selling you a modernization project.
A word on contract design, because it is especially delicate in legacy projects: a pure fixed price is almost always the wrong choice here. No one can seriously fix a price in advance for the surprises slumbering in an undocumented old system. Anyone who does it anyway has either priced in a huge risk surcharge or will renegotiate the project mid-step.
Why that is so, and which model fits instead, we have described in detail in Fixed price vs. agile. The short version for legacy: discovery clearly bounded, implementation iterative with a budget cap. And because the mid-market has its own rules of the game here, Software for the mid-market is worth reading in addition.
More about our approach can be found on the page about custom software and app development.
Legacy modernization is not a tidying-up project but risk management. The obvious big rewrite is almost always the most expensive and riskiest option. The better way is to replace the old system step by step — small, valuable, reversible steps. And sometimes the most honest modernization is simply to leave the system alone.
Do you have a system that no one wants to touch any more and that everything still depends on? We analyse honestly whether and how it should be replaced step by step — and we will also tell you when you are better off leaving it alone.
This article is based on our own project experience from legacy modernizations in the Munich area. The central statements — why the big rewrite fails and why incremental replacement is the better way — are established, well-documented industry knowledge; the original primary sources are linked below.
