Wenn ein System weiterhin wichtige Abläufe unterstützt und wertvolle Daten enthält, sollte ein kompletter Neubau nicht die erste Reaktion sein. Zunächst muss geklärt werden, wo die eigentliche Grenze liegt: in der gesamten Architektur, in einem problematischen Modul, im Datenmodell, in einer Integration oder im Prozess der Auslieferung.
Ein Neubau ist sinnvoll, wenn sich wesentliche Teile nicht sicher erhalten lassen oder die Grenzen der bisherigen Lösung ein wichtiges Geschäftsziel verhindern. In vielen anderen Fällen sind Stabilisierung, der Austausch des schwierigsten Moduls oder eine kontrollierte Migration in Etappen der bessere Anfang.
Die Entscheidung muss auf dem konkreten Code, den Daten und dem Betriebsablauf beruhen. Weder das Alter der Anwendung noch der Name der Technologie reichen dafür aus.
„Wir schreiben alles neu“ klingt einfacher, als es ist
Ein altes System kann die tägliche Arbeit erschweren. Releases dauern lange, eine Korrektur beschädigt eine andere Funktion und die Dokumentation endet Jahre vor dem heutigen Stand. Eine neue Anwendung verspricht Ordnung. Gleichzeitig können dabei Geschäftsregeln verloren gehen, die nirgends beschrieben sind, auf die sich Mitarbeiter und Kunden aber täglich verlassen.
Auch Daten, Berechtigungen, Berichte, Integrationen und bisher manuell behandelte Ausnahmen müssen verstanden und bei Bedarf neu umgesetzt werden. Werden diese Punkte zu spät erkannt, kann das neue System technisch sauberer sein und trotzdem schlechter zum Unternehmen passen.
Neuer Code ist nicht allein deshalb wertvoll, weil er neu ist. Er soll ein konkretes Problem lösen: Risiken reduzieren, Änderungen sicherer machen, die Stabilität verbessern oder die Arbeit der Nutzer vereinfachen.
Vier mögliche Wege
| Weg | Wann er sinnvoll sein kann | Was abgesichert werden muss |
|---|---|---|
| Stabilisieren und weiterentwickeln | Der Kern funktioniert, während sich Ausfälle und teure Änderungen auf wenige Bereiche konzentrieren. | Kritische Prozesse, Datensicherungen, Tests der wichtigsten Abläufe, Deployment und aussagekräftige Fehlererkennung. |
| Ein Modul schrittweise ersetzen | Ein Teil verhindert die Weiterentwicklung, der übrige Teil der Anwendung bleibt wertvoll. | Grenzen von Daten und Integrationen sowie die Zeit, in der altes und neues Modul parallel laufen. |
| Kontrolliert migrieren | Die bisherige Plattform oder das Datenmodell setzt grundlegende Grenzen, der Übergang lässt sich aber aufteilen. | Datenabgleich, Reihenfolge der Umstellung, durchgängiger Betrieb und eine Rückkehrmöglichkeit. |
| Neu bauen | Wertvolle Bestandteile lassen sich nicht erhalten oder ihre Grenzen verhindern das Geschäftsziel. | Vollständiger Funktionsumfang, über Jahre entstandene Regeln, Datenmigration, Parallelbetrieb und Abschaltung des Altsystems. |
Die Tabelle strukturiert das Gespräch, ersetzt aber kein Audit. Dass Änderungen nur langsam veröffentlicht werden können, kann zum Beispiel an der Architektur, fehlenden Tests, einem unsicheren Release-Prozess oder mehreren Ursachen gleichzeitig liegen.
Vier Fragen vor der Entscheidung
- Unterstützt das System die wichtigsten Prozesse und Daten weiterhin korrekt?
- Welche Bereiche verursachen die meisten Ausfälle, manuellen Arbeiten oder teuren Korrekturen?
- Erhält die eingesetzte Technologie noch Sicherheitsupdates und läuft sie in einer gepflegten Umgebung?
- Lassen sich Module trennen und ersetzen, ohne das gesamte Unternehmen anzuhalten?
Betrifft das Problem nur einen Bereich, gibt es keinen automatischen Grund, die ganze Anwendung nachzubauen. Ein Neubau wird eher sinnvoll, wenn sich das System nicht reproduzierbar betreiben lässt, zentrale Abhängigkeiten nicht mehr unterstützt werden und Daten sowie Module nicht sicher voneinander getrennt werden können.
Wenn eine kritische PHP-Sicherheitslücke die Entscheidung ausgelöst hat, trennen Sie zuerst das dringende Update der Laufzeitumgebung von der weiteren Modernisierung. Der Leitfaden „Kritische PHP-Sicherheitslücken im Oktober 2026: Was ist bei einer alten Anwendung zu tun?“ erläutert die Reihenfolge.
Was vor der Entscheidung geprüft werden sollte
Die Prüfung darf sich nicht auf den Quellcode beschränken. Sie sollte klären:
- welche Prozesse nicht unterbrochen werden dürfen;
- wo die Daten liegen und wie sie gesichert werden;
- welche externen Systeme Informationen mit der Anwendung austauschen;
- welche Rollen und Berechtigungen tatsächlich genutzt werden;
- wie Tests, Deployment, Monitoring und Rückkehr zur vorherigen Version heute funktionieren;
- welche Übergangslösungen Teil des normalen Arbeitsablaufs geworden sind;
- welches messbare Ergebnis die erste Etappe liefern soll.
Ohne diese Antworten wird leicht der Preis einiger sichtbarer Reparaturen mit dem Preis einer unvollständigen Neuentwicklung verglichen. Das ist kein fairer Vergleich. Ein neues System muss auch Migration, Integrationen, Datenübernahme, Übergangszeit und Abnahme der kritischen Prozesse berücksichtigen.
Wann die Modernisierung sinnvoller ist
Eine schrittweise Modernisierung hat eine gute Grundlage, wenn das System noch läuft, wertvolle Daten enthält, aktive Nutzer hat und sich sinnvolle Modulgrenzen festlegen lassen. Dann können zunächst kritische Bereiche stabilisiert, wichtige Verhaltensweisen mit Tests geschützt und Fehler besser sichtbar gemacht werden.
Anschließend werden die Teile ersetzt, die das Unternehmen am stärksten behindern. Jede Etappe braucht einen eigenen Umfang, Abnahmekriterien und einen Rückweg. So beruhen spätere Entscheidungen auf Erkenntnissen aus dem realen System und nicht nur auf Annahmen vom Projektbeginn.
Wann ein Neubau sinnvoll ist
Eine neue Anwendung sollte ernsthaft erwogen werden, wenn die aktuelle Plattform nicht mehr unterstützt wird, das Datenmodell die benötigte Entwicklung verhindert, sich die Anforderungen des Unternehmens grundlegend geändert haben oder eine sichere Trennung des Altsystems mehr kosten würde als dessen kontrollierter Ersatz.
Auch dann ist keine einzige riskante Komplettumstellung erforderlich. Zuerst kann ein Prozess umgezogen und sein Ergebnis verglichen werden. Erst danach folgt der nächste Bereich. Datenmigration, Parallelbetrieb und Rückkehrmöglichkeit gehören zum Projekt und dürfen nicht erst kurz vor dem Start ergänzt werden.
Praxisbeispiel: verschiedene Entwicklungsstufen von Tempus
Das Portfolio von Domin Software dokumentiert mehrere Arbeiten für den Tempus-Shop. Dazu gehörten die Bereinigung des vorhandenen Codes und die Entwicklung eigener Module, die Aktualisierung der Plattform und der grafischen Oberfläche sowie die Migration von sStore zu PrestaShop mit Übernahme von Produkten und Kunden.
Das bedeutet nicht, dass jede Anwendung denselben Weg gehen sollte. Das Beispiel zeigt, dass „weiterentwickeln oder neu bauen“ keine einmalige Entscheidung für die gesamte Lebensdauer eines Systems sein muss. In einer Phase können Reparatur und Ausbau sinnvoll sein, in einer späteren die kontrollierte Migration auf eine neue Grundlage.
Die dokumentierten Leistungen finden Sie im Portfolio von Domin Software. Wir stellen sie weder als Beleg für ein bestimmtes wirtschaftliches Ergebnis noch als fertiges Rezept für ein anderes Unternehmen dar.
OBIBOOK: Reparatur vor dem Neubau
Beim Projekt OBIBOOK reparierten wir zunächst den CSV-Import und die Nutzung auf mobilen Geräten. Der vollständige Neubau des Buchkatalogs folgte später als eigene Etappe. Das Beispiel zeigt, weshalb eine heute nötige Reparatur und die Entscheidung über die weitere Entwicklung unterschiedliche Umfänge haben können.
Eine Brücke statt eines großen Sprungs
Bei einer größeren Veränderung können altes und neues System zeitweise nebeneinander laufen. Ausgewählte Prozesse werden an das neue Modul geleitet, Daten in Abschnitten übertragen und Ergebnisse vor der Erweiterung verglichen. Nutzer können gruppenweise wechseln, statt ihre gesamte Arbeitsumgebung an einem Tag umzustellen.
Dieser Ansatz entspricht dem von Martin Fowler beschriebenen Strangler-Fig-Muster. Er macht ein komplexes Projekt nicht automatisch einfach, kann aber das Risiko einer einmaligen Komplettablösung verringern und ermöglicht die Prüfung jeder Etappe.
Wo DominPress passen kann
Wenn die Veränderung öffentliche Seiten, Inhalte, Formulare oder neue Webmodule betrifft, kann DominPress als neue Schicht ergänzt werden, ohne sofort das gesamte interne System auszutauschen. DominPress ist jedoch keine automatische Antwort auf jedes Altsystem. Die Wahl muss zu Prozessen, Daten, Integrationen und dem langfristigen Wartungsplan passen.
Was in die erste Nachricht gehört
Für ein erstes Gespräch helfen folgende Angaben:
- eine kurze Beschreibung des Systems und seiner Nutzer;
- der wichtigste Prozess, der nicht unterbrochen werden darf;
- das konkrete Problem, das die Entwicklung blockiert oder Fehler verursacht;
- eingesetzte Technologie und Version, soweit bekannt;
- eine Liste der wichtigsten Integrationen;
- das erwartete Ergebnis der ersten Etappe;
- Informationen zu aktuellen Sicherungen, Testumgebung und Dokumentation.
Senden Sie keine Passwörter, Schlüssel, Kopien der Produktionsdatenbank oder echten Kundendaten. Für den Anfang reichen die Problembeschreibung und der Kontext, mit dem sich eine gezielte Aufgabe, eine technische Analyse oder eine erste Modernisierungsetappe unterscheiden lassen.
Geht die Modernisierung mit einem Anbieterwechsel einher, lesen Sie auch, wie die Übernahme einer Anwendung durch einen neuen Entwickler beginnt. Dort erläutern wir die Informationen, die vor der Übergabe von Code und Konten benötigt werden.
Den richtigen Weg für das bestehende System finden
Wir setzen nicht voraus, dass eine Anwendung neu geschrieben werden muss. Zuerst klären wir, was weiterhin wertvoll ist, was das Unternehmen tatsächlich blockiert und wie sich das Änderungsrisiko begrenzen lässt. Den möglichen Umfang beschreibt unsere Leistung zur Systemmodernisierung.
Wenn Sie mit einem konkreten Fall beginnen möchten, beschreiben Sie das Problem im bestehenden System.