Kurze Antwort
Schrittweises Reparieren ist meist weniger riskant und liefert schneller Nutzen als eine Neuentwicklung; funktionierende Geschäftsregeln und Daten sind sehr wertvoll. Eine Neuentwicklung kommt erst infrage, wenn Datenmodell oder Abhängigkeiten die bestehende Struktur unüberwindbar einschränken und das Migrationsrisiko vertretbar ist.
Wann Verbesserung Wert erhält
Funktioniert die Geschäftslogik und konzentrieren sich Probleme auf einzelne Module, kann schrittweise Verbesserung sinnvoll sein. Beginnen Sie mit Tests und Beobachtbarkeit kritischer Abläufe.
Voraussetzung für die Reparatur ist, Änderungen sicher zu machen: automatisierte Tests für kritische Abläufe, Fehlerüberwachung und eine reproduzierbare Einrichtung. Fehlt diese Grundlage, stärkt ihr Aufbau zuerst sowohl die Entscheidung für die Reparatur als auch die für die Erneuerung.
Wann Ersatz nötig sein kann
Nicht unterstützte Abhängigkeiten, ungeeignete Datenmodelle oder dauerhafte Grenzen können größere Änderungen begründen. Daten und bestehende Regeln müssen auch in einen Neubau übertragen werden.
Auch wenn eine Erneuerung nötig ist, lässt sie sich oft in Scheiben statt auf einmal durchführen: einen neuen Teil neben dem alten aufbauen und Abläufe einzeln umziehen. Dieses Vorgehen senkt das Risiko eines großen Umstiegstags.
Entscheidung dokumentieren
Nutzen Sie gleiche Ziele für alle Optionen. Halten Sie Kosten, Umstellungsrisiken, Unterbrechungen und Zeit bis zum ersten Nutzen fest. Neue Technologie allein begründet keinen Neubau.
Halten Sie die Entscheidung für alle drei Optionen anhand derselben Kriterien fest: Zeit bis zum ersten Nutzen, Migrationsrisiko, Betriebsunterbrechung und spätere Wartungskosten. Die Begeisterung des Teams für neue Technik oder das Unbehagen gegenüber der alten ist kein Grund; ein messbarer Unterschied ist es.
Ein kleiner Versuch vor der Entscheidung
Wählen Sie einen kritischen Ablauf und probieren Sie ihn als kleine Scheibe sowohl durch Reparatur als auch durch Neuaufbau aus. Halten Sie fest, wie lange es dauerte, welche Überraschungen auftraten und wie gut sich das Ergebnis testen lässt. Dieser Versuch liefert eine deutlich verlässlichere Entscheidungsgrundlage als Schätzungen.
Vor der Entscheidung vergleichen
Die folgende Tabelle ist ein Ausgangsrahmen. Füllen Sie jede Zeile für Ihr eigenes System aus; fehlt Ihnen für eine Zeile der Beleg, planen Sie vor der Entscheidung eine kleine Messung, die ihn liefert.
Häufige Fragen
Die Fragen, die bei der Entscheidung zwischen Reparatur und Neuentwicklung am häufigsten gestellt werden.
Ist alte Technologie für sich genommen ein Grund für eine Neuentwicklung?
Nein. Alt heißt nicht falsch. Wenn konkrete Folgen wie nicht mehr unterstützte Abhängigkeiten, Sicherheitsrisiken oder fehlende Fachleute für die Technik Probleme verursachen, sind das die Gründe.
Wie riskant ist eine Neuentwicklung?
Die impliziten Geschäftsregeln des alten Systems zu erfassen, die Daten zu migrieren und Alt- und Neusystem eine Weile parallel zu betreiben, kostet meist mehr Aufwand als erwartet. Um das Risiko zu senken, gehen Sie in Scheiben und mit messbaren Abnahmekriterien vor.
Was bedeutet teilweise Erneuerung?
Sie bedeutet, ein problematisches Modul oder eine Schicht herauszulösen und neu aufzubauen und den Rest zu behalten. Sind gemeinsames Datenmodell und Schnittstellen klar definiert, ist das ein guter Mittelweg.
Sollte ich für die Entscheidung eine externe Einschätzung einholen?
Meinungen im Team tragen oft eine Bindung an eine Option. Eine unabhängige Bewertung macht die Belege vergleichbar; unsere Leistung Übernahme unfertiger Softwareprojekte umfasst solche Entscheidungen.
