Software modernisieren oder neu entwickeln? 7R-Leitfaden

Ob Sie Software modernisieren oder neu entwickeln sollten, entscheidet sich nicht für das ganze System, sondern pro Komponente: nach fachlichem Wert, technischem Zustand und dem Risiko für den laufenden Betrieb. Bei geschäftskritischen Systemen ist eine schrittweise Ablösung nach dem Strangler-Fig-Muster meist sicherer als eine komplette Neuentwicklung mit Stichtag. Welche Wege es gibt, zeigen die „7 R“ der Cloud-Migration, die wir in diesem Artikel mit einer Entscheidungstabelle einordnen.

Modernisieren, neu entwickeln, ersetzen: worum es geht

Ein gewachsenes Anwendungssystem, oft Legacy-System genannt, wird zum Handlungsfall, wenn jede Änderung Wochen dauert, Deployments von Hand laufen, nur wenige Personen den Code verstehen oder Betriebssystem und Datenbank keine Sicherheitsupdates mehr bekommen. Dann stehen drei Grundrichtungen zur Wahl:

• Modernisieren: Das bestehende System bleibt fachlich erhalten und wird technisch verbessert, etwa durch Umzug auf eine neue Plattform, Container, automatisierte Pipelines oder den Umbau einzelner Teile.
• Neu entwickeln: Die Funktionalität wird auf einer neuen Architektur neu gebaut. Das kann auf einen Schlag geschehen (Big Bang) oder schrittweise.
• Ersetzen: Ein Standard- oder SaaS-Produkt übernimmt die Aufgabe. SaaS (Software as a Service) bedeutet, dass Sie die Software als Dienst mieten, statt sie selbst zu betreiben.

Die Frage „modernisieren oder neu entwickeln“ ist deshalb meist falsch gestellt. Ergiebiger ist: Welcher Teil des Systems braucht welchen Weg, und in welcher Reihenfolge?

Die 7 R der Cloud-Migration

Ein verbreitetes Raster für diese Entscheidung sind die sieben Migrationsstrategien, die AWS in seiner Prescriptive Guidance zu Migrationsstrategien beschreibt. Sie gehen auf eine Einteilung in fünf R zurück, die Gartner 2011 veröffentlicht hat und auf die sich AWS im Beitrag „6 Strategies for Migrating Applications to the Cloud“ von 2016 ausdrücklich bezieht. Heute führt AWS sieben Strategien. Die Begriffe stammen aus der Cloud-Welt, lassen sich aber auf jede Modernisierung anwenden.

Eine vollständige Neuentwicklung fällt in diesem Raster unter „Refactor / Re-architect“ in seiner weitesten Form. AWS bezeichnet diese Strategie als die komplexeste und teuerste und empfiehlt bei großen Migrationen, Anwendungen möglichst erst umzuziehen und danach zu modernisieren.

Lift and Shift vs. Refactoring

Die meisten Diskussionen drehen sich um zwei Pole: Lift and Shift (Rehost) auf der einen, Refactoring auf der anderen Seite.

Lift and Shift bringt eine Anwendung schnell auf eine neue Infrastruktur. Der Code bleibt, wie er ist. Das senkt das Risiko des Umzugs und befreit Sie von eigener Hardware. Es löst aber kein Architekturproblem: Eine eng gekoppelte Anwendung mit manuellem Deployment ist nach dem Umzug eine eng gekoppelte Anwendung mit manuellem Deployment in der Cloud. Die Betriebskosten können sogar steigen, wenn die Anwendung dauerhaft große virtuelle Maschinen belegt, statt nach Last zu skalieren.

Refactoring verändert Code und Struktur, damit die Anwendung Cloud-Dienste nutzen kann: fachlich getrennte Services, eigene Datenhoheit je Service, Container, automatisierte Pipelines, Skalierung je Komponente. Das ist die Grundlage für schnellere Releases und neue Funktionen, verlangt aber Architekturarbeit, Tests und einen Plan für den Übergang.

Dazwischen liegt Replatform: Die Anwendung zieht um und wird an wenigen Stellen angepasst, zum Beispiel durch eine verwaltete Datenbank oder den Betrieb in Containern. Oft ist das ein pragmatischer erster Schritt, weil er den Betrieb vereinfacht und Zeit für den eigentlichen Umbau schafft. Das passt zur oben genannten Empfehlung von AWS, bei großen Migrationen erst umzuziehen und danach zu modernisieren.

Eine Faustregel: Lift and Shift, wenn der Treiber die Infrastruktur ist (Rechenzentrum, Hardware, Verträge). Refactoring, wenn der Treiber die Software selbst ist (Release-Tempo, Änderbarkeit, neue Anforderungen).

