Legacy-Migration ohne Big Bang: Vier Wege aus dem Altsystem

Irgendwann steht jedes gewachsene System an diesem Punkt: Die Runtime ist aus dem Support, jede Erweiterung dauert länger als die davor, und niemand im Team fasst den Kern noch freiwillig an. Die erste Reaktion ist fast immer dieselbe — neu bauen. Und genau dieser Reflex macht die Legacy-Migration teurer, als sie sein müsste.

Denn „modernisieren” ist keine einzelne Entscheidung, sondern eine Wahl zwischen vier sehr unterschiedlichen Wegen. Dieser Beitrag stellt sie gegenüber: Runtime-Uplift, Strangler Fig, Branch by Abstraction und der Big-Bang-Rewrite — was sie kosten, wo sie scheitern, und welche einzige Frage die Wahl in den meisten Fällen bereits entscheidet.

Warum der Rewrite-Reflex so teuer ist

Der Rewrite ist attraktiv, weil er ehrlich klingt: Das Alte ist kaputt, also bauen wir es richtig. In der Praxis unterschätzt er zwei Dinge systematisch.

Das Alte kann mehr, als irgendjemand weiß. In einem zehn Jahre alten System steckt eine Dekade an Sonderfällen, Workarounds und stillen Absprachen mit der Realität. Das meiste davon steht nirgends. Es ist auch nicht „Legacy-Ballast” — es ist die Fachlichkeit, für die Ihre Kunden bezahlen. Ein Rewrite beginnt bei null und muss sich diese Dekade Stück für Stück zurückerobern, meistens über Produktionsfehler.

Während des Rewrites steht das Geschäft nicht still. Das Altsystem braucht weiter Fixes, der Markt weiter Features. Also läuft beides parallel — zwei Systeme, zwei Teams, jede Änderung doppelt. Je länger der Rewrite dauert, desto weiter läuft ihm das Ziel davon. Viele dieser Projekte sterben nicht an Technik, sondern an dieser Schere.

Der eigentliche Denkfehler steckt aber schon eine Ebene früher — in der Diagnose.

Die eine Frage: Fundament oder Modell?

Bevor Sie über Wege reden, klären Sie, wo das Problem tatsächlich sitzt:

Ist das Fundament alt — oder das Modell falsch?

Das Fundament ist die Technik unter Ihrer Fachlichkeit: Runtime, Framework, Bibliotheken, Build, Deployment, Betrieb. Ein altes Fundament tut weh, ist aber ein lösbares Problem — die Fachlichkeit darüber kann völlig in Ordnung sein.

Das Modell ist der fachliche Kern: Wie das System die Welt abbildet, welche Begriffe es kennt, welche Regeln es durchsetzt. Ein falsches Modell tut anders weh: Jede neue Anforderung passt nicht, jede Erweiterung braucht eine Ausnahme, und die Ausnahmen haben inzwischen Ausnahmen.

Der Unterschied entscheidet alles:

• Fundament alt, Modell trägt → Sie brauchen einen Uplift. Fassen Sie die Fachlichkeit nicht an. Sie ist Ihr Wert, nicht Ihr Problem.
• Modell am Ende → Sie brauchen Ersatz. Aber inkrementell, nicht als Sprung ins Dunkle.

Die teuerste Verwechslung im Mittelstand ist die erste als die zweite zu lesen: ein System mit gesunder Fachlichkeit auf einer alten Runtime komplett neu zu schreiben. Sie werfen die wertvollste Substanz weg, um ein Problem zu lösen, das eine Etage tiefer lag.

Wie ein System überhaupt in diesen Zustand gerät — und welche Signale früh sichtbar sind — beschreiben wir in Software-Erosion: Eine stille Bedrohung.

Weg 1 — Runtime-Uplift: das Fundament tauschen, das Haus behalten

Beim Uplift heben Sie die Anwendung auf eine aktuelle technische Basis, ohne die Geschäftslogik neu zu denken. Runtime, Framework, Abhängigkeiten, Build- und Deployment-Kette werden modernisiert; das fachliche Verhalten bleibt identisch. Inkompatible APIs werden ersetzt, nicht neu erfunden.

Das klingt unambitioniert und ist meistens genau richtig. Sie bekommen den Großteil des Nutzens — aktuelle Runtime, Sicherheits-Updates, Performance, wieder wartbare Builds, ein Team, das den Stack kennt — bei einem Bruchteil des Risikos. Und Sie behalten die Dekade Fachlichkeit, die niemand dokumentiert hat.

