Softwareprojekt retten oder neustarten ist eine Entscheidung, die selten am Reißbrett fällt. Meist entsteht sie unter Termindruck, mit einem Team, das seit Monaten Überstunden macht, und einer Geschäftsführung, die Antworten will. Genau das macht sie gefährlich.
Ein Softwareprojekt lässt sich retten, wenn Tests existieren, die Architektur Module trennt und das Datenmodell im Kern zu den Geschäftsprozessen passt. Neuentwicklung ist richtig bei Technologie-Totalschaden oder einer Architektur, die sich nicht erweitern lässt. Bewertet werden sieben Kriterien, und vor der technischen Frage steht immer die Frage nach dem Ziel.
Die Frage, die im Softwareprojekt zu spät gestellt wird
Wer unter Druck entscheidet, neigt entweder dazu, an einem toten Projekt festzuhalten, weil schon so viel investiert wurde, oder alles über Bord zu werfen, obwohl der größte Teil der Arbeit noch zu retten wäre. Beide Fehler kosten Zeit und Geld. Vermeiden lassen sie sich, wenn die Entscheidung auf einem Kriterienkatalog beruht statt auf einer Stimmung im Raum.
Sieben Kriterien für die Entscheidung im Softwareprojekt
Ein belastbares Urteil braucht Antworten auf sieben Fragen, die unabhängig voneinander bewertet werden sollten.
- Codequalität. Wie viel des bestehenden Codes ist getestet, dokumentiert und verständlich für jemanden, der ihn nicht selbst geschrieben hat? Ein System ohne Tests ist nicht automatisch wertlos, aber jede Änderung daran wird zum Risiko.
- Architektur. Lässt sich das System in Teilen austauschen, oder hängt jede Komponente unauflöslich an jeder anderen? Eine monolithische Struktur ist kein Todesurteil, begrenzt aber, wie gezielt sich einzelne Schwachstellen beheben lassen.
- Datenmodell. Spiegelt die Datenstruktur die tatsächlichen Geschäftsprozesse wider, oder wurde sie im Projektverlauf mehrfach notdürftig erweitert? Ein verzogenes Datenmodell lässt sich reparieren. Es kostet nur oft mehr als eine Neuentwicklung des betroffenen Teils.
- Teamwissen. Wer im Team versteht das System noch vollständig? Bei hoher Fluktuation im Projektverlauf sinkt dieser Wert schneller, als das Organigramm zeigt.
- Restbudget. Wie viel ist noch da, und wie viel würde eine Modernisierung gegenüber einer Neuentwicklung realistisch kosten? Hier hilft eine grobe Aufwandsschätzung für beide Wege, keine Wunschrechnung.
- Terminlage. Gibt es einen Termin, der sich nicht verschieben lässt, etwa weil ein Altsystem zu einem Stichtag abgeschaltet wird? Ein solcher Termin verändert die Rechnung erheblich.
- Vertragssituation. Was regelt der Vertrag mit einem externen Dienstleister zu Abnahme, Nacherfüllung und Kündigung? Diese Frage entscheidet oft, welche Optionen überhaupt rechtlich und wirtschaftlich offenstehen.
| Kriterium | Spricht für Rettung | Spricht für Neustart |
|---|---|---|
| Codequalität | Tests vorhanden, Code lesbar | keine Tests, niemand versteht die Logik |
| Architektur | Module sind einzeln austauschbar | jede Änderung berührt das ganze System |
| Datenmodell | bildet die Prozesse im Kern ab | mehrfach notdürftig erweitert |
| Teamwissen | mehrere Personen kennen das System | Wissen ist mit Abgängen verschwunden |
| Technologie | wird weiter gepflegt, Entwickler verfügbar | Sprache oder Datenbank ohne Support |
| Restbudget | reicht für gezielte Reparatur | reicht ohnehin nur für einen Teilumfang |
| Termin | verschiebbar | Stichtag durch Abschaltung eines Altsystems |
Softwareprojekt retten oder neustarten aus technischer Sicht
Modernisierung lohnt sich, wenn die Codebasis solide ist, also wenn Tests existieren, die Architektur Module trennt und das Datenmodell im Kern zu den Geschäftsprozessen passt. Neuentwicklung ist dagegen die richtige Wahl bei Technologie-Totalschaden, etwa einer nicht mehr gepflegten Programmiersprache oder Datenbank, oder bei einer Architektur, die sich grundsätzlich nicht erweitern lässt (CodeGuides, 06/2026).
Diese Regel klingt einfacher, als sie in der Praxis ist. Die meisten Projekte liegen irgendwo dazwischen, selten an einem der beiden Extreme, etwa eine solide Kernarchitektur mit zwei oder drei Modulen, die technisch am Ende sind. In solchen Fällen ist eine Teilrettung oft die richtige Antwort, bei der zentrale Komponenten bleiben und einzelne, klar abgegrenzte Bereiche neu gebaut werden. Das 6R-Modell für Altsysteme liefert dafür die Zwischenstufen.
Warum unklare Ziele öfter das Problem sind als schlechter Code
der Projektfehlschläge gehen auf unklare Ziele zurück, nicht auf technische Qualität. Weder Modernisierung noch Neustart hilft, solange dieses Ziel fehlt.
ODCUS, 02/2026
Das ist ein wichtiger Punkt für die Rettungsentscheidung. Wenn niemand genau sagen kann, was das System am Ende leisten soll, verfolgen beide Wege dasselbe ungeklärte Ziel und scheitern irgendwann an derselben Stelle. Vor der technischen Entscheidung steht deshalb eine inhaltliche. Es braucht eine geteilte, schriftlich fixierte Vorstellung davon, was das Projekt liefern soll. Fehlt sie, ist das der erste Punkt auf der Liste, nicht die Wahl der Technologie.
Die Falle bei der Neubesetzung
Ein Muster verschlimmert die Entscheidung häufig, nämlich die übereilte Neubesetzung der technischen Führung mitten in der Krise. Eine überstürzte CTO-Neueinstellung kann ein Softwareprojekt um 12 bis 18 Monate zurückwerfen (Raphael Bauer, 05/2026), weil eine neue Führungskraft erst System, Team und die politischen Verhältnisse im Unternehmen verstehen muss, bevor sie überhaupt entscheidungsfähig ist. Diese Einarbeitungszeit fällt in genau der Phase an, in der das Projekt am wenigsten Zeit hat.
Wer stattdessen zunächst mit befristeter externer Unterstützung die Rettungs- oder Neustartfrage klärt, gewinnt Zeit, ohne sich sofort auf eine dauerhafte Besetzung festzulegen. Wie ein solches Lagebild entsteht, beschreibt der Beitrag zur ersten Projektkrise.
Sieben Kriterien, eine begründete EmpfehlungWir bewerten Codebasis, Vertrag und Teamwissen und liefern eine Aufwandsschätzung für beide Wege, nicht nur für den, an dem wir verdienen.
Wie lange die Bewertung dauern sollte
Eine vollständige Bewertung aller sieben Kriterien lässt sich bei mittelgroßen Softwareprojekten in ein bis zwei Wochen abschließen, wenn Zugriff auf Code, Verträge und Team von Anfang an gegeben ist. Wird der Zugang gestückelt gewährt, etwa weil ein bisheriger Dienstleister zögert, Repositorien vollständig zu öffnen, zieht sich die Bewertung in die Länge und mit ihr die Unsicherheit im Team. Ein klarer Zeitrahmen, kommuniziert an alle Beteiligten, verhindert, dass aus einer zweiwöchigen Prüfung ein monatelanger Schwebezustand wird.
Am Ende steht im besten Fall eine begründete Empfehlung mit Zahlen: geschätzter Aufwand für Modernisierung gegenüber Neuentwicklung, Restrisiko in beiden Fällen und eine klare Aussage dazu, welche Option bei welchem verfügbaren Budget realistisch ist. Eine reine Ja-Nein-Antwort ohne diese Zahlen lässt sich sechs Monate später kaum mehr nachvollziehen.
Häufige Fragen
Wie objektiviert man die Entscheidung zwischen Retten und Neustarten?
Über eine unabhängige Bewertung der sieben Kriterien Codequalität, Architektur, Datenmodell, Teamwissen, Restbudget, Terminlage und Vertragssituation, idealerweise durch jemanden, der nicht am bisherigen Projekt beteiligt war. Eine Punktebewertung pro Kriterium macht die Entscheidung nachvollziehbar und verhindert, dass persönliche Bindung an das bisherige System oder Frustration darüber die Bewertung verzerrt.
Was lässt sich bei einem Neustart überhaupt retten?
Meist mehr als erwartet. Ein funktionierendes Datenmodell, dokumentiertes Fachwissen über Geschäftsprozesse, einzelne stabile Module und vor allem das Wissen des Teams über gemachte Fehler lassen sich in ein neues Projekt übernehmen. Ein Neustart bedeutet selten, bei null anzufangen.
Wer sollte die Entscheidung treffen?
Die fachliche Einschätzung sollte von einer technisch erfahrenen, unabhängigen Person kommen. Die Entscheidung selbst gehört auf die Ebene, die Budget und Termine verantwortet, meist Geschäftsführung und IT-Leitung gemeinsam. Ein Interim CTO kann beide Rollen zeitlich befristet abdecken, Bewertung und Umsetzungsbegleitung.
Der nächste Schritt
torck übernimmt bei dieser Entscheidung Verantwortung im laufenden Projekt, über eine reine Beratungsrolle von außen hinaus. Technische Führung und Umsetzung liegen dann in einer Hand, mit eigenen Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat im Hintergrund. Vereinbaren Sie ein unverbindliches Erstgespräch, um Codebasis und Optionen gemeinsam einzuordnen.
German 
English 
French