Das Strangler-Fig-Muster: schrittweise statt Big Bang

Das Strangler-Fig-Muster (englisch Strangler Fig Pattern) ist ein Vorgehen, bei dem neue Komponenten ein Altsystem Funktion für Funktion ablösen, während es weiterläuft, bis es abgeschaltet werden kann. Beschrieben hat es Martin Fowler, zunächst als „Strangler Application“, später umbenannt in „Strangler Fig Application“. Das Bild stammt aus dem Regenwald: Eine Würgefeige keimt in einer Astgabel eines Baums, wächst an ihm hinab bis in den Boden und wird eigenständig. Der Wirtsbaum kann absterben, und die Feige bleibt in seiner Form stehen.

Fowlers Kernargument gegen die Komplett-Neuentwicklung: Die Ablösung eines ernsthaften IT-Systems dauert lange, und die Nutzer können nicht so lange auf neue Funktionen warten. Beim schrittweisen Vorgehen fallen Investition und Nutzen dagegen nach und nach und sichtbar an.

So läuft es ab

1. Abfangpunkt schaffen. Eine Fassade, ein API-Gateway oder ein Proxy (eine vorgeschaltete Komponente, die Anfragen entgegennimmt und weiterleitet) nimmt alle Aufrufe an und leitet sie zunächst vollständig an das Altsystem weiter.
2. Eine Funktion herauslösen. Eine fachlich abgegrenzte Funktion wird neu gebaut, möglichst eine mit spürbarem Nutzen.
3. Verkehr schrittweise umleiten. Erst ein kleiner Teil der Aufrufe geht an die neue Komponente, dann mehr. Monitoring vergleicht Fehler und Antwortzeiten.
4. Zurückschalten können. Solange das Altsystem die Funktion noch beherrscht, ist der Rückweg ein Konfigurationswechsel und kein Notfall.
5. Altteil stilllegen. Erst wenn die neue Komponente stabil läuft, wird der alte Code entfernt. Dann folgt die nächste Funktion.

Wo es an Grenzen stößt

Das Muster braucht eine Stelle, an der sich Aufrufe umleiten lassen. Greifen Clients direkt auf die Datenbank zu, muss diese Stelle zuerst geschaffen werden. Schwierig sind außerdem gemeinsam genutzte Daten: Solange alte und neue Komponente in dieselben Tabellen schreiben, braucht es eine klare Regel, welches System führend ist. Und der Parallelbetrieb kostet Aufwand für Übergangsarchitektur, die am Ende wieder verschwindet. Fowler hält diesen Aufwand für gerechtfertigt, weil das geringere Risiko und der frühere Nutzen überwiegen.

Entscheidungstabelle: welcher Weg für welche Ausgangslage

Ist das Altsystem eher eine gewachsene Tabellen- oder Datenbanklösung als eine klassische Anwendung, gelten eigene Regeln, die wir im Beitrag zum Ablösen von Excel und Access beschreiben.

Fünf Prüffragen vor der Entscheidung

1. Liegt der Quellcode vollständig vor und lässt er sich bauen?
2. Gibt es automatisierte Tests, die das heutige Verhalten absichern?
3. Werden Laufzeit, Framework und Datenbank noch mit Sicherheitsupdates versorgt?
4. Welcher Anteil der Funktionen wird tatsächlich genutzt (aus Logs oder Datenbank messen)?
5. Wer kennt die Fachlogik heute noch?

Je mehr der ersten drei Fragen mit Nein beantwortet werden und je weniger Personen die Fachlogik noch kennen, desto eher lohnt ein schrittweiser Neubau statt einer Modernisierung des Bestands. Die Antwort auf Frage 4 zeigt zusätzlich, welche Teile Sie gar nicht erst migrieren müssen.

Aus der Praxis: Shift-to-Cloud im laufenden Betrieb

In einem Projekt unseres Gründers bei einem Premium-Automobilhersteller, umgesetzt in verantwortlicher Rolle und nicht im Auftrag von Amperbytes AI, stand genau diese Entscheidung an. Ein gewachsenes Diagnosesystem, genutzt in Werken, Remote-Software-Update-Services und im Aftersales, sollte in eine microservice-basierte Plattform (viele kleine, fachlich getrennte Dienste statt einer großen Anwendung) auf Google Cloud überführt werden. Ein Abschalten für die Migration kam nicht in Frage, weil die Nutzer das System täglich brauchen. Heute bedient die Plattform über 15.000 Nutzer pro Monat.