Genau diesen Weg sind wir bei Omniga gegangen: eine heterogene Anwendungslandschaft von .NET Framework 4.6 auf .NET 8 — interne Systeme und aktiv genutzte SaaS-Plattformen. Statt eines Rewrites haben wir die Anwendungen nach Kritikalität priorisiert und einzeln migriert, die bestehende Geschäftslogik bewusst erhalten und die CI/CD-Pipelines mitgezogen. Die kundenseitigen Plattformen liefen dabei ohne Ausfallzeiten weiter.

Wann Uplift passt: Die Fachlichkeit trägt, der Schmerz kommt aus Runtime, Betrieb oder Sicherheit. Das ist häufiger der Fall, als der erste Impuls vermuten lässt.

Wo Uplift nicht reicht: Wenn das Modell selbst die Bremse ist. Ein Uplift macht ein falsches Modell schneller und sicherer — aber nicht richtig.

Weg 2 — Strangler Fig: das Neue wächst um das Alte

Muss Fachlichkeit ersetzt werden, ist der Strangler Fig das Muster der Wahl. Der Name geht auf Martin Fowler zurück, der ihn nach der Würgefeige benannt hat: Sie wächst um ihren Wirtsbaum, bis sie ihn ersetzt hat und er verschwindet.

Auf Software übertragen:

1. Fassade davor. Aller Traffic läuft über eine Schicht vor dem Altsystem — Gateway, Proxy, Routing-Layer. Fachlich passiert erst einmal nichts; Sie gewinnen nur die Kontrolle darüber, wer welche Anfrage beantwortet.
2. Ein Stück herausschneiden. Eine abgegrenzte Fähigkeit wird neu gebaut — klein genug für wenige Wochen, groß genug, um für sich zu stehen.
3. Traffic umlegen. Die Fassade schickt diesen Ausschnitt auf das neue System. Erst intern, dann für einen Teil der Nutzer, dann für alle.
4. Wiederholen. Stück für Stück, bis das Alte nichts mehr beantwortet.
5. Abschalten. Was keinen Traffic mehr sieht, kann weg.

Der eigentliche Gewinn ist nicht die Technik, sondern die Umkehrbarkeit. Jeder Schnitt ist klein, jeder Schritt liefert Nutzen, und wenn ein Ausschnitt sich als Fehlgriff erweist, legen Sie das Routing zurück. Es gibt keinen Tag X, an dem alles gut gehen muss.

Wo es wehtut — und das verschweigen die meisten Darstellungen:

• Die Daten. Alt und Neu greifen eine Zeit lang auf dieselbe Fachlichkeit zu. Wem gehört der Datensatz, wer darf schreiben, wie bleibt beides konsistent? Das ist der schwierigste Teil, nicht das Routing.
• Die Zwischenzeit ist der Normalzustand. Sie betreiben über Monate zwei Systeme plus eine Fassade. Wer den Weg wählt, muss diese Phase aushalten wollen.
• Halb fertig ist schlimmer als gar nicht angefangen. Ein abgebrochener Strangler Fig hinterlässt zwei halbe Systeme und eine Fassade, die niemand mehr versteht. Das Muster braucht Durchhaltewillen — der Schnitt darf keine Dauerlösung werden.

Wann Strangler Fig passt: Das Modell muss weg, das System darf aber keine Minute stehen — kundenseitige Plattformen, Systeme mit echten Umsätzen daran.

Weg 3 — Branch by Abstraction: Umbau innerhalb einer Codebasis

Sitzt das Problem nicht zwischen Systemen, sondern mitten in einer Codebasis — eine zentrale Komponente, an der alles hängt —, hilft keine Fassade. Hier greift Branch by Abstraction:

1. Sie ziehen eine Abstraktion vor die Altkomponente und leiten allen Zugriff darüber.
2. Hinter der Abstraktion entsteht die neue Implementierung — parallel zur alten, beide lauffähig.
3. Ein Schalter entscheidet, welche Implementierung greift. Umschalten passiert schrittweise und ist jederzeit zurücknehmbar.
4. Ist die neue Seite überall aktiv, fallen alte Implementierung, Schalter und oft auch die Abstraktion wieder weg.

Der Charme: Sie bauen groß um, ohne jemals einen langlebigen Branch zu haben. Der Code bleibt durchgehend integrierbar und auslieferbar — auch mitten im Umbau. Der Preis: Sie leben eine Weile mit zwei Implementierungen und einem Schalter, und Sie müssen die Aufräumphase wirklich durchziehen. Vergessene Schalter sind die technische Schuld von morgen.

Wann Branch by Abstraction passt: Austausch eines Kerns innerhalb eines Systems — Persistenzschicht, Berechnungskern, Integrationsschicht.

