Legacy-Software modernisieren: schrittweise oder neu bauen?

Eine Legacy-Software sollte selten allein wegen ihres Alters ersetzt werden. Entscheidend ist, ob sie Geschäftsprozesse zuverlässig trägt, Änderungen noch vertretbar ermöglicht und sicher mit anderen Systemen zusammenarbeitet. In den meisten Fällen ist eine schrittweise Modernisierung die risikoärmere Wahl; ein Neubau ist sinnvoll, wenn Architektur, Datenmodell und Bedienkonzept die nötigen Veränderungen dauerhaft blockieren.

Die eigentliche Frage: Was bremst das Geschäft?

„Legacy“ bedeutet nicht einfach „alt“. Ein seit Jahren betriebenes System kann stabil, fachlich wertvoll und wirtschaftlich sinnvoll sein. Problematisch wird es, wenn Wissen nur noch bei einzelnen Personen liegt, Änderungen unverhältnismäßig aufwendig werden oder Mitarbeitende wiederholt mit Excel-Dateien, E-Mails und manuellen Übertragungen ausweichen müssen.

Für Geschäftsführer und operative Teams ist deshalb nicht das verwendete Framework die erste Entscheidungsgrundlage. Wichtiger sind konkrete Folgen im Alltag: Können neue Leistungen, Preise oder Freigaberegeln zeitnah abgebildet werden? Sind Daten zwischen Vertrieb, Abrechnung und Operations widerspruchsfrei? Lassen sich Fehler nachvollziehen und korrigieren? Und kann das Unternehmen den Betrieb weiterführen, wenn externe Abhängigkeiten oder einzelne Schlüsselpersonen wegfallen?

Eine technische Bestandsaufnahme übersetzt diese Beobachtungen in belastbare Entscheidungen. Sie betrachtet nicht nur Quellcode und Server, sondern auch Schnittstellen, Datenqualität, Berechtigungen, Betriebsabläufe, Testbarkeit und die fachlichen Regeln, die oft unsichtbar im System stecken. Erst daraus ergibt sich, ob gezielte Reparaturen, eine Ablösung einzelner Teile oder ein Neubau angemessen sind.

Wann eine schrittweise Modernisierung passt

Eine schrittweise Modernisierung eignet sich, wenn das bestehende System wichtige Fachlogik enthält und weiterhin zuverlässig arbeitet, aber an klar abgegrenzten Stellen an Grenzen stößt. Dann wird nicht alles auf einmal ersetzt. Stattdessen werden besonders problematische Funktionen, Integrationen oder Bedienoberflächen priorisiert und kontrolliert erneuert.

• Die Kernprozesse sind fachlich weitgehend klar und das bestehende System liefert dafür noch verlässliche Daten.
• Einzelne Schwachstellen lassen sich fachlich und technisch abgrenzen, etwa ein Import, ein Freigabeschritt oder ein Reporting-Modul.
• Der laufende Betrieb darf nicht über längere Zeit durch ein Großprojekt gefährdet werden.
• Neue Komponenten können über klar definierte Schnittstellen schrittweise mit dem Bestand zusammenarbeiten.
• Das Team kann parallel fachliche Entscheidungen treffen, testen und Rückmeldungen aus dem Betrieb einarbeiten.

Praktisch kann das bedeuten, zunächst eine API vor ein vorhandenes System zu setzen, damit andere Anwendungen nicht direkt auf dessen Datenbank zugreifen. Danach kann etwa ein neues internes Dashboard entstehen, das Daten aus mehreren Quellen bündelt. Das Altsystem bleibt zunächst führend für die vorhandene Fachlogik, während neue Funktionen außerhalb des eng gekoppelten Kerns entstehen. So entsteht kein unnötiger Komplettumzug, bevor Nutzen und Risiken geprüft sind.

Wann ein Neubau die klarere Entscheidung ist

Ein vollständiger Neubau ist kein Zeichen besonderer technischer Ambition, sondern eine betriebliche Entscheidung mit hohen Anforderungen. Er ist dann plausibel, wenn zentrale Teile des Systems nicht mehr sicher verändert werden können und eine Modernisierung lediglich die Probleme konservieren würde. Das kann etwa bei einem unverständlichen Datenmodell, nicht reproduzierbaren Betriebsabläufen oder einer Architektur ohne sinnvolle Erweiterungspunkte der Fall sein.

Auch ein grundlegend veränderter Geschäftsprozess kann einen Neubau rechtfertigen. Wenn eine Anwendung für interne Sachbearbeitung gebaut wurde, künftig aber Kunden oder Partner im Self-Service bedienen soll, reichen neue Masken oft nicht aus. Rollen, Datenzugriff, Fehlerbehandlung, Nachvollziehbarkeit und Prozesse müssen dann neu gedacht werden. Ein Neubau schafft in diesem Fall die Gelegenheit, nicht nur Technik, sondern auch überholte Arbeitsabläufe abzulösen.

Die größte Gefahr beim Neubau ist, Funktionen zu kopieren, ohne ihre Bedeutung zu verstehen. Viele Altsysteme enthalten Sonderregeln, die aus konkreten Ausnahmen entstanden sind. Manche sind unverzichtbar, andere längst obsolet. Beide Kategorien müssen vor der Umsetzung sichtbar werden. Ein Neubau ohne fachliche Inventur verlagert dieses Risiko lediglich in ein neues System.

