Legacy-System
Was ein Legacy-System ausmacht, welche drei Spielarten in ERP-Projekten vorkommen und was daraus für die ERP-Auswahl folgt
Kernaussagen
- Ein Legacy-System erkennt man nicht am Alter. Entscheidend ist, dass es die heutigen Anforderungen nicht mehr trägt und sich nur mit unverhältnismäßigem Aufwand ändern lässt [1][2].
- In ERP-Projekten begegnen uns drei Spielarten: überangepasste Systeme, lange nicht aktualisierte Systeme und überholte Individualsoftware. Jede hat eine andere Ursache und legt einen anderen Weg nahe.
- Wer die Ursache nicht abstellt, nimmt sie ins neue System mit. Wird dort wieder jede Abweichung programmiert, steht nach einigen Jahren das nächste überangepasste System.
- Vor der Auswahl steht deshalb die Frage, welche Funktionen des Altsystems wirklich gebraucht werden. Wer das alte System im neuen nachbaut, übernimmt auch Verhalten, das niemand mehr braucht [4].
Die Definitionen setzen unterschiedliche Schwerpunkte
„Legacy“ heißt wörtlich Erbe. Im Deutschen sind Altsystem und Bestandssystem gebräuchlich. Als Fachbegriff ist das Wort weitgehend wertfrei, umgangssprachlich schwingt die Altlast mit [3]. Eine frühe Definition stammt aus der Forschung zur Migration solcher Systeme in den 1990er-Jahren. Sie beschreibt das Dilemma, das bis heute gilt: Legacy-Systeme tragen den Betrieb und bremsen zugleich jede Veränderung [1].
| Quelle | Definition (sinngemäß übersetzt) | Schwerpunkt |
|---|---|---|
| Brodie und Stonebraker, wiedergegeben bei Bisbal u. a. [1] | Jedes Informationssystem, das sich Änderung und Weiterentwicklung erheblich widersetzt | Veränderbarkeit |
| Rosenkranz, Staegemann, Volk und Turowski, IEEE Access 2024 [2] | Meist geschäftskritische Systeme, die vor Jahren entwickelt wurden und sich der Weiterentwicklung erheblich widersetzen. Die Autoren trennen das chronologische Alter eines Systems von seiner tatsächlichen Veralterung | Alter gegen Veralterung |
| Wikipedia, Artikel Altsystem [3] | Eine etablierte, historisch gewachsene Anwendung im Bereich der Unternehmenssoftware | Herkunft und Wortsinn |
| ERP-Glossar von Find-Your-ERP | Ein eingesetztes System, das technisch nicht mehr dem aktuellen Stand entspricht oder die heutigen Anforderungen des Unternehmens nicht mehr erfüllt | Technik und Anforderungen |
Die Forschung setzt bei der Veränderbarkeit an, Wikipedia bei der Herkunft, das Glossar bei den Anforderungen des Unternehmens. Einig sind sich die Quellen darin, dass ein Legacy-System im Einsatz ist und gebraucht wird. Ein abgeschaltetes System ist keines mehr.
Unser Verständnis
Wir sprechen von einem Legacy-System, wenn ein eingesetztes System technisch nicht mehr dem aktuellen Stand entspricht oder die heutigen Anforderungen nicht mehr erfüllt und sich nur mit unverhältnismäßigem Aufwand dorthin bringen lässt. Ein altes System, das passt und gepflegt wird, gehört nicht dazu. In ERP-Projekten unterscheiden wir drei Spielarten: das überangepasste System, das stehengebliebene System und die überholte Individualsoftware. Die Unterscheidung lohnt sich, weil jede Spielart eine andere Ursache hat und davon abhängt, welcher Weg naheliegt. Häufig ist ein solches Altsystem der Anlass für eine ERP-Auswahl. Die Kurzdefinition steht im Glossar unter Legacy-System.
Drei Spielarten von Legacy-Systemen haben verschiedene Ursachen
Die Spielarten treten oft gemeinsam auf, etwa wenn ein lange nicht aktualisiertes ERP zugleich stark angepasst ist. Für die Entscheidung lohnt es sich trotzdem, sie getrennt zu betrachten.
Das überangepasste System
An diesem System wurde über die Jahre so viel angepasst, dass es sich kaum noch weiterentwickeln lässt; in Projekten heißt es dann „verbastelt“. Gemeint sind Anpassungen über die reine Konfiguration hinaus, bis hin zu Eingriffen in den Systemkern (siehe Glossar, Customizing). Je tiefer der Eingriff, desto höher der Aufwand bei jedem Update. Die Anzeichen sind deutlich: Updates werden verschoben, weil jede neue Version die Eigenprogramme brechen kann, und was die Anpassungen genau tun, wissen nur wenige Personen in der IT oder beim Partner.
Die Ursache liegt selten in der Technik. Meist wurde jede Abweichung vom Standard programmiert, statt den Prozess zu prüfen. Wie sich Anpassungen nach ihrer Tiefe unterscheiden und wann sich eine lohnt, beschreibt der Beitrag zum ERP-Customizing. Eine Literaturstudie von Abendroth, Bender und Gronau zeigt, wohin sich die Anpassung von ERP-Systemen verschoben hat: von Änderungen am Programmcode in On-Premise-Systemen zu Anpassungen über Schnittstellen und Integration in Cloud-ERP-Systemen [7]. Überangepasste Systeme stammen deshalb meist aus der On-Premise-Zeit, und ihre Eingriffe in den Code lassen sich in ein Cloud-ERP nicht einfach mitnehmen.
Das stehengebliebene System
Dieses System wurde lange nicht mehr angefasst: kein Release-Wechsel seit Jahren, oft eine Version, für die der Hersteller die Wartung beendet hat oder bald beendet. Das Alter allein ist dabei nicht das Problem. Rosenkranz und Koautoren unterscheiden ausdrücklich das chronologische Alter eines Systems von seiner tatsächlichen Veralterung [2]. Zum Legacy-System wird ein stehengebliebenes ERP, wenn sich der Abstand zur aktuellen Version, zu neuen Anforderungen und zu angebundenen Systemen nicht mehr mit vertretbarem Aufwand schließen lässt.
Neue Anforderungen wie elektronische Rechnungen oder ein Webshop lassen sich dann nur über Zusatzlösungen abbilden, und Schnittstellen zu neueren Systemen fehlen. Spätestens wenn es für Betriebssystem oder Datenbank keine Sicherheitsupdates mehr gibt, wird aus dem Abstand ein Risiko. Ein bekanntes Beispiel für eine solche Frist ist das Wartungsende von SAP ECC, siehe SAP ECC ablösen.
Die überholte Individualsoftware
Viele betriebliche Systeme waren früher Eigenentwicklungen, etwa auf IBM AS/400, die seitdem schrittweise abgelöst werden. Individualsoftware wird für die Anforderungen eines einzelnen Unternehmens entwickelt, vom Unternehmen selbst oder im Auftrag (siehe Glossar, Individualsoftware). Zum Legacy-System wird sie, wenn sie nicht mehr dem heutigen Stand entspricht. Typisch ist, dass die Regeln nur im Programmcode stehen und nur wenige Personen diesen Code kennen. Jede neue Anforderung kommt dann über genau diese Personen ins System.
Die Plattform ist dabei oft nicht das Problem. IBM hat die AS/400 1988 eingeführt, ihr Betriebssystem heißt seit 2008 IBM i [5] und wird weiterentwickelt; die Version 7.6 hat IBM im April 2025 angekündigt [6]. Veraltet ist in solchen Fällen die Anwendung, die darauf läuft.
Im Beispiel stecken zwei Spielarten in einem Unternehmen
Ein Hersteller von Industriearmaturen mit rund 250 Beschäftigten will wissen, ob er sein ERP aktualisieren oder ersetzen soll. Die Bestandsaufnahme ergibt zwei Systeme mit Handlungsbedarf:
| System | im Einsatz seit | Zustand heute | Spielart |
|---|---|---|---|
| ERP-Standardsoftware im eigenen Rechenzentrum | 2011 | letzter Release-Wechsel 2016; eigene Preisfindung für Sonderwerkstoffe, geänderte Auftragsmasken, Dutzende Eigenprogramme im Systemkern | stehengeblieben und überangepasst |
| Eigenentwicklung auf IBM i für Prüfmittel und Prüfprotokolle | Ende der 1990er-Jahre | betreut von einem Mitarbeiter, der in zwei Jahren in den Ruhestand geht; die Prüfregeln stehen nur im Programmcode | überholte Individualsoftware |
Lehrbeispiel, kein Kundenprojekt.
Beim ERP hilft ein Release-Wechsel allein nicht. Die Eigenprogramme müssten für die neue Version geprüft und nachgezogen werden, und der Wechsel käme einer Neueinführung nahe, wie es das Glossar unter Release-Wechsel für große Versionssprünge beschreibt. Die Liste der Anpassungen zerfällt in drei Gruppen. Ein Teil wird nicht mehr genutzt, einen Teil deckt eine aktuelle Standardsoftware ohne Anpassung ab, und wenige Anpassungen bilden echte Besonderheiten des Geschäfts, etwa die Preisfindung für Sonderwerkstoffe. Nur diese gehen als Anforderung in die Auswahl.
Bei der Prüfmittelverwaltung geht es zuerst um Wissen. Bevor ein neues System gewählt wird, schreibt der betreuende Mitarbeiter die Prüfregeln gemeinsam mit der Qualitätssicherung auf. Danach ist zu entscheiden, ob das neue ERP die Aufgabe übernimmt oder eine spezialisierte Software angebunden wird. Bis dahin bleibt die Eigenentwicklung über eine Schnittstelle in Betrieb. In einem Projekt stehen damit zwei Entscheidungen an, die verschiedene Fragen beantworten.
Die Spielart bestimmt den naheliegenden Weg
| Spielart | naheliegender Weg | worauf es ankommt |
|---|---|---|
| Überangepasstes System | Neueinführung nahe am Standard; ein Release-Wechsel käme oft einer Neueinführung gleich | jede Anpassung einzeln bewerten und nur übernehmen, was Geschäftswert hat, möglichst über Konfiguration oder vorgesehene Erweiterungen |
| Stehengebliebenes System | Release-Wechsel, wenn das System fachlich noch passt; sonst Neuauswahl | Abstand zur aktuellen Version, Wartungsende, ein Plan für regelmäßige Releases nach dem Wechsel |
| Überholte Individualsoftware | Standardsoftware, häufig schrittweise eingeführt | Regeln aus dem Code dokumentieren, Übergangsschnittstellen planen, Daten exportierbar machen |
Einordnung von Find-Your-ERP.
Im Einzelfall entscheiden Strategie, Technik, Mitarbeitende und Gesamtkosten, ob ein Upgrade noch trägt oder eine Neueinführung der bessere Weg ist. Diese Abwägung beschreibt der Beitrag ERP-Upgrade oder Ablösung, eine erste Einordnung gibt der Upgrade-oder-Ablösung-Check.
Für Individualsoftware und große Altsysteme mit vielen Verbindungen bietet sich die schrittweise Ablösung an. Martin Fowler beschreibt sie mit dem Bild der Würgefeige: Neue Funktionen entstehen neben dem Altsystem, und nach und nach wandert Verhalten aus dem Altsystem in das neue, bis das alte abgeschaltet werden kann [4]. Fowler warnt dabei vor dem scheinbar einfachen Plan, das alte System in neuer Technik nachzubauen. Das bestehende Verhalten ist im Detail schwer zu erfassen, und vieles davon wird gar nicht mehr gebraucht [4]. Wie sich eine solche Ablösung beschaffen und vertraglich absichern lässt, beschreibt find-your-software.de unter Legacy-Systeme ablösen.
Ein altes System ist nicht automatisch ein Legacy-System
In Gesprächen über Altsysteme begegnen uns drei Irrtümer immer wieder.
Der erste setzt Alter mit Legacy gleich. Ein ERP, das seit fünfzehn Jahren läuft, regelmäßig aktualisiert wird und zu den Prozessen passt, muss nicht abgelöst werden. Umgekehrt kann ein wenige Jahre altes System zum Legacy-System werden, wenn es stark angepasst wurde und kein Release mehr mitmacht. Alter und Veralterung sind zwei verschiedene Dinge [2].
Der zweite lautet, ein neues System löse das Problem von selbst. Beim überangepassten System lag die Ursache in der Gewohnheit, jede Abweichung zu programmieren. Ohne eine Regel, welche Anpassungen zulässig sind und wer darüber entscheidet, entsteht im neuen System nach einigen Jahren dasselbe Bild. Hersteller begrenzen Eingriffe in den Kern inzwischen bewusst; bei SAP heißt das Prinzip Clean Core (siehe Glossar, Clean Core). Die Regel im eigenen Haus ersetzt das nicht.
Der dritte: Ablösen heißt, alles an einem Stichtag umzustellen. Bei einem einzelnen ERP mit klaren Grenzen ist der Stichtag oft der einfachere Weg. Bei Altsystemen mit vielen Verbindungen kann es sinnvoller sein, Bereich für Bereich umzustellen und das Altsystem eine Zeit lang angebunden zu lassen (siehe Glossar, Big Bang oder Rollout). Die Übergangsschnittstellen müssen dann gebaut und bis zur Abschaltung betrieben werden.
Release-Wechsel, Customizing und Individualsoftware meinen etwas anderes
Drei Begriffe fallen fast immer zusammen mit dem Legacy-System, und keiner davon meint das Altsystem selbst.
| Begriff | Was gemeint ist | Bezug zum Legacy-System |
|---|---|---|
| Release-Wechsel / Upgrade | Umstieg auf eine neuere Version desselben ERP-Systems | Weg aus dem stehengebliebenen System, solange es fachlich passt |
| Customizing | Anpassungen über die reine Konfiguration hinaus, bis zu Eingriffen in den Systemkern | in großer Menge und Tiefe die Ursache des überangepassten Systems |
| Individualsoftware | Software für die Anforderungen eines einzelnen Unternehmens, selbst oder im Auftrag entwickelt | wird zum Legacy-System, wenn sie nicht mehr dem heutigen Stand entspricht |
Begriffe nach dem ERP-Glossar von Find-Your-ERP.
Customizing ist für sich kein Fehler. Eine Anpassung, die eine echte Besonderheit des Geschäfts abbildet und an einem vorgesehenen Erweiterungspunkt sitzt, übersteht auch Updates. Zum Problem wird die Summe vieler tiefer Eingriffe, für die niemand mehr den Überblick hat.
In der Auswahl zählt, was vom Altsystem wirklich gebraucht wird
Ein Altsystem ist für die Auswahl eine wertvolle Quelle, solange niemand es zur Vorlage erklärt. Es zeigt die Besonderheiten des Geschäfts und enthält ebenso viele Gewohnheiten. Beides trennt eine Fit-Gap-Analyse, die nach Geschäftswert fragt und nicht nach dem bisherigen Ablauf. In Demo und Angebot helfen diese Prüffragen:
| Prüffrage | Woran Sie es erkennen |
|---|---|
| Welche Anpassungen des Altsystems werden noch genutzt und bringen Geschäftswert? | Eine Liste der Anpassungen mit ihrer Nutzung liegt vor; nur bewertete Anpassungen stehen als Anforderung im Katalog |
| Lassen sich die verbleibenden Besonderheiten ohne Eingriff in den Kern abbilden? | Der Anbieter zeigt die Lösung in der Demo über Konfiguration, vorgesehene Erweiterungspunkte oder eine Anwendung daneben |
| Welche Regeln stecken nur im Code des Altsystems? | Die Regeln sind vorab beschrieben und werden in der Demo mit echten Fällen nachgestellt, im Beispiel die Preisfindung für Sonderwerkstoffe |
| Wie kommen die Daten aus dem Altsystem? | Exportweg und Testmigration stehen im Angebot, auch für Datenbanken älterer Plattformen |
| Kann das Altsystem eine Zeit lang angebunden bleiben? | Übergangsschnittstellen, ihre geplante Laufzeit und ihr Betrieb sind im Angebot beschrieben |
| Wie bleibt das neue System aktuell? | Release-Takt, Testverfahren für Erweiterungen und die Leistung des Partners bei jedem Release sind festgelegt |
Häufige Fragen
Ist ein Legacy-System dasselbe wie technische Schulden?
Nein. Die Schulden-Metapher für Software stammt von Ward Cunningham: Unausgereiften Code auszuliefern sei wie eine Schuld aufzunehmen, und jede Minute an nicht ganz richtigem Code zähle als Zins [8]. Legacy-Systeme tragen meist viele solcher Schulden. Ein System kann aber technisch sauber gebaut und trotzdem fachlich überholt sein, etwa wenn sich das Geschäftsmodell geändert hat.
Kann auch ein Cloud-ERP zum Legacy-System werden?
Ja, aber an anderer Stelle. Den Release-Wechsel des Kerns übernimmt der Anbieter, angepasst wird in Cloud-ERP-Systemen vor allem über Schnittstellen und Integration [7]. Veralten können deshalb die Erweiterungen, Schnittstellen und Anwendungen daneben, wenn niemand sie bei jedem Release prüft und pflegt.
Wie findet man heraus, wie viel Anpassung in einem ERP steckt?
Über eine Bestandsaufnahme: Welche eigenen Programme, Felder und Tabellen gibt es, welche Standardobjekte wurden geändert, und welche davon werden noch genutzt? Die Liste erstellen die IT oder der Partner mit den Werkzeugen des Systems, die Nutzung zeigen Protokolle und Gespräche mit den Fachbereichen. Erst mit der Nutzung lässt sich bewerten, was in ein neues System gehört.
Was tun, wenn nur noch eine Person das Altsystem versteht?
Das Wissen sichern, bevor über das neue System entschieden wird. Die Person beschreibt gemeinsam mit den Fachbereichen die Regeln, die das System anwendet, und spielt typische Fälle mit echten Daten durch. Sie gehört ins Auswahlprojekt, weil sie Sonderfälle kennt, die in keinem Anforderungskatalog stehen.
Weiterlesen
Kurzdefinitionen zu Legacy-System, Individualsoftware, Release-Wechsel und Customizing.
Wie sich Upgrade und Neueinführung nach Strategie, Technik, Mitarbeitenden und Gesamtkosten abwägen lassen.
Sieben Fragen zum bestehenden ERP und eine erste Einordnung, ob Modernisierung oder Wechsel naheliegt.
Das Stufenmodell von der Konfiguration bis zur Kernmodifikation und ein Schema, mit dem sich jede Anpassung bewerten lässt.
Wartungsfristen von SAP ECC und die Frage, ob S/4HANA oder eine Alternative besser zum Unternehmen passt.
Sourcing-Strategie für den Systemwechsel, von der schrittweisen Ablösung bis zur Wahl des Partners.
Quellen
[1] Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J.; Wade, V.; Richardson, R.; O’Sullivan, D. (1997): A Survey of Research into Legacy System Migration. Technical Report TCD-CS-1997-01, Trinity College Dublin. Die Definition geht dort zurück auf Brodie, M.; Stonebraker, M. (1995): Migrating Legacy Systems. Morgan Kaufmann. Abgerufen am 9. November 2026.
[2] Rosenkranz, S.; Staegemann, D.; Volk, M.; Turowski, K. (2024): Explaining the Business-Technological Age of Legacy Information Systems. IEEE Access 12, S. 84579–84611.
[3] Wikipedia: Altsystem. Stand 2. Juli 2026, abgerufen am 9. November 2026.
[4] Fowler, M. (2024): Strangler Fig. martinfowler.com, 22. August 2024. Abgerufen am 9. November 2026.
[5] Eberhard, J.: Getting started with IBM i. IBM Developer. Abgerufen am 9. November 2026.
[6] IBM (2025): IBM i Support Roadmap and Service Extension Information. Stand 8. April 2025. Abgerufen am 9. November 2026.
[7] Abendroth, A.; Bender, B.; Gronau, N. (2024): The Evolution of Original ERP Customization: A Systematic Literature Review of Technical Possibilities. Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024), S. 17–27.
[8] Cunningham, W. (1992): The WyCash Portfolio Management System. OOPSLA ’92 Experience Report, 26. März 1992. Abgerufen am 9. November 2026.
Herstellerquellen belegen allgemeine Prinzipien und sind keine Produktempfehlung.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihr Altsystem mit einem ERP-Berater
Im Gespräch ordnen Sie mit einem Berater ein, welche Spielart Ihr Altsystem hat und welcher Weg sich daraus ergibt. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.