Altsysteme und Legacy Systeme

Man möchte sie loswerden und kann sich doch jahrzehntelang nicht von ihnen trennen. Altsysteme sind weit verbreitet und lassen sich nur schwer ablösen.

Was gestern noch stabil lief, wird heute zum Bremsklotz für Innovation und Wachstum.

1. Was ist ein Altsystem?

Ob eine Anwendung ein Altsystem (engl. Legacy System) ist, hängt nicht in erster Linie vom Alter ab. Es gibt keine feste Grenze, ab wann ein System als „alt“ gilt. Manche Systeme könnte man sogar bereits kurz nach ihrer Fertigstellung als Altsystem einordnen. Andere bleiben lange frisch und flexibel.

Was genau macht ein Altsystem aus?

Entscheidend ist weniger das Alter als vielmehr der Zustand des Systems und seines technologischen Umfelds. Grundsätzlich lassen sich zwei Kategorien unterscheiden:

Wird eine Software vom Hersteller nicht mehr weiterentwickelt oder unterstützt, kann man in der Regel von einem Altsystem sprechen. Fehlende Updates und Support führen zwangsläufig zu steigenden Risiken im Betrieb.

Aber auch aktiv gepflegte Produkte können Eigenschaften von Altsystemen aufweisen. Entscheidend ist nicht nur der Supportstatus, sondern auch die Integrations- und Betriebsfähigkeit.

Typische Merkmale sind:

• umständliche und veraltete Benutzeroberfläche
• fehlende moderne Schnittstellen (z. B. APIs)
• eingeschränkte Integration in zentrale Benutzer- und Identity-Systeme
• begrenzte Betriebsfähigkeit, z. B. fehlende Container-Unterstützung
• mangelnde Integration in Monitoring, Logging und Tracing

Bei selbst entwickelten Systemen ist die Bewertung komplexer. Hier sprechen mehrere Faktoren dafür, dass es sich um ein Altsystem handelt:

• Zentrale Technologien (Plattform, Programmiersprache, Datenbank) werden nicht mehr weiterentwickelt
• Technologien sind veraltet oder nicht mehr kompatibel
• Architektur und Code erschweren Änderungen erheblich
• Know-how und Fachpersonal sind schwer verfügbar
• Im Unternehmen fehlt Wissen zur Wartung und Weiterentwicklung

Ein Altsystem ist eine Frage der Wartbarkeit, Weiterentwickelbarkeit und Zukunftsfähigkeit.

2. Probleme von Altsystemen

Muss wirklich jedes System dem neuesten Hype folgen? Warum betreibt man Altsysteme nicht einfach weiter?

Tatsächlich laufen Systeme oft über ihr eigentliches Haltbarkeitsdatum hinaus weiter. Das ist nachvollziehbar und in vielen Fällen sinnvoll, schließlich erfüllen sie ihren Zweck.

Die Probleme entstehen nicht plötzlich, sondern schleichend.

2.1 Systeme altern, schleichend und kontinuierlich

Fast jede Anwendung startet mit moderner Technologie und einer klaren Architektur. Doch ab Version 1.0 beginnt der schleichende Wandel. Neue Anforderungen entstehen, für die das System ursprünglich nie gedacht war. Funktionen werden unter Zeitdruck umgesetzt, Budgets sind knapp.

Die Folge: steigende Komplexität und eine zunehmend fragile Struktur.

Dieser Prozess wird häufig als Software Erosion bezeichnet. Es sammelt sich zunehmend technische Schulden (Technical Debt) an.

Wenn Refactorings ausbleiben, verschärft sich die Situation weiter. Änderungen werden schwieriger, Fehler treten häufiger auf und Innovation wird gebremst.

Refactoring wirkt wie eine Verjüngungskur. Systeme, die regelmäßig überarbeitet werden, können über viele Jahre stabil und flexibel bleiben. In der Praxis fehlt dafür jedoch oft die Zeit und das Budget.

2.2 Technologien altern

Nicht nur der Code, sondern auch die verwendeten Technologien unterliegen einem Lebenszyklus.

Einzelne Bibliotheken oder Frameworks lassen sich meist noch relativ einfach austauschen. Kritisch wird es bei zentralen Komponenten wie:

• Programmiersprachen
• Plattformen und Frameworks
• Middleware
• Datenbanken
• Laufzeitumgebungen

Hier entstehen technologische Abhängigkeiten (Vendor Lock-in), die eine Weiterentwicklung erschweren.

