Entscheidungsraster für CTOs: Refactoring oder Neuentwicklung, mit Schweizer Praxisbeispielen

Im Zweifel refaktorieren. Eine Neuentwicklung nur dann, wenn messbare Rahmenbedingungen schrittweise Veränderung verunmöglichen. Risiko, Kosten und das verlorene Wissen einer kompletten Neuentwicklung zahlen sich gegenüber kleinen, testbaren Verbesserungen selten aus. Die eine Frage, die entscheidet: Können kleine, testbare Änderungen die geforderte geschäftliche Vorgabe erfüllen? Das Punkteraster unten macht aus dieser Frage eine belastbare Antwort.

---

Kurz gefasst:

• Erstellen Sie vor Refactoring oder Neuentwicklung eine Entscheidungsmatrix mit Geschäftskritikalität, Datenkopplung, Testabdeckung, Deployment-Risiko, Teamkapazität, Betriebskosten und rechtlichen Vorgaben.

• Refactoring ist die beste Wahl, wenn Nahtstellen vorhanden sind, die Testabdeckung ausreicht und der Weg zum Nutzen kurz ist, vor allem wenn Tests das Verhalten absichern. Eine Neuentwicklung ist nur gerechtfertigt, wenn schrittweise Änderungen die nötigen Fähigkeiten nicht liefern können.

• Neuentwicklungen sollten eng abgegrenzt und kurz sein und von klaren Abschlusskriterien geleitet werden, mit Belegen dafür, dass eine teilweise Migration die technischen oder regulatorischen Anforderungen nicht erfüllen kann. Emotionale Entscheide sind zu vermeiden.

• Schrittweise Muster wie der Strangler Fig erlauben es, Altsysteme Funktion für Funktion oder Datendomäne für Datendomäne abzulösen, sofern Observability und Rollback-Mechanismen vorhanden sind.

• Senior-Entwickler:innen müssen den Entscheidungsprozess begleiten, damit die Beurteilung auf Belegen wie Testabdeckung, Nahtstellen und Deployment-Risiko beruht und nicht auf Vorlieben oder veralteten Eindrücken.

---

Eine gewichtete Entscheidungsmatrix für Refactoring oder Neuentwicklung

Eine einzelne Meinung übersteht eine Verwaltungsratssitzung selten. Eine Punktematrix schon. Bewerten Sie jeden Faktor von 1 (spricht für Refactoring) bis 5 (spricht für Neuentwicklung) und gewichten Sie danach, was Ihr Geschäft tatsächlich bedroht.

• Geschäftskritikalität: wie viel Umsatz oder Compliance-Risiko aktuell hinter diesem System steht.

• Datenkopplung: wie eng Schema und Geschäftslogik verwoben sind und ob Sie eines davon herauslösen können, ohne das andere anzufassen.

• Testabdeckung: der Anteil der kritischen Pfade, die durch automatisierte Tests abgedeckt sind, denen Sie vertrauen.

• Deployment- und Rollback-Risiko: wie schnell Sie eine Änderung ausliefern und wieder zurücknehmen können, wenn dadurch etwas kaputtgeht.

• Teamkapazität: ob Sie die Senior-Entwickler:innen frei haben, um eine mehrmonatige Migration zu stemmen, ohne andere Arbeiten auszuhungern.

• Betriebskosten: der aktuelle Wartungsaufwand, gemessen in Stunden pro Sprint oder Franken pro Quartal.

• Rechtliche oder regulatorische Vorgaben: ob ein Rahmenwerk, eine Vorgabe zum Datenstandort oder eine Prüfanforderung schrittweise Änderungen von vornherein ausschliesst.

Gewichten Sie Geschäftskritikalität und rechtliche Vorgaben am stärksten, denn sie haben das grösste Schadenspotenzial, wenn Sie falsch entscheiden.

Ein Gesamtwert unter rund 2,5 spricht für Refactoring. Ein Wert zwischen 2,5 und 3,5 legt einen Strangler-Fig-Ansatz nahe: schrittweise Ablösung hinter einer Routing-Schicht. Über 3,5 wird eine eng abgegrenzte Neuentwicklung vertretbar, sofern mindestens zwei Faktoren dies belegen. Sammeln Sie echte Zahlen, bevor Sie irgendetwas bewerten: Testabdeckung der Unit-Tests in Prozent, mittlere Durchlaufzeit für Änderungen, Deployment-Frequenz und dokumentierte Wartungskosten pro Quartal. Ein Raster auf Basis von Vermutungen ist bloss eine Meinung mit angehängter Tabelle.

