Code-Sanierung vs. Rewrite: Der Unterschied und wann was richtig ist

Ihre Software läuft. Aber jede Änderung dauert länger als früher. Jeder behobene Fehler zieht zwei neue nach sich. Spätestens jetzt fallen in Gesprächen zwei Begriffe: Code-Sanierung und Rewrite. Beide versprechen Besserung. Beide bedeuten grundverschiedene Dinge. Und beide haben ihre Berechtigung, nur selten im selben Fall.

Dieser Artikel erklärt den Unterschied zwischen Code-Sanierung und Rewrite. Sie bekommen konkrete Kriterien an die Hand, mit denen Sie die richtige Wahl treffen. Ohne Fachchinesisch, dafür mit klaren Empfehlungen.

Was bedeutet Code-Sanierung?

Eine Code-Sanierung bereinigt bestehenden Code, ohne die Architektur zu ändern. Das System bleibt dasselbe. Es wird nur sauberer, sicherer und leichter wartbar.

Typische Arbeiten bei einer Sanierung:

• Refactoring: Code wird umstrukturiert, ohne sein Verhalten zu ändern. Details erklärt unser Glossar-Eintrag zum Refactoring. Ziel ist Code, den Entwickler wieder verstehen und sicher ändern können.
• Updates: Veraltete Bibliotheken und Sprachversionen werden aktualisiert. Eine Bibliothek ist fertiger Code von Dritten, den Ihre Software mitbenutzt.
• Totes entfernen: Funktionen, die niemand mehr nutzt, fliegen raus. Weniger Code bedeutet weniger Angriffsfläche und weniger Wartung.
• Tests ergänzen: Automatische Prüfungen stellen sicher, dass nach jeder Änderung alles funktioniert.

Das Entscheidende: Ihre Software bleibt durchgehend in Betrieb. Ihre Kunden merken von der Sanierung im Idealfall nichts. Was sie merken: Neue Funktionen kommen wieder schneller.

Wie so ein Projekt konkret abläuft, beschreibt unser Artikel zur Software-Sanierung.

Was bedeutet Rewrite?

Ein Rewrite ist die komplette Neuentwicklung. Das alte System wird ersetzt. Ein Team baut die Software von Grund auf neu, meist mit aktueller Technologie.

Das klingt verlockend. Endlich ein sauberer Start. Keine Altlasten, moderne Werkzeuge.

Die Praxis sieht oft anders aus. Ein Rewrite dauert fast immer länger als geplant. Das alte System enthält Geschäftslogik aus vielen Jahren. Sonderfälle, Ausnahmen, Regeln, die nie jemand aufgeschrieben hat. All das muss die neue Software ebenfalls beherrschen. Sonst ist der Neuanfang ein Rückschritt.

Dazu kommt ein wirtschaftlicher Punkt. Während des Rewrites läuft das alte System weiter. Sie bezahlen also zwei Systeme gleichzeitig. Eines verdient Geld. Das andere noch nicht.

Das heißt nicht, dass ein Rewrite falsch ist. Es heißt nur: Er braucht einen guten Grund. "Der Code ist alt" reicht als Grund nicht aus.

Was passiert, wenn Sie gar nichts tun?

Keine Entscheidung ist auch eine Entscheidung. Meist die teuerste.

Unbereinigter Code sammelt technische Schulden an. Jede Änderung wird aufwendiger. Fehler häufen sich. Irgendwann traut sich niemand mehr an bestimmte Stellen im Code.

Gleichzeitig altert das Fundament. Sprachversionen und Frameworks erreichen ihr End of Life, also das offizielle Support-Ende. Sicherheitslücken bleiben dann offen. Aus einem Wartungsthema wird ein Sicherheitsthema.

Der wichtigste Punkt: Warten macht die Entscheidung nicht leichter. Die Sanierung wird jedes Jahr umfangreicher. Der Rewrite wird jedes Jahr riskanter. Entscheiden Sie, solange Sie noch beide Optionen haben.

Wann ist die Code-Sanierung richtig?

Die Sanierung ist der richtige Weg, wenn der Kern Ihrer Software gesund ist. Drei Kriterien helfen bei der Einschätzung.

Die Architektur trägt noch

Die Grundstruktur passt zu dem, was die Software heute leisten soll. Die Probleme liegen in Details: unübersichtlicher Code, fehlende Tests, veraltete Bibliotheken. Das alles lässt sich Schritt für Schritt beheben.

Das Fachwissen steckt im Code

