Legacy-Software bezeichnet Altsysteme, die produktiv im Einsatz sind, aber nur noch schwer gewartet, erweitert oder abgesichert werden können. Entscheidend ist dabei nicht das Alter des Codes, sondern der Zustand drumherum: fehlende automatisierte Tests, verlorenes Wissen über die Fachlogik, abgekündigte Frameworks oder Plattformen ohne Herstellersupport. Ein fünf Jahre altes System ohne Tests und Dokumentation kann Legacy sein, ein zwanzig Jahre altes mit sauberer Testabdeckung und aktivem Team dagegen nicht.
Für Geschäftsführer und IT-Verantwortliche im Mittelstand ist Legacy-Software selten ein akademisches Problem. Sie zeigt sich als Release, das niemand mehr anfassen will, als Sicherheitslücke, die sich nicht mehr patchen lässt, oder als App, die der Store plötzlich nicht mehr annimmt. Dieser Eintrag erklärt, woran du Legacy-Software erkennst, welche Risiken sie trägt, welche Optionen es zum Umgang gibt und wie du den Begriff von technischer Schuld, Standard- und Individualsoftware abgrenzt.
Was Legacy-Software ausmacht: eine Definition ohne Altersgrenze
Der Begriff „Legacy“ stammt aus dem Englischen und bedeutet Erbe oder Vermächtnis. Gemeint ist Software, die ein Unternehmen von früheren Entscheidungen, Teams oder Dienstleistern übernommen hat und die weiterläuft, weil der Betrieb von ihr abhängt. Das Problem ist nicht, dass sie alt ist, sondern dass niemand mehr sicher sagen kann, was beim nächsten Eingriff passiert.
Die bekannteste technische Definition stammt von Michael Feathers. In seinem Buch „Working Effectively with Legacy Code“ (Prentice Hall, 2004) definiert er Legacy Code schlicht als Code ohne Tests. Seine Begründung: Ohne Tests fehlt jede Möglichkeit, eine Änderung schnell und verlässlich zu prüfen. Jeder Eingriff wird zum Blindflug, egal ob der Code gestern oder vor fünfzehn Jahren geschrieben wurde. Diese Sicht ist bewusst eng, trifft aber den Kern: Legacy ist ein Zustand fehlender Absicherung, nicht ein Datum im Kalender.
In der Unternehmenspraxis kommen zwei weitere Dimensionen dazu. Erstens Wissen: Wenn der ursprüngliche Entwickler das Haus verlassen hat und die Dokumentation aus einem Ordner mit Screenshots besteht, ist die Fachlogik im Code eingeschlossen. Zweitens Support: Wenn Framework, Laufzeitumgebung oder Betriebssystem vom Hersteller abgekündigt sind, bekommt das System keine Sicherheitsupdates mehr, selbst wenn der eigene Code sauber ist. Legacy-Software ist also Software ohne Tests, ohne Wissen oder ohne Support, meist in Kombination.
Warum Legacy nicht gleich schlecht ist
Ein Legacy-System hat in der Regel Jahre im Produktivbetrieb hinter sich. Es bildet Sonderfälle ab, die niemand mehr auf dem Zettel hat: den Kunden mit der abweichenden Rechnungsadresse, die Rabattlogik aus der Messeaktion von 2019, den Export für den einen Großhändler. Diese Fälle stehen nirgends dokumentiert, aber der Code behandelt sie korrekt. Genau deshalb ist Legacy-Software wertvoll und gefährlich zugleich. Wertvoll, weil sie funktioniert. Gefährlich, weil niemand weiß, warum.
Erkennungsmerkmale: Woran du Legacy-Software erkennst
Es gibt harte und weiche Signale. Die weichen hörst du in Meetings: „Da gehen wir lieber nicht ran“, „das kann nur der Kollege“, „wir deployen freitags nie“. Die harten Signale lassen sich prüfen, und sie haben oft ein Datum.
Abgekündigte Frameworks und Plattformen
Das deutlichste Merkmal ist ein Support-Ende des Herstellers. Ein Beispiel aus der App-Entwicklung: Microsoft hat den Support für Xamarin am 1. Mai 2024 beendet, wie die offizielle Xamarin-Seite von Microsoft bestätigt. Seitdem gibt es keine Updates mehr, auch keine Sicherheitskorrekturen. Jede Xamarin-App, die heute noch im Store liegt, läuft auf einem Framework ohne Hersteller. Vergleichbare Fälle gibt es in jeder Technologiefamilie: PHP-Versionen ohne Security-Support, Java-Laufzeiten ohne Updates, Shopsysteme, deren Hersteller die Produktlinie eingestellt hat.
Store-Fristen bei mobilen Apps
Bei mobilen Apps setzen die App-Stores eigene Fristen, die unabhängig vom Framework gelten. Google Play verlangt laut der offiziellen Target-API-Anforderung seit dem 31. August 2026, dass neue Apps und App-Updates mindestens Android 16 (API-Level 36) als Ziel haben. Bestehende Apps müssen mindestens API-Level 35 erreichen, um auf neueren Geräten für neue Nutzer sichtbar zu bleiben. Eine Verlängerung bis zum 1. November 2026 ist auf Antrag möglich.
Apple zieht ähnlich an: Laut der Seite „Upcoming Requirements“ im Apple Developer Portal müssen Apps seit dem 28. April 2026 mit Xcode 26 und dem SDK für iOS 26 gebaut werden, um bei App Store Connect hochgeladen zu werden. Wer eine App auf einem abgekündigten Framework betreibt, kann diese Vorgaben oft nicht mehr erfüllen. Dann wird aus einem technischen Thema ein geschäftliches: Die App lässt sich nicht mehr aktualisieren, und irgendwann verschwindet sie aus dem Store.
Fehlende Tests, fehlendes Wissen, fehlende Umgebung
Die weiteren Merkmale sind weniger datumsgebunden, aber genauso prüfbar. Gibt es automatisierte Tests, und laufen sie in einer CI-Pipeline durch? Existiert eine Entwicklungsumgebung, die ein neuer Kollege in einem Tag aufsetzen kann? Ist bekannt, welche Bibliotheken in welcher Version im Einsatz sind, idealerweise als Software Bill of Materials? Lässt sich ein Release ohne manuelles Kopieren auf den Server ausrollen? Wird eine dieser Fragen mit Nein beantwortet, hat das System Legacy-Anteile, auch wenn es erst drei Jahre alt ist.
Risiken: Was Legacy-Software ein Unternehmen kostet
Die Kosten von Legacy-Software sind selten eine Position in der Bilanz. Sie verstecken sich in Wartungsbudgets, in verschobenen Projekten und in Risiken, die erst dann sichtbar werden, wenn sie eintreten. Vier Bereiche sind besonders relevant.
Sicherheit. Ein System ohne Herstellersupport bekommt keine Patches. Bekannte Schwachstellen bleiben offen, und Angreifer suchen gezielt nach genau solchen Installationen. Der US-Rechnungshof GAO hat das in seinem Bericht GAO-19-471 (2019) an zehn kritischen Altsystemen von US-Behörden dokumentiert: Die Systeme waren zwischen 8 und 51 Jahre alt, eines davon wies zum Stand September 2018 insgesamt 168 Schwachstellen mit hohem oder kritischem Risiko auf, ein anderes lief auf Hardware, die der Hersteller nicht mehr unterstützte.
Compliance. Datenschutz, Barrierefreiheit, Produktsicherheit und branchenspezifische Vorgaben entwickeln sich weiter. Ein System, das sich nicht mehr ändern lässt, kann neue Anforderungen nicht abbilden. Das gilt für die DSGVO genauso wie für Store-Richtlinien oder Anforderungen von Wirtschaftsprüfern an Nachvollziehbarkeit.
Personal. Für abgekündigte Technologien wird der Arbeitsmarkt dünn. Der GAO-Bericht nennt als Beispiel ein COBOL-System des US-Bildungsministeriums und hält fest, dass die Zahl der verfügbaren Fachkräfte mit den nötigen Kenntnissen schrumpft. Dasselbe Muster zeigt sich im Mittelstand bei alten PHP-Frameworks oder proprietären Shop-Lösungen: Die wenigen Entwickler, die das System kennen, werden zum Engpass und zum Klumpenrisiko.
Vendor-Lock-in. Legacy-Systeme hängen oft an einem einzelnen Dienstleister oder Hersteller, der als Einziger den Code kennt oder die Lizenz hält. Dieser Vendor-Lock-in schwächt die Verhandlungsposition und macht jeden Wechsel teuer. Dazu kommt ein indirekter Effekt: Wenn 80 Prozent des IT-Budgets in den Betrieb des Bestands fließen, wie es der GAO-Bericht für die US-Bundesverwaltung beziffert (rund 72 von über 90 Milliarden US-Dollar im Haushaltsjahr 2019), bleibt für Neues kaum Spielraum.
Optionen: Vier Wege im Umgang mit Legacy-Software
Es gibt keine Standardantwort. Die richtige Option hängt davon ab, wie geschäftskritisch das System ist, wie groß der Änderungsbedarf ist und wie viel Wissen noch im Haus liegt. Grundsätzlich stehen vier Wege offen, und oft ist eine Kombination sinnvoll.
| Option | Was passiert | Geeignet, wenn | Typisches Risiko |
|---|---|---|---|
| Weiterbetrieb | System bleibt unverändert, wird abgeschottet und überwacht | Wenig Änderungsbedarf, absehbares Ende, geringe Angriffsfläche | Sicherheitslücken ohne Patch, schleichender Wissensverlust |
| Refactoring | Code wird schrittweise unter Tests gestellt und bereinigt, Funktion bleibt gleich | Fachlogik ist wertvoll, Technologie noch tragfähig, Team vorhanden | Aufwand schwer zu schätzen, sichtbarer Nutzen kommt spät |
| Schrittweise Ablösung | Funktionen werden nacheinander in ein neues System verlagert, Alt und Neu laufen parallel | Großes System, hoher Änderungsbedarf, kein Stillstand möglich | Doppelter Betrieb, Schnittstellen zwischen Alt und Neu |
| Rewrite | Komplette Neuentwicklung, Altsystem wird zum Stichtag abgeschaltet | Kleines, klar abgegrenztes System oder Plattform ohne Zukunft | Verlust unbekannter Fachlogik, lange Phase ohne Releases |
Der Rewrite ist die riskanteste Option
Die vollständige Neuentwicklung klingt verlockend, weil sie den Ballast loswird. In der Praxis ist sie die Option mit der höchsten Ausfallquote. Das bekannteste öffentlich dokumentierte Beispiel liefert Joel Spolsky in seinem Essay „Things You Should Never Do, Part I“ (2000). Netscape entschied sich, den Browser-Code für Version 6.0 komplett neu zu schreiben. Zwischen Version 4.0 und der 6.0-Beta lagen drei Jahre ohne nennenswertes Release, eine Version 5.0 gab es nie. In dieser Zeit verlor Netscape den Browsermarkt an Microsoft. Spolsky nennt den Rewrite den „single worst strategic mistake“, den ein Softwareunternehmen machen kann.
Sein Argument ist bis heute gültig: Was im alten Code wie Unordnung aussieht, sind meist Fehlerkorrekturen aus Jahren echten Betriebs. Wer neu schreibt, wirft dieses Wissen weg und baut die Fehler erneut ein. Ein Rewrite ist deshalb nur dann vertretbar, wenn die Plattform selbst keine Zukunft hat (wie bei Xamarin) oder das System klein genug ist, um es vollständig zu verstehen.
Schrittweise Ablösung als Mittelweg
Für die meisten mittelständischen Systeme ist die schrittweise Ablösung der realistischste Weg. Dabei wird das Altsystem nicht abgeschaltet, sondern Stück für Stück entkernt: Eine neue Komponente übernimmt zuerst eine Funktion, etwa den Produktexport oder die Preisberechnung, und das Altsystem ruft sie über eine Schnittstelle auf. Mit jedem Schritt wandert mehr Logik in die neue Welt, bis das alte System nur noch eine Hülle ist. Dieses Vorgehen ist als „Strangler Fig“-Muster bekannt und hat den Vorteil, dass jeder Schritt einzeln ausgerollt und zurückgenommen werden kann.
Legacy bei mobilen Apps und im Backend: zwei verschiedene Spielarten
Legacy-Software folgt im Backend und bei mobilen Apps unterschiedlichen Regeln, und das verändert die Entscheidung.
Im Backend kontrollierst du die Laufzeitumgebung selbst. Ein alter Dienst auf einem gepflegten Server kann jahrelang weiterlaufen, wenn er abgeschottet ist und nur definierte Schnittstellen nach außen hat. Hier ist Weiterbetrieb mit Monitoring eine legitime Option, und Refactoring lässt sich in kleinen Schritten erledigen, weil niemand außer dem eigenen Team ein Release freigeben muss. Die Gefahr liegt in der Unsichtbarkeit: Ein Backend fällt niemandem auf, bis es ausfällt.
Bei mobilen Apps entscheiden Dritte über die Laufzeit. Apple und Google setzen Fristen für SDK-Versionen, Betriebssystem-Updates ändern Berechtigungsmodelle, und ein abgekündigtes Framework wie Xamarin lässt sich nicht einfach „abschotten“. Die App läuft auf Geräten der Kunden, nicht auf dem eigenen Server. Weiterbetrieb ohne Updates ist deshalb nur eine Frage der Zeit, bis die App aus dem Store fliegt oder auf neuen Geräten abstürzt. Für Apps ist die Frage daher selten ob, sondern wann und wohin migriert wird, etwa zu .NET MAUI, Flutter oder React Native. Die Entscheidung sollte vor der nächsten Store-Frist fallen, nicht danach.
Legacy-Software im Mittelstand: typische Konstellationen
In mittelständischen Unternehmen tritt Legacy-Software in wiederkehrenden Mustern auf. Das Warenwirtschaftssystem, das ein Dienstleister vor zwölf Jahren individuell gebaut hat und das seitdem nur noch „gepflegt“ wird. Der Onlineshop auf einer Plattformversion, deren Hersteller den Support eingestellt hat. Die Außendienst-App, die seit dem Framework-Ende niemand mehr neu bauen kann. Die Excel-Makro-Sammlung, die inzwischen die halbe Produktionsplanung steuert.
Gemeinsam ist diesen Fällen, dass das System zu wichtig ist, um es abzuschalten, und zu unsicher, um es anzufassen. Der erste sinnvolle Schritt ist deshalb nie die Technologieentscheidung, sondern eine Bestandsaufnahme: Welche Fachprozesse hängen am System? Welche Schnittstellen gibt es? Wer kennt den Code? Welche Fristen (Support-Ende, Store-Vorgaben, Lizenzablauf) stehen an? Erst mit diesem Bild lässt sich entscheiden, ob Refactoring, Ablösung oder Rewrite die wirtschaftlich beste Option ist. Eine Position dazu: Wer diese Analyse überspringt und direkt mit dem Rewrite beginnt, wiederholt den Netscape-Fehler im Kleinen.
Abgrenzung: Legacy-Software, technische Schuld, Standard- und Individualsoftware
Technische Schuld beschreibt bewusste oder unbewusste Abkürzungen in der Softwareentwicklung, die später Zinsen in Form von Mehraufwand kosten. Jede Legacy-Software trägt technische Schuld, aber nicht jede technische Schuld macht ein System zu Legacy. Ein junges Projekt kann hohe Schulden haben und trotzdem gut testbar und gut verstanden sein. Legacy-Software ist der Zustand, in dem die Schuld so hoch ist, dass Änderungen nicht mehr sicher möglich sind.
Standardsoftware ist ein Produkt, das ein Hersteller für viele Kunden entwickelt und pflegt. Sie wird zu Legacy, wenn der Hersteller die Version oder das Produkt abkündigt, wie bei Xamarin. Der Kunde kann dann meist nichts selbst reparieren, weil er den Quellcode nicht besitzt. Die einzige Option ist das Upgrade auf die Nachfolgeversion oder der Wechsel zu einem anderen Produkt.
Individualsoftware wird speziell für ein Unternehmen entwickelt. Sie wird zu Legacy, wenn Wissen, Tests oder das Entwicklerteam verloren gehen, oder wenn die zugrunde liegende Technologie ihr Support-Ende erreicht. Anders als bei Standardsoftware liegt der Quellcode beim Unternehmen, sodass Refactoring und schrittweise Ablösung möglich sind. Das ist der wesentliche Vorteil, aber nur, wenn das Unternehmen die Verantwortung auch wahrnimmt.
Häufige Fragen zu Legacy-Software
Ab wann gilt Software als Legacy?
Es gibt keine Altersgrenze. Software gilt als Legacy, wenn sie produktiv im Einsatz ist, aber nicht mehr sicher geändert werden kann: weil Tests fehlen, weil das Wissen über die Fachlogik verloren ist oder weil Framework oder Plattform vom Hersteller abgekündigt wurden. Nach Michael Feathers reicht schon das Fehlen von Tests, damit Code als Legacy gilt.
Sollte man Legacy-Software immer ersetzen?
Nein. Ein System, das stabil läuft, wenig Änderungen braucht und abgeschottet betrieben werden kann, darf weiterlaufen. Ersetzen oder ablösen solltest du, wenn Sicherheitsupdates ausbleiben, neue Anforderungen nicht mehr umsetzbar sind oder nur noch eine Person das System kennt. Ein kompletter Rewrite ist dabei die riskanteste Option; eine schrittweise Ablösung ist meist der sicherere Weg.
Was ist der Unterschied zwischen Legacy-Software und technischer Schuld?
Technische Schuld ist die Summe der Abkürzungen im Code, die später Mehraufwand kosten. Legacy-Software ist ein Zustand: Die Schuld ist so hoch oder das Umfeld so veraltet, dass Änderungen nicht mehr sicher möglich sind. Technische Schuld kann man abbauen, bevor ein System zu Legacy wird; bei Legacy-Software ist der Abbau selbst zum Risiko geworden.