Eine Komplett-Neuentwicklung mit Stichtag schied damit aus, ein reiner Lift and Shift hätte die enge Kopplung und die manuellen Deployments nur verlagert. Der gewählte Weg folgte dem Prinzip der schrittweisen Ablösung:

• Zielarchitektur vor der ersten Migration. Fachlich geschnittene Services mit klaren Schnittstellen waren der Maßstab für jede Migrationsentscheidung. Dieser Maßstab sollte verhindern, dass der bisherige Monolith (eine Anwendung, die nur als Ganzes gebaut und ausgerollt wird) bloß in Dienste zerlegt wird, die weiterhin nur gemeinsam ausgerollt werden können.
• Pipelines und Infrastruktur als Code als Voraussetzung. CI/CD-Pipelines (Continuous Integration und Continuous Delivery) in Azure DevOps, Container mit Docker und Kubernetes und die Cloud-Infrastruktur als Code in Terraform bildeten das Fundament, auf dem der Parallelbetrieb beherrschbar wurde.
• Parallelbetrieb mit Rückweg. Alte und neue Komponenten liefen parallel, der Verkehr wurde schrittweise umgeleitet. Bei Problemen konnte das Team zurückschalten, ohne dass Nutzer betroffen waren.
• Observability von Anfang an. Logs, Metriken und Alarme zeigten im Parallelbetrieb, wo Last und Fehler auftreten.

Für die Entscheidung heißt das: Wer ohne Unterbrechung migrieren muss, entscheidet sich faktisch für den schrittweisen Weg und muss Pipelines, Infrastruktur als Code und Monitoring vorher einplanen. Ein Neubau mit Stichtag oder ein reiner Umzug hätten jeweils eines der beiden Ziele verfehlt: Betrieb ohne Unterbrechung oder eine änderbare Architektur. Die Details stehen im Praxisbeispiel Shift-to-Cloud eines Legacy-Diagnosesystems.

Risiken und wie Sie sie begrenzen

• Big Bang ohne Rückweg. Eine Umstellung an einem Stichtag bündelt alle Risiken auf einen Tag. Planen Sie Etappen, die sich einzeln zurücknehmen lassen.
• Bewegliches Ziel bei der Neuentwicklung. Während der Neubau läuft, ändert sich das Altsystem weiter: Gesetzesänderungen, neue Anforderungen, Fehlerbehebungen. Jede Änderung muss zweimal gebaut werden, oder das Altsystem wird eingefroren. Planen Sie, wie Änderungen in der Übergangszeit behandelt werden.
• Verborgene Fachlogik. Sonderfälle stecken oft nur im Code, nicht in der Dokumentation. Wer neu entwickelt, muss sie zuerst aus Code, Daten und Nutzung rekonstruieren. Umgekehrt gilt: Wer jede historische Sonderfunktion eins zu eins nachbaut, baut auch Funktionen, die niemand mehr braucht.
• Endloser Parallelbetrieb. Ohne festgelegte Kriterien für das Stilllegen bleibt das Altsystem jahrelang neben dem neuen stehen. Definieren Sie je Etappe, wann der alte Teil abgeschaltet wird.
• Entscheidung ohne Bestandsaufnahme. Wer ohne Blick auf Code, Betrieb und Nutzung entscheidet, entscheidet nach Bauchgefühl. Eine unabhängige Bewertung, etwa in einem Architektur-Review, schafft die Grundlage für die Wahl pro Komponente.

Typische Fallstricke bei der Umsetzung einer Migration, etwa bei Datenmigration, Abhängigkeiten und Kostenkontrolle, beschreiben wir auf der Seite zur Legacy-Modernisierung und Cloud-Migration.

Fazit

Software modernisieren oder neu entwickeln ist selten eine Entweder-oder-Frage für das ganze System. Die 7 R geben ein Raster, um jede Komponente einzeln einzuordnen: stilllegen, behalten, umziehen, ersetzen oder umbauen. Lift and Shift passt, wenn die Infrastruktur der Treiber ist, Refactoring, wenn die Software selbst bremst. Für geschäftskritische Systeme ist die schrittweise Ablösung nach dem Strangler-Fig-Muster mit Parallelbetrieb und Rückweg meist der sicherere Weg als eine Neuentwicklung mit Stichtag.

Wenn Sie vor dieser Entscheidung stehen, unterstützen wir Sie bei Bestandsaufnahme, Zielarchitektur und schrittweiser Umsetzung im Rahmen unserer Cloud-Migration und Legacy-Modernisierung. Schildern Sie uns Ihre Ausgangslage gern über das Kontaktformular.