Wann alles für Refactoring spricht

Die meisten Systeme, die hoffnungslos wirken, sind in Wahrheit nur ungenügend getestet. Refactoring gewinnt, wenn diese Bedingungen zutreffen:

1. Nahtstellen sind bereits vorhanden oder lassen sich in Tagen statt Monaten schaffen, sodass Sie ein Modul isolieren und ändern können, ohne den Rest anzufassen.

2. Schrittweises Deployment ist praktikabel: Sie können eine Änderung hinter einem Feature-Flag ausliefern und innert Minuten zurücknehmen.

3. Die Testabdeckung der kritischen Pfade reicht aus, oder sie zu erhöhen ist ein begrenzter, schätzbarer Aufwand und kein Fass ohne Boden.

4. Korrektes Verhalten zählt im Moment mehr als ein reines inneres Design. Nutzer:innen bemerken keine saubere Architektur, sie bemerken Ausfälle.

5. Der Weg zum Nutzen ist kurz, und Ihr Team oder Ihr Budget verkraftet keine Neuentwicklung über mehrere Quartale, ohne andere Prioritäten zu blockieren.

Ein Modul zur Zahlungsabwicklung mit unordentlichem Innenleben, aber solider Testabdeckung ist ein Lehrbuchfall für Refactoring: Das Risiko liegt im Verhalten, nicht in der Struktur, und das Verhalten ist durch Tests bereits abgesichert.

Praxistipp: Prüfen Sie, bevor Sie irgendetwas anderes bewerten, ob Sie für das Verhalten, das Sie ändern wollen, einen Test schreiben können, der durchläuft. Wenn nicht, ist das Ihr erstes Projekt, nicht die Neuentwicklung.

Wann eine Neuentwicklung wirklich vertretbar ist

Eine Neuentwicklung rechtfertigt ihre Kosten nur unter engen, belegten Bedingungen, nicht weil der Code alt aussieht oder jemand neu im Team das Framework nicht mag.

• Die aktuelle Architektur verhindert eine Fähigkeit, die das Geschäft wirklich braucht, und es gibt keinen schrittweisen Weg, sie zu ergänzen.

• Das Datenmodell oder eine regulatorische Anforderung lässt sich nicht sicher in Teilschritten migrieren, sodass Zwischenzustände das System nicht konform oder inkonsistent machen würden.

• Nirgends im Code existiert eine brauchbare Nahtstelle, und die Kopplung zwischen den Komponenten ist so dicht, dass das Herauslösen eines Teils alle anderen gefährdet.

• Eine Neuentwicklung in Etappen lässt sich eng abgrenzen, für ein kurzes, klar begrenztes Zeitfenster finanzieren und mit ausdrücklichen Abschlusskriterien ausliefern, statt mit dem offenen Auftrag «fertig ist es, wenn es fertig ist».

Trifft in Ihrem Fall nicht mindestens zwei davon zu, entscheiden Sie sich aus emotionalen und nicht aus technischen Gründen für eine Neuentwicklung. Das ist der teuerste Fehler auf dieser Liste.

Strangler Fig und andere Muster für schrittweise Modernisierung

Das von Martin Fowler dokumentierte Strangler Fig pattern ersetzt das Verhalten von Altsystemen in kleinen, testbaren Teilstücken statt in einem einzigen Umschalten. Jedes Teilstück geht live, bewährt sich in Produktion, und erst danach startet das nächste. So wird aus einer riskanten Wette eine Reihe risikoarmer Schritte.

Drei Varianten decken die meisten realen Migrationen ab:

• Routing über ein API-Gateway: Eine Fassadenschicht leitet den Verkehr je nach Route an das Altsystem oder an die neue Komponente, sodass Sie Funktion für Funktion umstellen können.

• Funktion für Funktion herauslösen: Sie ziehen jeweils eine Fähigkeit aus dem Monolithen heraus und beginnen mit jener, die am wenigsten Risiko und am meisten Reibung mit sich bringt.

• Daten in Teilstücken migrieren: Sie migrieren eine Datendomäne nach der anderen und lassen den Rest so lange auf dem alten Schema, bis er an der Reihe ist.

Nichts davon funktioniert ohne Observability, Feature-Flags, schnelles Rollback und Shadow Writes, mit denen Sie neues und altes Verhalten vergleichen, bevor Sie dem neuen Pfad allein vertrauen.

