Eine bestehende Anwendung funktioniert seit Jahren, bildet wichtige Prozesse ab und ist den Mitarbeitenden vertraut. Gleichzeitig werden Änderungen immer mühsamer: neue Funktionen dauern länger, Schnittstellen fehlen oder einzelne Komponenten wirken technisch überholt. Spätestens dann entsteht die Frage: Sollten wir die Software weiterentwickeln oder komplett ersetzen?
Die Antwort ist selten so eindeutig, wie sie auf den ersten Blick wirkt. Eine alte Anwendung kann technisch sauber und gut wartbar sein. Umgekehrt kann eine vergleichsweise junge Software bereits so stark von Workarounds, Abhängigkeiten und kurzfristigen Entscheidungen geprägt sein, dass jede Erweiterung unverhältnismäßig teuer wird.
Die bessere Entscheidung ist nicht automatisch „neu“. Sie ist die Variante, die Nutzen, Risiko und Veränderbarkeit über die nächsten Jahre am sinnvollsten zusammenbringt.
Wann sich bestehende Software weiterentwickeln lässt
Eine Weiterentwicklung ist häufig sinnvoll, wenn der Kern der Anwendung funktioniert und die gewünschte Veränderung klar begrenzt werden kann.
- Der Quellcode ist vollständig verfügbar.
- Die Anwendung lässt sich reproduzierbar installieren und deployen.
- Zentrale Frameworks und Abhängigkeiten werden noch unterstützt oder können aktualisiert werden.
- Die Datenstruktur ist nachvollziehbar.
- Kritische Funktionen lassen sich testen.
- Neue Anforderungen betreffen einzelne Bereiche statt das gesamte System.
- Bestehende Prozesse und Nutzerlogik sollen bewusst erhalten bleiben.
In solchen Situationen kann es wirtschaftlicher sein, gezielt zu ergänzen, zu refaktorieren oder einzelne Komponenten auszutauschen, statt ein funktionierendes System komplett neu zu bauen.
Ein internes Kundenportal funktioniert zuverlässig, besitzt aber keine moderne Schnittstelle zum CRM. Wenn Architektur und Datenmodell belastbar sind, kann eine gezielte Integration sinnvoller sein als ein vollständiger Neubau des Portals.
Wann ein Ersatz wahrscheinlicher wird
Ein kompletter Ersatz wird interessanter, wenn nicht einzelne Funktionen, sondern die technische Basis selbst zum Engpass geworden ist.
- Kritische Technologien erhalten keine Sicherheitsupdates mehr.
- Die Anwendung kann nur von einer einzelnen Person verstanden oder betrieben werden.
- Es existiert kein verlässlicher Quellcode- oder Versionsstand.
- Änderungen in einem Bereich verursachen regelmäßig Fehler an anderen Stellen.
- Tests fehlen vollständig und Releases sind kaum kontrollierbar.
- Die Architektur verhindert zentrale neue Anforderungen.
- Notwendige Integrationen lassen sich nur über fragile Workarounds umsetzen.
- Der zugrunde liegende Geschäftsprozess hat sich grundlegend verändert.
Auch dann ist ein Big-Bang-Rewrite nicht automatisch die beste Option. Moderne Migrations- und Modernisierungsstrategien unterscheiden zwischen Weiterbetrieb, Rehosting, Replatforming, Refactoring und vollständiger Neuarchitektur.
Fünf Fragen vor der Entscheidung
1. Funktioniert der fachliche Kern noch?
Wenn die Software den zentralen Geschäftsprozess weiterhin korrekt abbildet, ist das ein starkes Argument für Erhalt und Weiterentwicklung. Ein Neubau müsste diese oft über Jahre gewachsene Geschäftslogik zunächst vollständig neu verstehen und reproduzieren.
2. Wie veränderbar ist der Code?
Entscheidend ist nicht, ob der Code ästhetisch perfekt ist. Wichtig ist, ob Änderungen mit vertretbarem Risiko durchgeführt werden können. Dazu gehören nachvollziehbare Strukturen, kontrollierbare Abhängigkeiten, Tests und ein reproduzierbarer Build- und Deployment-Prozess.
3. Welche Teile verursachen die eigentlichen Probleme?
Häufig ist nicht die ganze Anwendung problematisch. Vielleicht ist nur die Benutzeroberfläche veraltet, eine Schnittstelle fehlt oder ein einzelnes Modul blockiert neue Anforderungen.
Dann kann eine schrittweise Modernisierung sinnvoll sein. Das Strangler-Fig-Muster beschreibt genau dieses Prinzip: Teile eines Altsystems werden nach und nach durch neue Komponenten ersetzt, statt die gesamte Anwendung auf einmal auszutauschen.
4. Was würde bei einem Neubau verloren gehen?
In einer bestehenden Software steckt häufig Wissen, das nirgends dokumentiert ist: Sonderfälle, Prüfregeln, Berechnungen, Berechtigungen und kleine Entscheidungen, die sich über Jahre angesammelt haben.
5. Welches Risiko trägt das Unternehmen während der Veränderung?
Bei geschäftskritischer Software zählt nicht nur der Zielzustand. Entscheidend ist auch, wie sicher der Weg dorthin ist.
- Kann die bestehende Anwendung während der Modernisierung weiterlaufen?
- Können neue Funktionen schrittweise produktiv genommen werden?
- Gibt es eine Rückfalloption?
- Wie werden Daten migriert?
- Welche Prozesse dürfen auf keinen Fall ausfallen?
Entscheidungsmatrix: weiterentwickeln, modernisieren oder ersetzen?
Weiterentwickeln: Der fachliche Kern funktioniert, die Technik ist beherrschbar und neue Anforderungen lassen sich klar ergänzen.
Schrittweise modernisieren: Die Anwendung ist geschäftlich wichtig, einzelne technische Bereiche bremsen jedoch Wartung, Integration oder Weiterentwicklung.
Ersetzen: Die technische Basis ist kaum noch wartbar, zentrale Anforderungen lassen sich nicht mehr wirtschaftlich umsetzen oder der zugrunde liegende Geschäftsprozess hat sich grundlegend verändert.
Warum ein kompletter Rewrite oft attraktiver klingt, als er ist
„Wir bauen es einfach neu“ klingt zunächst sauber. Keine Altlasten, moderne Technologie, neue Architektur. In der Praxis beginnt damit aber auch ein neues Risiko:
- bestehende Geschäftslogik muss vollständig entdeckt werden,
- alte und neue Datenmodelle müssen zusammengebracht werden,
- Nutzer müssen ihre Arbeitsweise ändern,
- Integrationen müssen neu implementiert werden,
- Funktionen, die im Altsystem selbstverständlich wirken, werden leicht übersehen.
Martin Fowler beschreibt mit dem Strangler-Fig-Ansatz eine Alternative: neue Funktionalität wird schrittweise um oder neben dem bestehenden System aufgebaut, bis alte Teile kontrolliert abgelöst werden können.
Vor dem Budgetversprechen steht der technische Check
Bevor ein Dienstleister seriös zusagen kann, dass eine bestehende Software weiterentwickelt werden kann, sollte er die technische Ausgangslage kennen.
- Repository und Versionshistorie
- Programmiersprache und Framework-Versionen
- Abhängigkeiten und deren Wartungsstatus
- Datenbank und Datenmigrationen
- Hosting und Deployment
- Tests
- Authentifizierung und Berechtigungen
- Schnittstellen
- Dokumentation
- offene Fehler und bekannte technische Schulden
Fazit
Das Alter einer Software ist kein ausreichender Grund für einen Neubau. Entscheidend ist, ob die Anwendung ihren fachlichen Zweck noch erfüllt und ob sich Änderungen technisch kontrolliert umsetzen lassen.
Unternehmen sollten deshalb nicht mit der Frage „alt oder neu?“ beginnen, sondern mit drei anderen Fragen: Was funktioniert heute gut? Was blockiert uns konkret? Und welcher Veränderungsweg reduziert das Risiko?
Häufige Fragen
Wann sollte bestehende Software weiterentwickelt werden?
Eine Weiterentwicklung ist häufig sinnvoll, wenn der fachliche Kern funktioniert, der Quellcode verfügbar ist und neue Anforderungen mit vertretbarem technischem Risiko ergänzt werden können.
Wann sollte Software komplett ersetzt werden?
Ein Ersatz wird eher sinnvoll, wenn die technische Basis nicht mehr wartbar ist, zentrale Technologien nicht mehr unterstützt werden oder neue Geschäftsanforderungen mit der bestehenden Architektur nicht wirtschaftlich umsetzbar sind.
Ist ein kompletter Rewrite immer moderner?
Ein Rewrite ermöglicht einen technischen Neustart, bringt aber auch Risiken mit sich. Bestehende Geschäftslogik, Daten, Integrationen und Sonderfälle müssen vollständig neu verstanden und umgesetzt werden.
Was ist eine schrittweise Softwaremodernisierung?
Dabei werden problematische Teile einer bestehenden Anwendung kontrolliert modernisiert oder ersetzt, während andere funktionierende Bereiche zunächst bestehen bleiben.