Wenn eine bestehende Anwendung im Alltag zunehmend Probleme verursacht, entsteht schnell die Frage: weiterentwickeln oder komplett ersetzen?
Ein Neustart wirkt zunächst attraktiv. Neue Technologie, neue Oberfläche, sauberer Code. Gleichzeitig steckt in bestehenden Systemen oft jahrelanges Prozesswissen. Ein vollständiger Ersatz kann deshalb teuer, riskant und organisatorisch aufwendig sein.
Die entscheidende Frage lautet nicht: Ist das System alt? Sondern: Ist es noch eine tragfähige Grundlage für den Prozess, den es unterstützen soll?
Wann Weiterentwicklung oft sinnvoll ist
- Der fachliche Prozess wird grundsätzlich korrekt abgebildet.
- Die Technologie lässt sich noch sicher betreiben.
- Der Quellcode ist verständlich und wartbar.
- Erweiterungen sind technisch möglich.
- Datenmodell und Systemstruktur sind grundsätzlich tragfähig.
- Mitarbeitende können mit dem System arbeiten.
- Die Probleme liegen in einzelnen Funktionen oder Reibungspunkten.
Praxis: Weiterentwicklung statt Neustart
In einem Wils-Solutions-Projekt wurde eine interne Anwendung bereits täglich von mehr als 20 aktiven Nutzern eingesetzt. Die fachlichen Kernfunktionen waren vorhanden. Im Alltag entstanden jedoch unnötige Unterbrechungen: Kalenderänderungen lösten zu viele Benachrichtigungen aus und ein abgelaufener Loginstatus wurde teilweise erst beim nächsten Speichern sichtbar.
Ein kompletter Neubau hätte das eigentliche Problem nicht besser gelöst. Stattdessen wurden die konkreten Reibungspunkte im bestehenden System angepasst.
Kernsystem: funktionierte und wurde akzeptiert
Problem: kleine, wiederkehrende Unterbrechungen
Lösung: gezielte Weiterentwicklung statt vollständiger Neuentwicklung
Wann ein Ersatz sinnvoller werden kann
1. Die technische Basis ist nicht mehr tragfähig
Wenn zentrale Komponenten keine Sicherheitsupdates mehr erhalten, Bibliotheken dauerhaft veraltet sind oder die Anwendung nur noch auf schwer betreibbaren Abhängigkeiten funktioniert, steigt das technische Risiko.
2. Änderungen werden unverhältnismäßig teuer
Ein Warnsignal ist, wenn kleine fachliche Anforderungen immer größere technische Eingriffe erfordern. Dann kann die Architektur selbst zum Engpass geworden sein.
3. Niemand kann das System zuverlässig warten
Kritisch wird es, wenn Wissen nur bei einzelnen Personen liegt, der Code kaum nachvollziehbar ist und Änderungen ohne große Nebenwirkungen nicht mehr möglich sind.
4. Die Anwendung passt nicht mehr zum Geschäftsprozess
Wenn sich das Unternehmen stark verändert hat und Mitarbeitende wesentliche Teile des Prozesses dauerhaft außerhalb der Anwendung abwickeln, kann der funktionale Kern selbst überholt sein.
5. Nutzbarkeit wird zum dauerhaften Produktivitätsproblem
Auch funktionierende Software kann wirtschaftlich schlecht sein, wenn jeder Vorgang unnötig kompliziert ist. Dabei sollte unterschieden werden: Ist wirklich das gesamte System ungeeignet oder lassen sich die kritischen Nutzerwege gezielt verbessern?
Entscheidungsmatrix: Erweitern oder ersetzen?
Eher erweitern: Kernprozess passt · System wartbar · Technik tragfähig · Schnittstellen möglich · Nutzer kommen grundsätzlich zurecht
Eher ersetzen: Kernprozess passt nicht mehr · hohe technische Risiken · Änderungen extrem teuer · System kaum wartbar · strategische Erweiterung blockiert
Die Rolle von Schnittstellen
Zwischen „bestehendes System behalten“ und „alles neu bauen“ gibt es einen wichtigen dritten Weg: Integration.
Viele Fachanwendungen erfüllen ihren Kernzweck weiterhin gut. Probleme entstehen nur, weil Daten aus angrenzenden Prozessen von Hand übertragen werden müssen. Eine API, ein Import, ein Export oder eine ergänzende Anwendung kann diese Lücke schließen.
Die Rolle der Mitarbeitenden
- Welche Funktionen werden tatsächlich täglich genutzt?
- Welche Umwege haben sich im Alltag etabliert?
- Welche Informationen fehlen im richtigen Moment?
- Welche Fehler oder Rückfragen treten wiederholt auf?
- Welche Funktionen existieren, werden aber kaum verstanden?
Warum ein kompletter Neubau ebenfalls Risiken hat
- Datenmigration
- Parallelbetrieb
- Schulung und Akzeptanz
- unerwartete Altlogik
- Schnittstellen zu Fremdsystemen
- neue Fehler im Übergang
Wann ein schrittweiser Übergang sinnvoll ist
- kritische Prozesse dokumentieren
- neue Systemgrenzen definieren
- einen priorisierten Kernprozess neu umsetzen
- Schnittstellen zum Altsystem schaffen
- Daten und Funktionen schrittweise migrieren
- Altkomponenten kontrolliert ablösen
Fazit
Eine bestehende Anwendung sollte nicht allein wegen ihres Alters ersetzt werden. Entscheidend sind Wartbarkeit, technische Tragfähigkeit, Erweiterbarkeit, Nutzbarkeit und die Frage, ob der Kernprozess noch zum Unternehmen passt.
Oft liegt der wirtschaftlich sinnvollste Weg zwischen „nichts verändern“ und „alles neu bauen“: gezielte Weiterentwicklung, Integration und schrittweise Modernisierung.
Häufige Fragen
Wann sollte bestehende Software weiterentwickelt werden?
Wenn der Kernprozess noch passt, die Anwendung wartbar und technisch tragfähig ist und die Probleme vor allem in einzelnen Funktionen, Schnittstellen oder Nutzerwegen liegen.
Wann sollte Software komplett ersetzt werden?
Ein Ersatz wird sinnvoller, wenn der fachliche Kern nicht mehr passt, die technische Basis hohe Risiken verursacht, Änderungen unverhältnismäßig teuer werden oder das System strategische Weiterentwicklung dauerhaft blockiert.
Muss veraltete Software automatisch neu entwickelt werden?
Nein. Alter allein ist kein ausreichendes Kriterium. Entscheidend sind Sicherheitsstatus, Wartbarkeit, Architektur, Erweiterbarkeit und die Eignung für den aktuellen Geschäftsprozess.
Können Schnittstellen einen Systemwechsel vermeiden?
Ja. Wenn das Kernsystem weiterhin geeignet ist, können APIs, Imports, Exports oder ergänzende Anwendungen fehlende Verbindungen zu anderen Prozessen herstellen.