Was Neuentwicklungen wirklich kosten und wie Sie das Risiko steuern

Die ehrlichen Kosten einer Neuentwicklung tauchen in der ursprünglichen Schätzung selten auf. Drei Treiber dominieren: der Parallelbetrieb beider Systeme, bis das neue aufgeholt hat, die Entwicklungszeit, die sich zwischen neuen Funktionen und Migrationsarbeit aufteilt, und der Abgleichaufwand, um zu bestätigen, dass das neue System dieselben Ergebnisse liefert wie das alte.

• Legen Sie Abschlusskriterien für jeden Parallelbetrieb fest, bevor Sie ihn starten: dokumentierte Schwellen für die Übereinstimmung, ein Zeitfenster für den Abgleich und ausdrückliche Freigabepunkte.

• Nutzen Sie Shadow Writes, damit das neue System echten Verkehr verarbeitet, ohne ihn auszuliefern. So validieren Sie unter produktionsgleichen Bedingungen, bevor Sie umstellen.

• Automatisieren Sie den Abgleich zwischen alten und neuen Ergebnissen, statt von Hand zu prüfen. Manuelles Prüfen skaliert über die ersten Wochen hinaus nicht.

• Achten Sie auf den Second-System-Effekt: Eine Neuentwicklung sammelt Umfang an, weil das Team jede alte Beschwerde auf einmal beheben will. So wird aus drei Monaten ein Jahr.

Technische Schulden haben einen messbaren Zinssatz. Research replicating developer productivity impact zeigt, dass technische Schulden die Zeit erhöhen, die Entwickler:innen für Tests, Analyse und Refactoring aufwenden, also genau jene Kosten, die Sie mit der Wahl des falschen Migrationswegs zu vermeiden versuchen. DORA’s 2024 research ergänzt eine deutlichere Warnung: Der Einsatz von KI allein korrelierte mit einem leichten Rückgang von Auslieferungsdurchsatz und Auslieferungsstabilität. Werkzeuge ersetzen also nicht die Grundlagen, nämlich kleine Arbeitspakete und solides Testen während einer Migration.

Scorecard und Checkliste, die Sie diese Woche durchgehen können

Bringen Sie diese Punkte in Ihr nächstes Planungsmeeting statt einer Präsentation voller Meinungen. Ziehen Sie dabei auch Erkenntnisse aus backlog refinement in Scrum bei, damit Refactoring und schrittweise Modernisierung sicherer werden.

• Schwelle für die Testabdeckung: Prüfen Sie die Abdeckung der kritischen Pfade, die Sie anfassen werden, und legen Sie ein Minimum fest, bevor die Migrationsarbeit beginnt.

• Nahtstellen erfassen: Listen Sie jede Modulgrenze auf, die bereits besteht oder sich innert zwei Sprints schaffen lässt.

• Rollback-Plan: Halten Sie in einem Abschnitt schriftlich fest, wie genau Sie die erste Änderung in Produktion rückgängig machen.

• Kostenschätzung für den Parallelbetrieb: Beziffern Sie, was der Betrieb beider Systeme über Ihr geplantes Migrationsfenster kostet.

• Freigabepunkte der Stakeholder: Benennen Sie schriftlich und vor dem Start, wer den Schritt von Shadow Writes zur vollständigen Umstellung freigibt.

Bewerten Sie jeden Faktor aus der Matrix oben, summieren Sie das gewichtete Ergebnis und lassen Sie die Schwelle über Ihren Weg entscheiden: unter 2,5 heisst Refactoring, 2,5 bis 3,5 heisst Strangler Fig, über 3,5 mit belegenden Hinweisen heisst eng abgegrenzte Neuentwicklung.

Wie Umsetzung mit erfahrenen Köpfen in der Praxis aussieht

Solche Entscheide gehen vor allem dann schief, wenn jene, die das Raster ausfüllen, beim Bau des Systems nicht dabei waren und auch das Nachfolgesystem nicht warten werden. Senior-Entwickler:innen bleiben bei uns von der ersten Beratung bis zur Übergabe im Projekt, damit die Beurteilung durchgehend gleich fundiert bleibt.

• Unsere Fallstudie zur Habitects AG zeigt eine technische Migration in voller Verantwortung, bei der die Wahl zwischen schrittweisem Herauslösen und einer eng abgegrenzten Neuentwicklung anhand genau solcher Belege getroffen wurde und nicht aus Vorliebe für neue Technologie.