Entscheidung in vier Schritten vorbereiten

1. Geschäftskritische Prozesse erfassen: Welche Abläufe verursachen Umsatz, erfüllen Verpflichtungen oder verhindern operative Fehler? Nicht jede Funktion verdient dieselbe Aufmerksamkeit.
2. Schmerzpunkte mit Beispielen belegen: Dokumentieren Sie konkrete Medienbrüche, wiederkehrende Fehler, lange Änderungswege und Abhängigkeiten. Trennen Sie beobachtete Probleme von bloßen Vermutungen.
3. Technische und fachliche Grenzen bewerten: Prüfen Sie Datenmodell, Schnittstellen, Berechtigungen, Testmöglichkeiten, Deployment und verfügbares Wissen. Ergänzen Sie dies um die Frage, welche Regeln wirklich noch benötigt werden.
4. Zielbild und ersten Schnitt festlegen: Definieren Sie, welche Aufgabe künftig besser funktionieren soll und welche Datenquelle vorerst führend bleibt. Starten Sie mit einem abgegrenzten Bereich, dessen Erfolg im Betrieb überprüfbar ist.

Praxisbeispiel: Rechnungsprozess ohne Big Bang verbessern

Ein Unternehmen arbeitet mit einem gewachsenen Rechnungsprogramm. Artikelverwaltung, Rechnungserstellung, PDF-Export und E-Mail-Versand sind vorhanden, doch Änderungen an Vorlagen und Abläufen sind schwer umsetzbar. Zusätzlich pflegt das Team Kundendaten an mehreren Stellen, weil eine saubere Verbindung zu anderen Systemen fehlt.

Ein vorschneller Neubau würde alle Funktionen gleichzeitig infrage stellen. Sinnvoller kann es sein, zuerst Datenflüsse zu klären: Welches System ist für Kunden, Artikel und Rechnungsstatus jeweils maßgeblich? Anschließend wird eine Integration aufgebaut, die notwendige Daten eindeutig überträgt und Fehler sichtbar macht. In einem zweiten Schritt kann eine modernisierte Oberfläche für die Rechnungsbearbeitung folgen. Erst wenn der alte Rechnungskern zum Hindernis wird, ist seine gezielte Ablösung begründet.

Der Nutzen dieses Vorgehens liegt nicht in einer bestimmten Technologie. Er liegt darin, dass die Organisation zuerst die riskantesten manuellen Übergaben reduziert und dabei Wissen über Sonderfälle sammelt. Gleichzeitig bleibt die Möglichkeit erhalten, den nächsten Schritt anhand realer Erfahrungen zu entscheiden.

Technische Leitplanken für eine wartbare Ablösung

Unabhängig vom Weg sollte die neue Architektur Verantwortlichkeiten sauber trennen. Eine dokumentierte API verhindert, dass neue Anwendungen direkt an interne Datenstrukturen gekoppelt werden. Ein nachvollziehbares Berechtigungskonzept schützt vertrauliche Daten und erleichtert die Prüfung von Zugriffen. Automatisierte Tests konzentrieren sich zunächst auf die geschäftskritischen Regeln, nicht auf möglichst hohe Kennzahlen.

Für mittelständische Unternehmen ist zudem die Betriebsfähigkeit Teil der Architekturentscheidung. Dazu gehören dokumentierte Deployments, Backups, Monitoring, klare Zuständigkeiten und die Möglichkeit, den Code langfristig zu übernehmen und weiterzuentwickeln. Open-Source-Komponenten und Hosting in Deutschland können dabei passend sein, wenn sie zu Datenschutzanforderungen, Betriebsmodell und vorhandenem Know-how passen. Sie ersetzen jedoch keine saubere Systemgrenze und keine verantwortliche Wartung.

Typische Fehlentscheidungen vermeiden

• Den Austausch eines Frameworks mit einer fachlichen Modernisierung verwechseln. Neue Technik hilft nicht, wenn Daten und Prozesse unverändert widersprüchlich bleiben.
• Zu früh eine Zielarchitektur festschreiben. Erst die kritischen Abläufe und Abhängigkeiten verstehen, dann Komponenten auswählen.
• Zwei Systeme dauerhaft parallel pflegen, ohne klare Datenhoheit. Für jedes wichtige Objekt muss feststehen, welches System führend ist.
• Die Migration als einmaligen Termin behandeln. Datenbereinigung, Übergangsregeln und Rückfalloptionen gehören in die Planung.
• Nur die IT entscheiden lassen. Fachbereiche müssen Sonderfälle priorisieren und festlegen, welche bisherigen Regeln entfallen dürfen.

Wer Legacy-Software modernisieren will, sollte daher keine Grundsatzentscheidung zwischen „alt“ und „neu“ treffen. Die bessere Frage lautet: Welcher nächste Schritt reduziert heute ein relevantes Geschäftsrisiko, ohne morgen unnötige Abhängigkeiten zu schaffen? Eine fundierte Bestandsaufnahme und ein klar abgegrenzter erster Baustein liefern darauf meist mehr Antworten als ein umfassendes Neuversprechen.