Ein altes System kann jahrelang laufen und weiterhin die wichtigsten Prozesse im Unternehmen abwickeln – und wird trotzdem immer deutlicher zur Bremse. Jede neue Funktion kostet mehr, als sie sollte. Und eine einfache Änderung in der Preisliste oder eine Integration mit irgendeinem externen Werkzeug wird zu einem Projekt über viele Wochen. Irgendwann fällt die Frage, die bei fast jeder größeren geschäftlichen Entscheidung wiederkehrt: Soll die Modernisierung eines alten IT-Systems über die Weiterentwicklung der bestehenden Anwendung laufen oder über eine komplette Neuentwicklung? Die Antwort ist selten eindeutig, denn auf der einen Seite steht bewährte Geschäftslogik und auf der anderen wachsende technische Schuld.
Bei Web Systems betrachten wir das aus der Perspektive des Dienstleisters. Seit 2006 entwerfen und betreuen wir Webanwendungen, B2B-Systeme, API-Integrationen und Automatisierungen, und in diesen Jahren haben wir die Wartung etlicher Systeme übernommen, die jemand ganz anderes geschrieben hat. Eines wissen wir sicher: Die Entscheidung zwischen Neuschreiben und Weiterentwickeln ist keine Frage technologischer Mode, sondern einer nüchternen Kalkulation von Risiko, Kosten und Unternehmenszielen. In diesem Artikel zeigen wir, wie Sie den Moment der Entscheidung erkennen, wann sich Weiterentwicklung lohnt, wann eine Neuentwicklung, welche Zwischenwege sinnvoll sind und worauf Sie bei der Schätzung von Kosten und Risiken wirklich achten sollten.
Spis treści
Woran Sie erkennen, dass ein System eine Modernisierungsentscheidung braucht
Das erste Signal sind meist die Kosten von Änderungen. Wenn das Hinzufügen einer scheinbar banalen Funktion Wochen an Arbeit erfordert und ein vorsichtiges Umschiffen von Codeteilen, die niemand mehr versteht, ist das ein klares Zeichen dafür, dass die technische Schuld das Tempo zu diktieren beginnt. Das zweite häufige Symptom? Fehlende Dokumentation in Verbindung mit dem Weggang der Personen, die die Anwendung ursprünglich geschrieben haben. Das Wissen darüber, warum etwas so und nicht anders funktioniert, verschwindet mit ihnen. Und jede Änderung wird zum Ratespiel über die Konsequenzen.
Parallel dazu wächst das Sicherheitsrisiko. Veraltete Bibliotheken, eine überholte Version der Sprache oder des Frameworks, fehlende regelmäßige Updates – das sind offene Türen für Schwachstellen, für die es längst öffentliche Exploits gibt. In Systemen, die personenbezogene Daten oder Zahlungen verarbeiten, ist ein solcher Zustand nicht mehr nur ein technisches Problem, sondern auch eine Frage der Rechtskonformität. Hinzu kommen Leistungsprobleme, die bei wachsender Nutzer- oder Datenzahl auftreten, weil eine vor Jahren entworfene Architektur die heutige Größenordnung schlicht nicht vorgesehen hat.
Eine eigene Kategorie sind Integrationen. Neue Werkzeuge, Zahlungs-Gateways, Buchhaltungssysteme oder Marketingplattformen erwarten moderne APIs und Datenaustauschformate. Ein älteres System kann sich oft nur mit teuren Umwegen mit ihnen verbinden, manchmal überhaupt nicht. Nachfolgend haben wir die typischen Symptome technischer Schuld zusammengestellt, die wir bei Audits beobachten:
- jede Änderung erfordert manuelle Tests, weil automatische Tests fehlen
- das Einspielen einer neuen Version ist stressig und wird auf das Wochenende verschoben
- niemand im Team fühlt sich in den neuralgischen Modulen sicher
- Bibliotheken und Umgebung werden vom Hersteller nicht mehr unterstützt
- die Daten sind verstreut und es gibt keine einzige Quelle der Wahrheit
Wenn Sie mehrere dieser Punkte gleichzeitig wiedererkennen, ist die Entscheidung über die Richtung der Modernisierung nicht mehr optional. Sie ist nur noch eine Frage von Zeit und Geld.
Wann sich die Weiterentwicklung der bestehenden Anwendung lohnt
Die Weiterentwicklung einer bestehenden Anwendung ist häufiger sinnvoll, als es die Begeisterung für das Neuschreiben von allem nahelegt. Das stärkste Argument? Bewährte Geschäftslogik. Wenn ein System seit Jahren Bestellungen, Abrechnungen oder Dokumentenläufe korrekt abwickelt, enthält es hunderte Entscheidungen und Ausnahmen, die reale Zeit und reales Geld gekostet haben. Dieses Wissen ist wertvoll und sollte nicht leichtfertig weggeworfen werden. Die zweite Bedingung ist der Zustand des Codes: Wenn er lesbar ist und die Struktur, so unvollkommen sie sein mag, sichere Änderungen erlaubt, taugt das Fundament für die weitere Arbeit.
Dann ist der schrittweise Umbau der optimale Weg. Dazu gehören die Refaktorierung kritischer Teile, die Aktualisierung der Abhängigkeiten auf unterstützte Versionen und das systematische Ergänzen von Tests, die vor Regressionen schützen. Diese Arbeitsweise hat einen enormen geschäftlichen Vorteil: Das System läuft während der gesamten Arbeiten weiter. Das Unternehmen stoppt weder den Verkauf noch die Kundenbetreuung, und das Risiko verteilt sich auf kleine, kontrollierte Schritte statt auf einen großen Sprung ins Ungewisse.
In der Praxis kommt es auf die Reihenfolge an. Bevor wir größere Änderungen angehen, verschaffen wir uns einen Überblick über das Terrain, denn blindes Refaktorieren ohne Sicherheitsnetz endet schnell in Fehlern, die sich später nur schwer aufspüren lassen.
Tipp: Beginnen Sie mit einem Code-Audit und mit Tests für die wichtigsten Geschäftsabläufe, bevor Sie die Architektur überhaupt anfassen. Tests wirken wie ein Sicherungsnetz und geben Ihnen die Gewissheit, dass die nächsten Verbesserungen nichts kaputt machen.
Die Weiterentwicklung der bestehenden Anwendung bewährt sich auch dann, wenn das Budget begrenzt und der Zeitdruck hoch ist. Eine inkrementelle Modernisierung erlaubt es, die Arbeiten etappenweise zu finanzieren und die Ergebnisse nach jeder Phase zu beobachten. Auch die Erwartungen von Team und Geschäftsführung lassen sich leichter steuern, weil der Fortschritt mit bloßem Auge sichtbar ist und das Risiko, dass das Projekt auf der Stelle tritt, viel geringer ist als bei einer vollständigen Neuentwicklung. In vielen Projekten bringt gerade die konsequente, gut geplante Weiterentwicklung den besseren Ertrag als ein teurer Neustart.
Wann es besser ist, die Anwendung neu zu schreiben
Es gibt jedoch Situationen, in denen weiteres Flicken immer weniger bringt und eine Neuentwicklung die vernünftigere Investition ist. Erstens: eine Architektur, die die Weiterentwicklung von Grund auf blockiert. Wenn jede Änderung Eingriffe an einem Dutzend Stellen erfordert und die Module so miteinander verflochten sind, dass sie sich nicht trennen lassen, wachsen die Wartungskosten schneller als der Wert, den das System liefert. Das zweite Signal ist eine Technologie, die nicht mehr unterstützt wird: keine Sicherheitsupdates, ein schwindender Markt an Fachleuten und die Unmöglichkeit, die Umgebung auf moderner Infrastruktur zu betreiben.
Ein weiteres Argument sind Grenzen der Skalierung. Wenn sich das System bei wachsendem Verkehr nicht sinnvoll skalieren lässt, wenn die Datenstruktur den Anforderungen nicht mehr folgt und Integrationen über APIs immer waghalsigere Umwege erfordern, kann eine inkrementelle Modernisierung teurer werden als der Aufbau eines neuen Fundaments. In solchen Fällen ist eine Neuentwicklung keine Marotte, sondern ein Weg, die Kontrolle über die Kosten der weiteren Entwicklung zurückzugewinnen.
Man muss die Risiken jedoch ehrlich benennen, denn eine Neuentwicklung kann eine Falle sein. Die größte Gefahr? Der Verlust des im alten Code verborgenen Wissens – all jener Ausnahmen und Geschäftsregeln, die nirgendwo beschrieben wurden. Die zweite ist die notorische Unterschätzung des Umfangs: Das neue System muss die gesamte Funktionalität des alten nachbilden, bevor es irgendetwas Neues hinzufügt. Und das ist meist deutlich mehr Arbeit, als die ersten Schätzungen annehmen.
Typischer Fehler: alles auf einmal neu zu schreiben, im Modus der großen Umschaltung, bei der das alte System erst nach Fertigstellung des gesamten neuen abgeschaltet wird. Ein solches Projekt kann sich monatelang ohne funktionierendes Ergebnis hinziehen, und der Druck wächst mit jeder Woche. Deshalb teilen wir auch eine beschlossene Neuentwicklung in Etappen auf und halten das alte System so lange am Leben wie nötig – damit das Risiko kontrolliert bleibt und das Unternehmen seine Handlungsfähigkeit nicht verliert.
Zwischenwege – Strangler Fig, etappenweise Migration, Auslagerung von Modulen
Zwischen vollständiger Weiterentwicklung und kompletter Neuentwicklung liegt ein Feld von Zwischenlösungen, die sich in der Praxis am häufigsten bewähren. Am bekanntesten ist der Strangler-Fig-Ansatz, also das schrittweise Umranken des alten Systems mit neuen Diensten. Neue Funktionen entstehen in moderner Technologie, und der Verkehr wird Stück für Stück auf sie umgeleitet. Der alte Code lebt so lange, wie er gebraucht wird, und erlischt natürlich, sobald alle seine Zuständigkeiten von den neuen Komponenten übernommen wurden. Dadurch läuft das System ununterbrochen weiter, und das Risiko verteilt sich auf kleine Portionen.
Das zweite Werkzeug ist das Aufbrechen des Monolithen in kleinere Module oder Dienste – dort, wo es begründet ist. Wir betonen diese Bedingung, denn Microservices sind kein Selbstzweck und können erhebliche betriebliche Komplexität hinzufügen. Wir lagern jene Teile aus, die sich am häufigsten ändern, eine klar abgegrenzte Verantwortung haben oder unabhängig skaliert werden müssen. Der Rest kann in einem zusammenhängenden Modul bleiben, solange es keinen realen Grund gibt, ihn zu teilen.
Eine eigene und häufig unterschätzte Etappe ist die Datenmigration. Sie gehört zu den riskantesten Elementen des gesamten Vorhabens, denn Daten sind oft inkonsistent, enthalten historische Ausnahmen und passen ohne Transformation nicht in das neue Modell. Die Migration erfordert einen eigenen Plan, eine Testumgebung und die Prüfung der Korrektheit an realen Datenbeständen, nicht nur an schönen Beispielen. Gute Praxis? Beide Systeme parallel betreiben und die Ergebnisse vergleichen, bevor das alte abgeschaltet wird.
Diese Ansätze verbindet ein architektonisches Prinzip: die Trennung der Verantwortlichkeiten und eine einzige Quelle der Wahrheit für jeden Datentyp. Wenn klar ist, welche Komponente Eigentümerin einer Information ist und nur sie diese ändern darf, wird das System vorhersehbar, leichter testbar und robuster gegenüber Fehlern. Und genau diese Disziplin, nicht die Wahl einer bestimmten Technologie, entscheidet darüber, ob die weitere Entwicklung günstig und sicher verläuft oder erneut in wachsende technische Schuld umschlägt.
Kosten, Risiken und Wartung – worauf Sie bei der Entscheidung achten sollten
Eine Modernisierungsentscheidung sollte auf dem Vergleich der Kosten über mehrere Jahre beruhen, nicht nur auf dem Preis der nächsten Umsetzung. Auf der einen Seite stehen die Kosten für den Betrieb des alten Systems: wachsende Arbeitsstunden für kleine Änderungen, das Ausfallrisiko, die Kosten für die Aufrechterhaltung veralteter Infrastruktur und der immer teurere Zugang zu Fachleuten, die die jeweilige Technologie beherrschen. Auf der anderen Seite die Kosten der Modernisierung, die zu Beginn höher ausfallen können, sich aber über die geringeren Kosten jeder weiteren Änderung amortisieren. Erst die Gegenüberstellung beider Kurven über einen Horizont von drei bis fünf Jahren zeigt das reale Bild.
Bei der Bewertung lohnt es sich, ein paar klare Kriterien einzuhalten. Sie helfen, die Ingenieursentscheidung von Emotionen und technologischer Mode zu trennen:
- Sicherheit – lässt sich das System aktualisieren und schützt es die Daten gemäß den Anforderungen
- Konformität – erfüllt es die branchlichen und rechtlichen Vorgaben heute und in absehbarer Zukunft
- Skalierbarkeit – trägt es das Wachstum von Verkehr und Daten, ohne dass die Fundamente neu geschrieben werden müssen
- Kosten der weiteren Entwicklung – was kostet das Hinzufügen einer typischen neuen Funktion tatsächlich
Ein weniger sichtbarer, aus meiner Sicht aber entscheidender Faktor ist die Testbarkeit und Lesbarkeit der Architektur. Ein System, das von Tests abgedeckt und in Komponenten mit klaren Grenzen aufgeteilt ist, erzeugt sehr viel weniger technische Schuld, weil sich jede Änderung sicher einführen und schnell überprüfen lässt. Gerade diese Eigenschaft beeinflusst die Wartungskosten auf lange Sicht am stärksten. Und zugleich ist sie am schwersten zu würdigen, solange sie nicht fehlt.
Zum Schluss lohnt sich der Blick in die Zukunft des Systems. Eine moderne Version der Anwendung bedeutet nicht nur eine aufgefrischte Oberfläche, sondern auch die Bereitschaft für Integrationen, die Automatisierung wiederkehrender Prozesse sowie KI-basierte Lösungen wie die Analyse von Dokumenten oder die Unterstützung des Kundenservice. Die Entscheidung über die Modernisierung ist damit zugleich eine Entscheidung darüber, wie gut das System weitere Verbesserungen aufnehmen kann, ohne dass es erneut zu einer kostspieligen Revolution kommt.
FAQ – die häufigsten Fragen zur Modernisierung von IT-Systemen
Bedeutet eine Modernisierung Stillstand im Unternehmen?
In den meisten Fällen nicht. Eine gut geplante Modernisierung, besonders im inkrementellen Modell oder im Strangler-Fig-Ansatz, erlaubt es, das System während der gesamten Arbeiten betriebsbereit zu halten. Änderungen werden etappenweise eingeführt, neue Komponenten laufen neben den alten an, und der Verkehr wird erst nach dem Testen umgeleitet. Der riskante Moment ist meist die Datenmigration und die finale Umschaltung – deshalb planen wir sie gesondert, mit der Möglichkeit, Änderungen zurückzunehmen. Bei guter Vorbereitung merken die Endnutzer oft gar nicht, dass darunter ein tiefgreifender Umbau läuft.
Wie lange dauert die Neuentwicklung einer Anwendung und wovon hängt die Zeit ab?
Es gibt keine einzelne Zahl, denn die Dauer hängt von der Komplexität der Geschäftslogik, der Zahl der Integrationen, der Datenqualität und davon ab, wie gut das alte System dokumentiert ist. Die meiste Zeit verschlingt in der Regel nicht das Schreiben des neuen Codes, sondern das Nachbilden aller Regeln und Ausnahmen, die in der bestehenden Anwendung verborgen sind. Deshalb verkürzt ein solides Audit am Anfang das gesamte Projekt, weil es eine realistische Schätzung des Umfangs erlaubt. Ein etappenweises Vorgehen sorgt dafür, dass erste funktionierende Teile schnell entstehen und das Ganze allmählich reift.
Lässt sich ein System bei begrenztem Budget etappenweise modernisieren?
Ja, und genau das empfehlen wir häufig. Wir teilen die Modernisierung in Phasen und beginnen mit den Bereichen mit dem größten Risiko oder den höchsten Wartungskosten, wo eine Verbesserung den schnellsten Ertrag bringt. Jede Etappe wird gesondert kalkuliert und liefert einen messbaren Effekt, sodass sich das Budget über die Zeit verteilen und die Arbeiten aus den laufenden Vorteilen finanzieren lassen. Dieses Vorgehen begrenzt das Risiko und erlaubt es, das Projekt anzuhalten oder neu zu planen, wenn sich die Prioritäten des Unternehmens ändern.
Fazit
Es gibt keine allgemeingültige Antwort auf die Frage, ob die Modernisierung eines alten IT-Systems Weiterentwicklung oder Neuentwicklung bedeuten sollte. Alles hängt vom Zustand des Codes, der Qualität der Architektur, den geschäftlichen Zielen und den realen Wartungskosten über mehrere Jahre ab. Wenn die Logik bewährt ist und der Code sich lesen und testen lässt, lohnt es sich meist, die bestehende Anwendung schrittweise weiterzuentwickeln. Wenn die Architektur die Entwicklung blockiert und die Technologie keine Unterstützung mehr hat, ist ein kontrollierter, etappenweiser Neustart sinnvoller. Und am häufigsten bewähren sich Zwischenlösungen, die die Vorteile beider Wege verbinden.
Am wichtigsten ist, dass diese Entscheidung aus einem Audit und harten Kriterien folgt – Sicherheit, Skalierbarkeit, Testbarkeit und Kosten der weiteren Entwicklung – und nicht aus der Mode für eine bestimmte Technologie. Eine gut durchgeführte Analyse hilft, zwei Extreme zu vermeiden: das sinnlose Neuschreiben eines funktionierenden Systems und das Amlebenerhalten einer Lösung, die ausschließlich Kosten und Risiko erzeugt.
Wenn Sie vor einer solchen Entscheidung stehen, helfen wir Ihnen bei Web Systems, sie auf Basis von Fakten zu treffen. Wir beginnen mit einem Audit, zeigen die realen Optionen auf und führen Modernisierung, Integrationen, Automatisierungen sowie KI-Umsetzungen so durch, dass Ihr Unternehmen nicht stillsteht. Nehmen Sie Kontakt mit uns auf, wenn Sie ein MVP, eine neue Anwendung, eine Systemintegration oder die Modernisierung einer bestehenden Lösung planen – wir beraten Sie gern, womit Sie am besten beginnen.