Ihre Software bildet Prozesse ab, die sonst nirgends dokumentiert sind. Preisregeln, Schnittstellen, gewachsene Abläufe. Dieses Wissen bei einem Neuanfang zu rekonstruieren, ist teuer und fehleranfällig. Die Sanierung erhält es.

Der Betrieb darf nicht stillstehen

Ihr Geschäft hängt am laufenden System. Sie können nicht monatelang auf neue Funktionen verzichten. Eine Sanierung liefert in kleinen Schritten und das System bleibt dabei produktiv.

Treffen diese Punkte zu, lohnt sich der Erhalt. Wie Sie dabei vorgehen, zeigt unser Leitfaden technische Schulden abbauen.

Wann ist ein Rewrite richtig?

Manchmal ist der Neuanfang ehrlicher. Auch dafür gibt es klare Anzeichen.

Die Technologie ist am Ende

Die Plattform wird nicht mehr weiterentwickelt. Es gibt keine Entwickler mehr dafür. Updates sind unmöglich, nicht nur unbequem. Wer heute noch auf einem toten Framework aufbaut, investiert in eine Sackgasse.

Das Geschäftsmodell hat sich geändert

Die Software wurde für ein anderes Geschäft gebaut als das, das Sie heute betreiben. Sie verbiegen seit Jahren ein System für Zwecke, für die es nie gedacht war. Dann konserviert eine Sanierung nur das falsche Fundament.

Der Umbau kostet mehr als der Neubau

In seltenen Fällen ist der Code so unstrukturiert, dass jede Bereinigung teurer wird als ein Neuanfang. Das ist die Ausnahme, nicht die Regel. Diese Diagnose sollte eine gründliche Analyse stellen, kein Bauchgefühl.

Eine ausführliche Gegenüberstellung finden Sie in unserem Artikel Refactoring vs. Rewrite.

Der Mittelweg: schrittweise ablösen

Zwischen Sanierung und Rewrite gibt es einen dritten Weg. Sie erneuern das System Stück für Stück. Neue Teile entstehen in moderner Technik. Alte Teile laufen weiter, bis ihr Ersatz fertig ist.

Dieses Vorgehen heißt Strangler-Fig-Pattern, benannt nach der Würgefeige. Die Pflanze umwächst einen Baum, bis sie ihn ersetzt hat. Klingt brutal, ist aber die risikoärmste Form der Ablösung. Kein Stillstand, kein riskanter Stichtag, laufend sichtbare Ergebnisse.

Für viele mittelständische Systeme ist dieser Weg die beste Wahl. Er verbindet die Sicherheit der Sanierung mit den Vorteilen neuer Technik.

Drei Fragen für Ihre Entscheidung

Sie müssen kein Entwickler sein, um die Richtung vorzugeben. Drei Fragen bringen Klarheit.

Erstens: Was genau tut weh? Sind es langsame Änderungen und häufige Fehler? Das spricht für die Sanierung. Oder kann die Software grundsätzlich nicht mehr, was Ihr Geschäft braucht? Das spricht für den Rewrite.

Zweitens: Was wissen Sie über Ihr System? Gibt es Dokumentation, Tests, erreichbare Entwickler? Je weniger davon vorhanden ist, desto riskanter wird ein Neuanfang. Denn dann weiß niemand vollständig, was die neue Software alles können muss.

Dritte Frage: Was passiert bei einem Fehlschlag? Eine gescheiterte Sanierung kostet Budget, das System läuft trotzdem weiter. Ein gescheiterter Rewrite kann Jahre kosten. Wer das Risiko nicht tragen kann, wählt den schrittweisen Weg.

Beantworten Sie diese Fragen schriftlich, bevor Sie mit Dienstleistern sprechen. Das schützt vor Angeboten, die zum Anbieter passen statt zu Ihrem Problem.

Fazit: Erst analysieren, dann entscheiden

Code-Sanierung und Rewrite beantworten dieselbe Frage auf verschiedene Weise: Wie bleibt Ihre Software zukunftsfähig? Die Sanierung erhält, was funktioniert. Der Rewrite ersetzt, was nicht mehr zu retten ist. Die schrittweise Ablösung verbindet beides.

Welcher Weg für Sie passt, entscheidet nicht die Mode, sondern der Zustand Ihres Systems. Genau den schauen wir uns an. Ehrlich, nachvollziehbar und ohne Verkaufsdruck. Wenn die Sanierung reicht, sagen wir das. Wenn nur der Neuanfang hilft, sagen wir das auch.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.