Migrationen werden dadurch aufwendig, teuer und riskant. Mit zunehmendem Alter der Technologien verschärft sich die Situation weiter. Bis ein vormals stabiles System zu einem operativen Risiko wird.

2.3 Kritischer Punkt: End of Life (EOL)

Irgendwann erreicht jedes System einen Punkt, an dem zentrale Technologien nicht mehr aktiv weiterentwickelt werden. Dieser Zustand wird als End of Life (EOL) bezeichnet.

Ab diesem Zeitpunkt entfallen:

• Sicherheitsupdates
• Herstellersupport
• Weiterentwicklung und neue Features

Auch das verfügbare Know-how am Markt nimmt zunehmend ab.

Typische Beispiele für EOL sind:

• Programmiersprachen (COBOL)
• veraltete Plattformen oder alte Betriebssysteme
• 16- oder 32-Bit-Windows-Anwendungen
• nicht mehr gepflegte Middleware (z.B. Apache ServiceMix)
• UI Bibliotheken
• Build und CI/CD Systeme (ant)

Ab diesem Zeitpunkt wird ein vormals stabiles System zu einem operativen Risiko:

• Sicherheitslücken können nicht mehr geschlossen werden
• Compliance-Anforderungen werden nicht erfüllt
• Ausfälle lassen sich schwer beheben

2.4 Engpassfaktor Schnittstelle

Moderne Systeme sind API-getrieben und stark vernetzt. Altsysteme hingegen bieten häufig nur eingeschränkte oder proprietäre Schnittstellen.

Typische Probleme sind:

• fehlende oder unzureichende APIs
• proprietäre oder veraltete Protokolle
• fehlende Echtzeitfähigkeit

Gerade die fehlende Echtzeitfähigkeit ist in vielen Szenarien ein zentrales Problem. Moderne Anwendungen erwarten, dass Datenänderungen sofort verfügbar sind. Nicht erst zeitverzögert über nächtliche Batch-Verarbeitung oder Dateiexporte.

Das betrifft insbesondere Stammdatenabgleiche und ereignisgetriebene Prozesse.

Moderne Architekturen erfordern eine gewisse Offenheit der beteiligten Systeme, typischerweise in Form von:

• gut dokumentierten APIs (z. B. über OpenAPI)
• Webhooks für Ereignisse
• Anbindungen an Messaging-Systeme

Fehlt diese Offenheit, wird das Altsystem zum Engpass in der Gesamtarchitektur.

3 Wirtschaftliche Auswirkungen von Altsystemen

Neben den technischen Problemen haben Altsysteme direkte wirtschaftliche Auswirkungen auf Unternehmen.

Typische Folgen sind:

• Steigende Betriebskosten
  Wartung, Betrieb und Support werden mit zunehmendem Alter aufwendiger und teurer.
• Erhöhtes Ausfallrisiko
  Veraltete Technologien und fehlender Support erhöhen die Wahrscheinlichkeit von Störungen und Ausfällen.
• Gebremstes Wachstum
  Neue Geschäftsanforderungen lassen sich nur langsam oder gar nicht umsetzen.
• Eingeschränkte Innovationsfähigkeit
  Neue Produkte, Services oder digitale Geschäftsmodelle lassen sich nur langsam umsetzen.
• Abhängigkeit von Schlüsselpersonen
  Wissen ist häufig nur bei wenigen Experten vorhanden.
• Fehlallokation von IT-Ressourcen
  Ein großer Teil der IT-Kapazität wird für den Betrieb und die Pflege bestehender Systeme gebunden, statt für Innovation und Wachstum eingesetzt zu werden.

4. Altsysteme bergen Schätze

Altsysteme sind nicht nur ein Problem. Sie sind ein wertvoller Schatz, den es zu nutzen gilt. In ihnen steckt über Jahre gewachsenes Wissen, das man nicht verlieren möchte.

• Geschäftsprozesse sind präzise abgebildet
• Fachliche Logik wurde über lange Zeit optimiert
• Systeme sind tief in die Abläufe des Unternehmens integriert

Dieses Wissen ist selten dokumentiert, sondern steckt im System selbst.

Bei einer Modernisierung oder Neuimplementierung ist es entscheidend, dieses Wissen zu bewahren und gezielt zu übertragen. Häufig ist die Fachlogik im Altsystem genauer und vollständiger implementiert als in jeder Dokumentation. Eine naive Neuentwicklung ohne Analyse führt daher oft zu funktionalen Lücken.

5. Technologien in Altsystemen