Wann Big Bang doch richtig ist

Der Vollständigkeit halber, und weil es ehrlich ist: Manchmal ist der Neubau die richtige Wahl.

• Das System ist klein genug. Was ein kleines Team in wenigen Wochen neu baut, braucht keine Migrationsstrategie. Ein Strangler Fig für ein überschaubares Tool ist Overhead.
• Die Fachlichkeit ist ohnehin hinfällig. Wenn sich das Geschäftsmodell geändert hat und das Alte die falsche Aufgabe löst, gibt es keine Substanz zu retten.
• Das Alte lässt sich nicht anfassen. Keine Quellen, kein Know-how, keine Testbarkeit — dann ist Ersatz keine Entscheidung, sondern eine Feststellung.

Was Big Bang niemals ist: die Standardantwort auf ein müdes Fundament.

Die Entscheidungsmatrix

Kriterium	Runtime-Uplift	Strangler Fig	Branch by Abstraction	Big Bang
Problem sitzt im	Fundament	Modell (System-Ebene)	Modell (Code-Ebene)	Aufgabe selbst
Geschäftslogik	bleibt erhalten	wird ersetzt	wird ersetzt	wird neu gedacht
Laufender Betrieb	ungestört	ungestört	ungestört	Schnitt nötig
Zusatz-Aufbau	gering	Fassade + Routing	Abstraktion + Schalter	keiner
Rückweg	jederzeit	jederzeit	jederzeit	keiner
Erster Nutzen	früh	früh	früh	erst am Ende
Risiko	gering	mittel	gering–mittel	hoch
Passt, wenn…	Runtime alt, Fachlichkeit trägt	Modell am Ende, Betrieb kritisch	Kern-Austausch in einer Codebasis	System klein oder Aufgabe hinfällig

Die Matrix zeigt das eigentliche Muster: Die ersten drei Wege sind umkehrbar, der vierte nicht. Genau darin liegt ihr Wert. Nicht darin, dass sie schneller wären — oft sind sie es nicht —, sondern darin, dass ein Irrtum keine Katastrophe ist, sondern eine Korrektur.

Wie Sie zur Entscheidung kommen

Die Wege lassen sich kombinieren, und in größeren Landschaften ist das der Normalfall: Uplift für die Systeme, deren Fachlichkeit trägt; Strangler Fig für die zwei, deren Modell wirklich am Ende ist. Die Kunst liegt nicht darin, ein Muster zu wählen, sondern darin, pro System ehrlich zu diagnostizieren.

Diese Diagnose braucht wenig Zeit, aber Erfahrung: Wo endet Fundament, wo beginnt Modell? Welche Fachlichkeit ist wertvoll, welche nur alt? Welche Abhängigkeit hält das ganze Kartenhaus? Genau dafür ist eine kompakte Discovery-Phase da — sie ersetzt den Bauchentscheid durch eine belastbare Grundlage, bevor Budget fließt.

Wohin die Reise danach geht, ist eine eigene Frage: Ob ein modularer Monolith oder Microservices das richtige Ziel sind, ordnen wir in Modularer Monolith vs. Microservices ein. Nur eines vorweg: Die Zielarchitektur entscheidet nicht über den Weg dorthin. Auch ein Microservice-Ziel erreicht man inkrementell.

Fazit

„Neu bauen” ist selten falsch, weil das Alte gut wäre — sondern weil es fast immer die teuerste Antwort auf eine Frage ist, die noch niemand sauber gestellt hat. Diese Frage lautet: Ist unser Fundament alt oder unser Modell falsch?

Trägt die Fachlichkeit, heben Sie das Fundament — der Uplift ist unspektakulär und meistens richtig. Muss die Fachlichkeit weichen, ersetzen Sie sie schrittweise: Strangler Fig zwischen Systemen, Branch by Abstraction innerhalb einer Codebasis. Der Big Bang bleibt die Ausnahme mit einem sehr engen Fenster.

In allen drei ernstzunehmenden Fällen gilt dasselbe Prinzip: kleine Schritte, jederzeit umkehrbar, das Geschäft läuft weiter. Das ist kein Kompromiss gegenüber dem großen Wurf. Das ist der große Wurf.

---

Tech42 begleitet Legacy-Modernisierungen im Mittelstand — von der ehrlichen Diagnose über die Software-Architektur bis zur Umsetzung im laufenden Betrieb. Wenn Sie wissen wollen, ob Ihr System einen Uplift braucht oder einen Ersatz, klären wir das im kostenlosen Erstgespräch — bevor Sie sich auf einen Weg festlegen, von dem es keinen Rückweg gibt.