• Unsere Arbeit an Legacy-Migration und Replatforming und unsere technischen Due-Diligence-Mandate wenden dasselbe Raster an, bevor wir einen der beiden Wege empfehlen.

So helfen wir Teams, den richtigen Weg zu wählen und zu gehen

Wir führen Audits und Discovery-Sprints durch, die Ihr System genau gegen die obigen Faktoren bewerten: Testabdeckung, Nahtstellen, Deployment-Risiko und Datenkopplung. So beruht der Entscheid zwischen Refactoring und Neuentwicklung auf Belegen statt auf Bauchgefühl. Lautet die Antwort schrittweise Modernisierung, setzt unsere Arbeit an Legacy-Migration und Replatforming den Strangler Fig operativ um, mit Shadow Writes und Abgleich ab dem ersten Tag. Ist eine eng abgegrenzte Neuentwicklung die ehrliche Antwort, bleiben Senior-Entwickler:innen vom ersten Gespräch zur Abgrenzung bis zur Übergabe im Projekt. Auf unserer Preisseite finden Sie die Mandatsvarianten Guidance und Intensive, und in unseren Fallstudien sehen Sie, wie sich das Raster in echten Projekten bewährt hat.

Häufige Fragen

Was ist der Unterschied zwischen Refactoring und einer Neuentwicklung?

Refactoring verändert die innere Struktur eines Systems in kleinen, getesteten Schritten, während das äussere Verhalten gleich bleibt. Eine Neuentwicklung ersetzt das System vollständig, meist ausgehend von einer neuen Codebasis oder Architektur, und bringt weit mehr Risiko und Kosten mit sich als eine schrittweise Veränderung.

Was bedeutet Refactoring?

Refactoring heisst, bestehenden Code umzubauen, um Design, Lesbarkeit oder Wartbarkeit zu verbessern, ohne von aussen zu verändern, was er tut. Tests bestätigen, dass das Verhalten konstant bleibt, während das Innenleben besser wird.

Welches andere Wort gibt es für «Refactoring»?

Gängige Alternativen sind «umstrukturieren», «aufräumen» oder «schrittweise modernisieren». Keine davon erfasst jedoch die Testdisziplin, die echtes Refactoring vom beiläufigen Neuschreiben eines kleinen Abschnitts unterscheidet. In der Praxis verwenden Teams «Refactoring» gezielt, um zu signalisieren, dass Tests das Verhalten während der ganzen Änderung absichern.

Ist ChatGPT gut im Refactoring von Code?

KI-Werkzeuge beschleunigen mechanische Refactoring-Aufgaben wie Umbenennen, Funktionen herauslösen oder sauberere Muster vorschlagen. Sie ersetzen aber die Test- und Review-Disziplin nicht, die Refactoring sicher macht. Der DORA-Bericht 2024 stellte fest, dass der Einsatz von KI allein mit geringerem Auslieferungsdurchsatz und geringerer Stabilität korrelierte. Das unterstreicht: Grundlagen wie kleine Arbeitspakete und eine starke Testabdeckung tragen die Migration, nicht das Werkzeug.

Wann sollte ich einen Strangler-Fig-Ansatz statt eines der beiden Extreme wählen?

Ein Strangler-Fig-Ansatz passt, wenn Ihr Wert in der Entscheidungsmatrix im mittleren Bereich liegt: Einige Nahtstellen bestehen, die Kopplung ist aber noch erheblich, oder die Testabdeckung ist nur teilweise statt umfassend. So ersetzen Sie das System in Teilstücken und validieren jedes davon in Produktion, bevor Sie das nächste angehen. Genau deshalb beschreibt Martin Fowler ihn in seiner ursprünglichen Darstellung als die risikoärmere Standardwahl gegenüber einer vollständigen Neuentwicklung.

Quellen

• DORA’s 2024 research

• Strangler Fig pattern

• Research replicating developer productivity impact

Empfohlen

• Fallstudien: Schweizer Softwareprojekte

• Habitects AG: Die technische Verantwortung für eine Badsanierungs-Plattform, bis durch eine Fusion hindurch.

• Die Mitte: Über 600 Websites für eine Schweizer Partei aus einem einzigen System.

• Repa Immobiliare: Ein Immobilienportfolio weg vom Papier, mit Software, die nie online geht.