# Retiring legacy systems: assess risk, set the sequence, modernise step by step > How to replace systems without vendor support, without specialists and without documentation: assess the risk, separate the functions, replace step by step rather than in one jump. URL: https://techport.ai/en/it-beratung/architektur-und-anwendungen/legacy-modernisierung --- 1. [IT Consulting](/en/it-beratung)/ 2. [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen)/ 3. Retiring legacy systems [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen) # 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 1. **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. 2. **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. 3. **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. 4. **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](/en/kontakt)[Our software](/en/loesungen) ## Further reading [Architecture and ApplicationsERP strategy and system changeHow to prepare the ERP decision: assess the state of the system, review customisations, estimate migration cost realistically, plan around maintenance deadlines and make the rollout predictable.](/en/it-beratung/architektur-und-anwendungen/erp-strategie)[Architecture and ApplicationsCleaning up the application landscapeWhich systems carry which process, where data originates, what is duplicated and what is being phased out. An overview that speeds up decisions instead of filling folders.](/en/it-beratung/architektur-und-anwendungen/anwendungslandschaft)[Rollout and ChangeData migration without surprisesWhy migrations delay projects and how to do it differently: analyse data before planning, cleanse with the departments, run several tests, set acceptance criteria and reconcile provably.](/en/it-beratung/einfuehren-und-veraendern/datenmigration)[KnowledgeIT maturity checkKnow where your IT stands in ten minutes.](/en/it-beratung/reifegrad-check)[KnowledgeIT metricsDefinitions and formulas read the same way across the company.](/en/it-beratung/kennzahlen) Back to the field [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen) Rt Written by [Redaktion techport.ai](/ueber-uns), IT-Beratung Mehr als 15 Jahre Erfahrung in IT-Projekten des Mittelstands, Auswahl und Einführung von Unternehmenssoftware, Aufbau von IT-Betrieb und Informationssicherheit in wachsenden Organisationen. [More about us](/en/ueber-uns) More from techport.ai [ Software Custom process software for mid-sized companies. ](/en/loesungen)[ HR consulting People processes and the systems behind them. ](/en/hr-beratung)[ IT maturity check Ten minutes to a clear position. ](/en/it-beratung/reifegrad-check)[ HR maturity check 24 statements, a result per field. ](/en/hr-beratung/reifegrad-check)[ Funding BAFA grant plus more than 50 programmes for delivery. ](/en/foerderung)[ Process in practice How workflows become reliable software. ](/en/sop-praxis)[ Data and AI Analysis, forecasts and assistance systems. ](/en/daten-ki)[ About us The people behind techport.ai. ](/en/ueber-uns)