Legacy-Systeme: Warum Neubau oft der falsche Ansatz ist

Viele Unternehmen stehen irgendwann vor derselben Entscheidung: Das bestehende System ist gewachsen, schwer wartbar, vielleicht technisch überholt – also neu bauen?

Technisch ist das heute selten das Problem. Moderne Frameworks, Cloud-Infrastruktur und skalierbare Architekturen machen einen Neustart greifbar. Gleichzeitig zeigt sich in der Praxis etwas anderes: Ein kompletter Neubau ist oft nicht die einfachste oder sinnvollste Lösung. Nicht, weil er technisch nicht funktioniert. Sondern weil er das eigentliche Problem häufig nicht trifft.

Wenn „Legacy" mehr ist als alte Technologie

Der Begriff wird schnell verwendet – meist dann, wenn Systeme sich nur noch schwer verändern lassen. Doch in der Realität ist Legacy nie nur ein technisches Thema. Es ist das Ergebnis von Jahren an Entscheidungen, pragmatischen Lösungen und gewachsenen Prozessen:

• Geschäftslogik, die sich ständig verändert hat, aber selten vollständig dokumentiert wurde.
• Sonderfälle und Workarounds, die entstanden sind, weil das System irgendwann nicht mehr alle Anforderungen abgebildet hat.
• Schnittstellen, die organisch gewachsen sind – ohne klare Struktur.

Ein System bildet nicht nur Funktionen ab, sondern tatsächliche Arbeitsweisen. Ein Neubau setzt genau hier an – aber häufig ohne diese Realität vollständig zu verstehen.

Warum ein Neubau so überzeugend wirkt – und warum er oft teuer wird

Ein Neustart verspricht Klarheit: neue Architektur, sauberer Code, moderne Technologien. Das klingt kontrollierbarer als ein gewachsenes System. Doch genau hier liegt das Problem.

In der Praxis zeigt sich bei solchen Projekten ein immer ähnliches Muster. Anforderungen wirken zu Beginn klar – bis im Projektverlauf plötzlich Sonderfälle, Ausnahmen und implizite Logiken auftauchen, die nie dokumentiert wurden, aber im Alltag seit Jahren funktionieren. Dokumentation fehlt, oder ist so veraltet, dass das eigentliche Wissen in den Köpfen weniger Mitarbeitender steckt. Der Fokus verschiebt sich: Aus einem strukturierten Neubau wird schrittweise eine Rekonstruktion – mit dem Risiko, alte Komplexität unter neuem Namen wieder aufzubauen.

Die eigentliche Herausforderung liegt selten im Code selbst. Sie liegt in dem, was der Code abbildet.

Die entscheidende Frage: Prozessverständnis oder Technologieentscheidung?

Die Entscheidung „neu bauen oder modernisieren" wird oft als Architekturthema behandelt. In der Praxis ist sie vor allem eine Frage des Prozessverständnisses.

Ein bestehendes System ist nie neutral. Es bildet ab, wie ein Unternehmen arbeitet – inklusive aller Abkürzungen, Sonderfälle und gewachsenen Lösungen. Wenn diese Logik nicht verstanden wird, führt ein Neubau entweder dazu, dass funktionierende Abläufe verloren gehen – oder dass sie unter neuen technischen Rahmenbedingungen erneut entstehen. Beides kostet Zeit, Geld und Vertrauen.

Deshalb beginnt Modernisierung nicht mit der Technologieentscheidung. Sie beginnt mit der Frage: Was passiert hier eigentlich wirklich?

Der unterschätzte Weg: Schrittweise Modernisierung

Zwischen „alles neu" und „alles behalten" liegt ein Ansatz, der weniger sichtbar, aber oft tragfähiger ist. Bei der schrittweisen Modernisierung geht es nicht darum, bestehende Systeme um jeden Preis zu erhalten. Es geht darum, sie kontrolliert weiterzuentwickeln:

• Einzelne Module werden ersetzt, statt das gesamte System auf einmal neu zu bauen.
• Schnittstellen werden eingeführt, um Abhängigkeiten zu reduzieren.
• Funktionen werden parallel neu entwickelt, während das bestehende System weiterläuft.
• Wissen wird aktiv gesichert – durch Dokumentation, durch Übergangszeiten, durch bewusste Entscheidungen.

Was das konkret bedeutet, lässt sich am besten in Zahlen einordnen:

Technisch ist dieser Weg anspruchsvoll. Organisatorisch ist er oft stabiler – weil bestehendes Wissen nicht verloren geht, sondern gezielt weiterentwickelt wird.

Datenmigration: Was mit den bestehenden Daten passiert

In Modernisierungsprojekten wirkt Datenmigration zunächst wie eine technische Aufgabe: alter Stand raus, neuer Stand rein. In der Praxis ist sie das selten. Datenstrukturen wachsen genauso pragmatisch wie Geschäftslogik. Felder bekommen über die Jahre neue Bedeutungen, zusätzliche Tabellen entstehen als Workaround, Konventionen verschieben sich zwischen Entwicklungsphasen.

