Retiring legacy systems

By Redaktion techport.ai, IT-Beratung · Last updated on 21 August 2026

Almost every mid-sized company runs at least one system that ought to be retired. It does what it should, it costs little, and that is exactly why it is hard to get funding for its replacement. Until the moment arrives when the only person who can maintain it retires, or when a vulnerability becomes known for which no update exists any more.

Old systems are not a technical annoyance but a business risk with an uncertain date. The task is to assess that risk and plan the replacement while you still have a choice.

How you notice it

A system receives no more updates and runs on an operating system that is equally unsupported.
Changes are only possible through one person or one single provider.
The system runs on its own machine that must not be touched.
New requirements are rejected with the note that the old system cannot do it.

Why this happens

Old systems are stable because over the years they have seen every special case. That stability is a real asset and the reason replacement feels hard. On top of that, the knowledge of the business rules often exists only in the system itself, not in documentation. Anyone wanting to replace it has to recover that knowledge first, and the effort involved is invisible at the outset. So the decision is deferred until it is forced, and then there is no time for an orderly path.

How we go about it

Assess risk rather than age. We assess every legacy system along five questions: is there vendor support, is there more than one person with knowledge of it, is it reachable from outside, which data does it process, and how large would the damage be from a multi-day outage. That produces a defensible sequence.
Recover the business rules. We work with the users to establish what the system actually does, which special cases it covers and which of those are still needed. Experience shows a noticeable share of the supposed requirements falls away at this step.
Define the cut. We break the system into functional blocks and check which of them can be replaced individually, for example by an existing system, by standard software or by a small custom development. A step by step path is almost always safer than a complete switch over a weekend.
Replace and switch off. We deliver the steps, run parallel operation for a limited period with an end date, and actually switch off the legacy system. A system that is switched off is the only proof that the replacement succeeded.

What you gain

Fewer systems for which neither updates nor specialists exist.
A sequence driven by risk rather than by volume of complaint.
Business rules that are documented instead of living only in code.

From our projects

Parallel operation is where replacements fail. If the old path stays open with no end date, the people who most need the new one keep using the old one. We therefore agree a switch-off date before the start and make continued operation after that date a deliberate decision with a justification. The second recurring finding: while recovering the business rules, departments discover special cases that have been handled automatically for years and that nobody remembers. Those cases are the most important part of the requirements and the most frequent source of surprises after go-live.

Häufige Fragen

Can we simply move a legacy system into a virtual machine?

That extends its life and removes the hardware risk, but it removes neither the security risk nor the dependence on individuals. As an interim step it makes sense if the replacement is planned in parallel. As a permanent solution it shifts the problem into a year when the pressure is greater and the choice is smaller.

What do we do when nobody knows how the system works any more?

Then the replacement starts from the outputs rather than the system. We record what goes in and what comes out, which reports and documents are produced and which rules the users know. That gives a solid requirements base. The code itself is rarely the best source in these cases, because it also contains rules that stopped applying long ago.

Let us talk about Retiring legacy systems

In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.

Arrange an initial call Our software