Grosser Umbau oder schrittweises Refactoring?
Aktualisiert: 2026-09
Ein grosser Umbau verspricht einen sauberen Schnitt und bindet das Team, ohne dass fachlich etwas entsteht. Schrittweises Refactoring liefert laufend Nutzen, braucht aber Disziplin. In den meisten Fällen gewinnt der schrittweise Weg — weil grosse Umbauten selten zu Ende geführt werden.
Wenn technische Schulden spürbar werden, entsteht schnell der Wunsch nach einem grossen Aufräumprojekt: einmal richtig, danach ist alles sauber. Der Wunsch ist verständlich und geht in der Praxis meist schief.
Der Grund ist nicht technischer, sondern organisatorischer Natur. Ein Umbauprojekt ohne sichtbaren fachlichen Fortschritt steht unter dauerndem Rechtfertigungsdruck. Sobald etwas Dringendes dazwischenkommt — und das tut es —, wird es unterbrochen. Ein halb durchgeführter Umbau hinterlässt zwei Strukturen nebeneinander und ist schlechter als der Ausgangszustand.
Im direkten Vergleich
| Kriterium | Grosser Umbau | Schrittweises Refactoring |
|---|---|---|
| Risiko | Hoch, grosse Änderung auf einmal | Gering, kleine Schritte |
| Sichtbarer Fortschritt | Erst am Ende | Laufend |
| Durchhaltbarkeit | Gering, wird bei Dringlichem unterbrochen | Hoch, weil eingebettet in normale Arbeit |
| Fachliche Auslieferung | Steht während des Umbaus still | Läuft parallel weiter |
| Aufwand insgesamt | Auf dem Papier geringer | Verteilt, insgesamt oft ähnlich |
| Abbruchrisiko | Hoch, mit schlechtem Zwischenzustand | Gering, jeder Schritt ist abgeschlossen |
Wann Grosser Umbau besser ist
- —Der bestehende Ansatz ist grundsätzlich falsch, nicht nur unaufgeräumt.
- —Ein klar abgegrenzter Bereich lässt sich isoliert ersetzen.
- —Es gibt eine belastbare Zusage, dass das Projekt bis zum Ende getragen wird.
Wann Schrittweises Refactoring besser ist
- —Das System funktioniert grundsätzlich und ist nur schwer wartbar.
- —Fachliche Anforderungen laufen parallel weiter und können nicht pausieren.
- —Erfahrungsgemäss kommt regelmässig Dringendes dazwischen.
Unsere Einschätzung
Unsere Einschätzung: In den meisten Fällen ist der schrittweise Weg richtig — die Regel, jeden berührten Bereich etwas besser zu hinterlassen, trägt über Monate erstaunlich weit und braucht keine Freigabe für ein Sonderprojekt. Sie funktioniert allerdings nur mit einer verbindlichen Definition of Done, sonst wird sie unter Zeitdruck als Erstes weggelassen.
Ein grosser Umbau ist gerechtfertigt, wenn der Ansatz selbst falsch ist und schrittweises Verbessern nur eine falsche Struktur poliert. Dann gehört er als eigenes Vorhaben geplant, mit klarer Abgrenzung und der ausdrücklichen Zusage, dass er nicht bei der ersten Dringlichkeit unterbrochen wird.
Übergeordnete Leistung: Individualsoftware-Entwicklung
Passende Angebote
Legacy-Modernisierung
Legacy-Modernisierung macht gewachsene Software wieder wartbar und zukunftsfähig — schrittweise statt im riskanten Big-Bang. Ergebnis ist ein System, das sich weiterentwickeln lässt, ohne dass der laufende Betrieb dafür angehalten oder alles auf einmal neu gebaut werden muss.
Tech Due Diligence
Eine Tech Due Diligence prüft vor einer Investition oder Übernahme, was unter der Haube steckt: Architektur, Code-Qualität, Skalierbarkeit, Sicherheit und technische Schulden. Ergebnis ist eine ehrliche Risikobewertung, die eine teure Fehlentscheidung verhindern kann — bevor sie getroffen wird.
Häufige Fragen
Wie überzeugen wir die Geschäftsleitung von Refactoring?
Nicht als eigenes Projekt, sondern als Teil der normalen Arbeit — indem der Aufwand in die Schätzungen einfliesst. Ein separater Antrag für Aufräumarbeit wird fast immer abgelehnt.
Was, wenn wir für Refactoring keine Zeit haben?
Dann steigt der Aufwand für jede künftige Änderung weiter. Die Zeit wird also nicht gespart, sondern nur verlagert — mit Zinsen.
Woran erkennen wir, dass ein Umbau nötig ist?
Wenn nicht die Umsetzung unsauber ist, sondern der zugrunde liegende Ansatz nicht zum heutigen Bedarf passt. Ein sauber umgesetzter falscher Ansatz wird durch Refactoring nicht richtig.