Bei der Modernisierung von Altsystemen begegnet man immer wieder typischen Technologien und Systemen, die in vielen Unternehmen seit Jahren oder sogar Jahrzehnten im Einsatz sind.

5.1 XML, SOAP und Web Services

Die 2000er Jahre wurden stark von XML-basierten Technologien und Formaten geprägt. In dieser Zeit entstanden viele Systeme, die bis heute im Einsatz sind.

Typische Bausteine dieser Architekturen sind:

• XML als zentrales Datenformat
• SOAP-basierte Web Services
• komplexe Schema-Definitionen
• Transformation mit XSLT-Stylesheets

Diese Technologien wurden entwickelt, um strukturierte Daten zwischen Systemen auszutauschen. Der Fokus lag auf Standardisierung, Validierung und formale Korrektheit. Heute werden sie in vielen Fällen als schwergewichtig und wenig flexibel wahrgenommen. Insbesondere im Vergleich zu modernen Ansätzen wie REST und JSON wirken XML- und SOAP-basierte Lösungen komplex und aufwendig in der Umsetzung.

Dennoch sind sie weiterhin weit verbreitet:

• in großen Unternehmen
• im öffentlichen Sektor
• in langfristig gewachsenen Integrationslandschaften

Randnotiz: Ist XML veraltet?

XML selbst ist nicht veraltet.

Im Gegensatz zu JSON ist XML keine Sprache zur Serialisierung von Objekten, sondern eine Markup Language zur Beschreibung strukturierter Daten. XML bietet Eigenschaften, die in bestimmten Szenarien weiterhin relevant sind:

• Erweiterbarkeit von Grammatiken (z. B. über XML-Schema, Namespaces)
• Kombinierbarkeit unterschiedlicher Sprachen (XML-Dialekte)
• Unterstützung komplexer Dokumentstrukturen, bei denen stark und weniger stark strukturierte Inhalte kombiniert werden
• klare Trennung von Struktur und Inhalt

Gerade bei komplexen, dokumentenorientierten oder stark standardisierten Anwendungsfällen kann XML weiterhin sinnvoll sein.

Für viele moderne Anwendungsfälle haben sich jedoch schlankere Alternativen wie JSON und YAML durchgesetzt. Sie sind einfacher zu verarbeiten, verursachen weniger Overhead und lassen sich leichter in moderne Architekturen integrieren.

5.2 Protokolle: X.400, FTP und OFTP

Im elektronischen Datenaustausch sind häufig noch ältere Protokolle im Einsatz:

• X.400
• FTP, OFTP

Diese Protokolle gelten heute als veraltet, sind aber in vielen Unternehmen weiterhin fest etabliert.

Ein Grund dafür ist, dass sie Funktionen bieten, die moderne Alternativen nicht immer direkt abbilden. Dazu gehören insbesondere:

• verbindliche Empfangsbestätigungen
• zuverlässige Zustellmechanismen
• etablierte Standards im B2B-Datenaustausch

Gerade in Bereichen wie Logistik, Industrie oder Finanzwesen sind diese Eigenschaften für Geschäftsprozesse essenziell.

Bei einer Migration müssen diese Funktionen bewusst berücksichtigt und gezielt ersetzt werden. Andernfalls drohen funktionale Lücken oder Probleme in bestehenden Abläufen.

5.3 Datenformate

Formate wie Electronic Data Interchange (EDI) sind nach wie vor weit verbreitet.

EDI-Dokumente sind für Menschen ohne spezielle Werkzeuge kaum lesbar und oft schwer zu verarbeiten. Die Erweiterbarkeit ist eingeschränkt und führt in der Praxis häufig zu Kompromissen, etwa durch kreative Zweckentfremdung vorhandener Felder.

Gleichzeitig sind diese Formate tief in Lieferketten und B2B-Prozesse integriert. Sie bilden etablierte Geschäftsprozesse ab und sind oft Voraussetzung für die Zusammenarbeit mit Partnern.

Eine Ablösung ist daher selten kurzfristig möglich und erfordert in der Regel eine schrittweise Migration.

Diese Technologien sind nicht isoliert zu betrachten. In modernen Architekturen müssen sie häufig mit REST-APIs, Event-Streaming oder Cloud-Plattformen kombiniert werden. Genau hier entstehen die größten Herausforderungen.

6. Unser Angebot

Wir unterstützen euch dabei, Altsysteme zu analysieren, sicher zu betreiben und schrittweise zu modernisieren. Von der Integration über API-Gateways bis hin zur Migration in moderne Architekturen.

Ohne die bestehende Stabilität und das enthaltene Fachwissen zu gefährden.