Das bedeutet konkret: Die Daten tragen dieselbe Geschichte wie der Code. Wer sie nicht versteht, baut ein technisch sauberes neues System auf einem Fundament, das niemand mehr eindeutig lesen kann.

Drei Fragen reduzieren das Risiko früh:

• Welche Daten nutzt das Unternehmen operativ und welche sind nur historisch relevant?
• Welche Bereinigung muss vor der Migration passieren, damit die neue Struktur sie überhaupt aufnehmen kann?
• Wie bleiben Reports, Auswertungen und Verknüpfungen konsistent, wenn sich die zugrunde liegende Struktur ändert?

In vielen Projekten erfordert die Migration mehr Aufwand als die Neuentwicklung selbst. Wer sie zu spät plant, baut ein technisch fertiges System, das im Alltag nicht trägt, weil die Daten darunter nicht passen.

Change Management: Modernisierung ist kein reines IT-Projekt

Wenn ein neues System ein altes ablöst, verändert es Arbeitsabläufe. Manchmal grundlegend, manchmal in Details, die im Workshop unsichtbar wirken, im Alltag aber bestimmen, ob das System angenommen wird. Wer diese Veränderung nicht aktiv begleitet, bleibt unter der operativen Wirkung, die das Projekt eigentlich liefern sollte.

Vier Punkte entscheiden, ob ein modernisiertes System im Bestand trägt:

• Das Wissen aus dem alten System gehört strukturiert dokumentiert, bevor zentrale Personen wechseln oder das Unternehmen verlassen.
• Fachbereiche formulieren Anforderungen mit, statt sie nur abzunicken. Sonst bildet das neue System einen idealisierten Prozess ab, der mit dem Alltag wenig zu tun hat.
• Schulungen und Übergangszeiten gehören in die Projektplanung, nicht in eine Phase nach dem Go Live.
• Zentrale Wissensträger brauchen Entlastung im Projektzeitraum, sonst wird ihr Know-how zum Engpass, sobald zwei Systeme parallel laufen.

Modernisierung ist deshalb selten ein reines IT-Projekt. Sie ist eine organisatorische Veränderung, die technisch begleitet wird. Wer sie nur technisch denkt, baut ein neues System, das im Alltag schlechter funktioniert als das alte, weil das Wissen, das es bedient, nicht mitgewachsen ist.

Was häufig fehlt, bevor Projekte starten

Viele Modernisierungsprojekte beginnen mit einer Technologieentscheidung: Welche Architektur? Welche Plattform? Welche Tools? Was dabei zu kurz kommt, ist die Analyse des Ist-Zustands – nicht auf technischer Ebene, sondern auf Prozessebene.

Drei Fragen, die ich in solchen Gesprächen immer stelle:

• Verstehen wir die tatsächlichen Arbeitsweisen hinter dem System – also nicht nur, was es tut, sondern warum es so gebaut wurde?
• Wo entstehen manuelle Workarounds, und welche Teile des Systems sind wirklich kritisch für den laufenden Betrieb?
• Und: Ist das Wissen dokumentiert – oder steckt es in den Köpfen von zwei, drei Personen, die das Unternehmen vielleicht morgen verlassen?

Ohne diese Klarheit basiert jede Entscheidung auf Annahmen. Und Annahmen werden in komplexen Systemen schnell teuer.

Wann ein Neubau trotzdem sinnvoll ist

Natürlich gibt es Situationen, in denen ein kompletter Neustart der richtige Weg ist. Wenn Systeme nicht mehr stabil betrieben werden können, Sicherheitsanforderungen nicht mehr erfüllt werden – etwa im Kontext von NIS-2 oder DSGVO-Compliance – oder die Geschäftslogik sich grundlegend verändert hat, kann ein klarer Schnitt sinnvoll sein.

Auch dann gilt jedoch: Ein Neubau funktioniert nur, wenn verstanden wurde, was ersetzt wird. Sonst entsteht kein neues System. Sondern nur ein neues Legacy-System – mit moderner Technologie, aber denselben strukturellen Problemen.

Fazit

Ein Neubau wirkt oft wie der sauberste Weg. Und technisch ist er das auch. Organisatorisch ist er es selten.

Viele Systeme sind nicht deshalb schwierig, weil sie alt sind, sondern weil sie über Jahre ohne klare Struktur gewachsen sind. Diese Struktur lässt sich nicht einfach ersetzen. Sie muss verstanden und neu gedacht werden. Das gilt für die Geschäftslogik genauso wie für die Daten darunter und das Wissen darüber. Modernisierung trägt nur, wenn beides bewusst mitwächst.

Modernisierung bedeutet deshalb nicht automatisch Neubau. Es bedeutet die Fähigkeit, zwischen beidem zu unterscheiden, und dann den Weg zu wählen, der zum Unternehmen, zu den Prozessen und zum tatsächlichen Problem passt.

Wenn Sie aktuell vor dieser Entscheidung stehen, hilft es oft, den bestehenden Zustand einmal gemeinsam strukturiert zu betrachten, bevor eine technische Richtung festgelegt wird.