Sieben Entscheidungskriterien

Update, Refactoring, Replatforming oder Rewrite

0:00 Fast jedes Unternehmen hat sie: eine Anwendung, die seit vielen Jahren läuft, ohne die nichts geht und die trotzdem niemand gern anfasst. Die Laufzeitumgebung ist veraltet, jede Änderung dauert länger als die vorige, und irgendwann fällt in einer Besprechung der Satz: Das schreiben wir am besten neu. Manchmal stimmt das. Oft aber ist es der teuerste von mehreren möglichen Wegen.

0:21 In den nächsten Minuten geht es um genau diese Wege, vom Update über das Refactoring und das Replatforming bis zum Rewrite. Und um sieben Kriterien, mit denen Sie herausfinden, wie viel Veränderung Ihre Anwendung wirklich braucht.

Vier Wege und die Frage davor

0:35 Bevor wir über Kriterien sprechen, sortieren wir die Begriffe. Update, Refactoring, Replatforming und Rewrite klingen nach einer Steigerung, nach kleinen, mittleren und großen Lösungen. Das sind sie nicht. Es sind vier verschiedene Eingriffe, die an verschiedenen Stellen ansetzen. Und vor all dem steht eine Frage, die in technischen Runden gern übersprungen wird: ob die Anwendung überhaupt noch gebraucht wird.

1:00 Stellen Sie sich ein altes Haus vor. Man kann die Heizung tauschen, die Räume neu aufteilen, das Haus auf ein neues Fundament setzen oder es abreißen und neu bauen. Jede dieser Maßnahmen löst ein anderes Problem, und keine ist automatisch die bessere. Genau so arbeitet dieses Kurzmodul. Es empfiehlt keinen Weg, sondern liefert ein Entscheidungsprofil. Sie nehmen Ihre Anwendung, gehen sieben Kriterien durch und erhalten eine Tendenz.

1:25 Die kann für die ganze Anwendung gelten oder für einzelne Bereiche unterschiedlich ausfallen. In der Praxis ist eine Kombination sogar das häufigste Ergebnis. Die aufschlussreichste Spalte ist die rechte, die Risiken. Beim Update lauern Inkompatibilitäten, vor allem dann, wenn man mehrere Versionssprünge auf einmal nachholt.

1:45 Beim Refactoring ist es der Umbau ohne Netz, also ohne Tests, die zeigen, dass alles noch funktioniert. Das Replatforming verschiebt die Anwendung auf eine neue Plattform, behebt aber womöglich nicht die eigentliche Ursache. Und beim Rewrite gehen Geschäftsregeln verloren, die nur im alten Code stehen, während zwei Systeme lange parallel laufen.

2:06 Die letzte Zeile ist die realistischste: Teile der Anwendung gehen verschiedene Wege. Das hat seinen eigenen Preis, eine Übergangsarchitektur, die oft länger lebt als geplant. Wer mit Cloud-Anbietern spricht, begegnet schnell den sogenannten Rs. Microsoft unterscheidet sechs: Rehost, Replatform, Refactor, Rebuild, Retire und Retain.

2:26 AWS kommt auf sieben, unter anderem mit Repurchase, also dem Umstieg auf ein anderes Produkt. Diese Listen sind nützlich, weil sie eine gemeinsame Sprache schaffen. Aber Vorsicht bei einem Wort: Refactor bedeutet bei Microsoft eine Änderung am Code, ohne dass sich das Verhalten nach außen wesentlich ändert. Bei AWS steht Refactor gemeinsam mit Re-Architecture für einen tiefen Umbau hin zu Cloud-nativen Funktionen.

2:52 Wer in einer Besprechung Refactoring sagt, sollte also klären, was gemeint ist. Das erste Kriterium ist kein technisches. Es fragt, welchen Wert die Anwendung für das Unternehmen hat und wie lange sie diesen Wert noch liefern muss. Eine Anwendung, die nur noch von wenigen genutzt wird, ist möglicherweise ein Kandidat zum Abschalten oder für ein Standardprodukt.

3:14 Eine stabile Anwendung ohne Änderungsbedarf darf auch einfach bleiben, wie sie ist. Microsoft nennt das Retain und meint damit ausdrücklich: Kosten, Abhängigkeiten oder Risiken sprechen gerade gegen einen Umbau. Das ist keine Verlegenheitslösung, sondern eine Entscheidung. Erst wenn klar ist, dass sich die Investition lohnt, wird die Frage nach dem Weg interessant.

Ursache und Verhaltenswissen

3:35 Steht fest, dass sich die Modernisierung lohnt, folgen zwei Fragen, die viele Projekte zu früh überspringen. Erstens: Was genau ist das Problem? Zweitens: Wissen wir eigentlich, was die Anwendung heute alles tut? Beide Antworten entscheiden darüber, ob ein Umbau gelingt, und beide liegen selten so klar auf dem Tisch, wie man denkt.

3:56 Die Anwendung ist alt, das ist keine Problembeschreibung, sondern ein Gefühl. Diese Tabelle zwingt dazu, genauer hinzusehen. Eine Laufzeit ohne Herstellerunterstützung ist ein Versionsproblem und verlangt zuerst ein Update. Wenn jede Änderung lange dauert, weil alles mit allem zusammenhängt, ist es ein Strukturproblem, und dann hilft Refactoring.

4:16 Ist vor allem der Betrieb teuer und das Deployment kaum zu automatisieren, sitzt die Ursache in der Plattform. Erst wenn sich neue fachliche Anforderungen in der bestehenden Struktur kaum noch abbilden lassen, kommt ein Rewrite ernsthaft in Betracht. Das Prinzip dahinter: Die Ursache bestimmt den Weg, nicht das Alter der Software.

4:36 Ein besonders verbreitetes Missverständnis: Wir ziehen in die Cloud, dann sind wir modern. Container, Cloud oder Kubernetes ändern aber den Betrieb, nicht die Struktur der Anwendung. Schwer testbarer Code bleibt schwer testbar, auch wenn er in einem Container läuft. Der DORA-Bericht von 2024 formuliert es deutlich: Wer in die Cloud umzieht, ohne ihre Flexibilität tatsächlich zu nutzen, kann schlechter dastehen als im eigenen Rechenzentrum.

5:02 Das heißt nicht, dass Replatforming falsch ist. Es ist genau richtig, wenn Betrieb und Bereitstellung das Problem sind. Es hilft nur nicht, wenn eigentlich die Änderbarkeit fehlt. Hier lernen Sie Zählwerk kennen, unser Beispiel für dieses Modul. Zählwerk rechnet seit vierzehn Jahren Wasser und Abwasser für einen kommunalen Versorger ab.

5:22 Und wie bei fast jeder Anwendung dieses Alters steckt darin Wissen, das nirgends sonst steht: Abzüge für Gartenwasserzähler, Mindestmengen bei leerstehenden Wohnungen, Sonderregeln aus Altverträgen. Dazu ein nächtlicher Abrechnungslauf, der fehlerhafte Zählerstände still korrigiert. Niemand hat das je dokumentiert, aber die Kunden verlassen sich darauf.

5:42 Ein Rewrite ohne dieses Wissen baut die bekannten Funktionen nach. Die tatsächlich benötigten Regeln fehlen dann, und man merkt es erst bei der ersten falschen Rechnung. Bevor an einer solchen Anwendung größer gebaut wird, braucht es ein Sicherheitsnetz. Am Anfang stehen Characterization Tests. Sie prüfen nicht, wie die Anwendung sich verhalten sollte, sondern halten fest, wie sie sich heute tatsächlich verhält, mit allen Eigenheiten.

6:08 Golden-Master-Tests gehen eine Ebene höher und vergleichen ganze Abrechnungsläufe zwischen altem und neuem Stand. Contract-Tests sichern die Schnittstellen zu den Umsystemen, End-to-End-Tests die geschäftskritischen Abläufe. Und wo ein Test eine merkwürdige Regel zutage fördert, wird nicht geraten, sondern die Fachseite gefragt.

6:27 Am Ende steht eine einfache Frage: Können wir nach einer Änderung belegen, dass alles noch stimmt?

Kopplung, Qualitätsziele und Lieferfähigkeit

6:33 Mit Ursache und Verhaltenswissen ist klar, was zu tun ist und worauf man achten muss. Jetzt geht es um das Wie. Lässt sich die Anwendung in Teilen modernisieren? Woran messen wir den Erfolg? Und schafft das Team den Umbau neben dem Tagesgeschäft? Die Kriterien vier bis sechs beantworten genau diese Fragen. Der Quellcode ist nur der sichtbare Teil einer Anwendung.

6:56 Der Modernisierungsaufwand entsteht oft woanders: in Datenbanken, die mehrere Systeme gemeinsam nutzen, in Tabellen, auf die andere Anwendungen direkt zugreifen, in Batchketten, deren Reihenfolge niemand anfassen will. Bei Zählwerk liest das Kassenverfahren die Rechnungen über eine alte SOAP-Schnittstelle, und das Reporting greift direkt auf die Tabellen zu.

7:16 Jede dieser Verbindungen ist eine Stelle, an der ein Umbau nach außen sichtbar wird. Je mehr davon existieren, desto schwerer lässt sich ein Bereich allein modernisieren, und desto größer wird der Eingriff, zu dem man gezwungen ist. Wenn sich Bereiche abgrenzen lassen, gibt es ein bewährtes Muster für den schrittweisen Ersatz: Strangler Fig, benannt nach der Würgefeige, die um einen Baum herumwächst, bis sie ihn ersetzt hat.

7:40 AWS beschreibt es in drei Schritten. Zuerst entsteht eine neue Komponente neben dem Bestand. Dann laufen beide eine Zeit lang nebeneinander, und ein Proxy am Rand der Anwendung leitet die Aufrufe nach und nach auf die neue Komponente um. Der Bestand bleibt dabei als Rückfallweg erhalten. Erst wenn kein Verkehr mehr beim alten Teil ankommt, wird er entfernt. So entsteht der Nutzen schrittweise, nicht erst am Ende.

8:05 Strangler Fig hat eine Voraussetzung: Die Aufrufe müssen sich am Rand der Anwendung abfangen lassen. Was tief im Inneren steckt, etwa eine Tarifberechnung, die von vielen Stellen aufgerufen wird, erreicht man so nicht. Dafür empfiehlt AWS Branch by Abstraction. Zuerst entsteht eine Abstraktion vor der alten Komponente, dann wird hinter dieser Abstraktion die neue gebaut und schließlich umgeschaltet.

8:28 Beide Muster halten die Anwendung jederzeit lauffähig und machen Schritte rücksetzbar. Kostenlos sind sie nicht: Der Proxy kann zum Engpass werden, und wo Datenkonsistenz geteilt wird, passt Branch by Abstraction laut AWS nicht. Ohne messbares Ziel wird Modernisierung zum Technologietausch. Man hat danach ein neues Framework, aber niemand kann sagen, ob es besser geworden ist.

8:51 Deshalb fragt das fünfte Kriterium nach zwei oder drei Kennzahlen, die sich nachweisbar verbessern sollen. Das kann die Zeit sein, bis eine Änderung in Produktion ist, die Zahl der Ausfälle oder schlicht die Betriebskosten. Die Kennzahlen zeigen zugleich, welcher Weg passt. Geht es um Betrieb, liegt Replatforming nahe, geht es um Änderbarkeit, eher Refactoring.

9:11 Ein Rewrite verdient sich seine Berechtigung erst, wenn die vorhandene Struktur die Ziele nicht wirtschaftlich erreicht. Die beste Zielarchitektur nützt nichts, wenn das Team sie nicht sicher erreichen kann. Das sechste Kriterium fragt deshalb ehrlich nach den eigenen Möglichkeiten: Wer kennt den Bestand noch? Wer kennt die Zieltechnik? Wie viel Zeit bleibt neben dem Tagesgeschäft?

9:34 Gibt es einen Rückweg, falls etwas schiefgeht? DORA empfiehlt seit Jahren kleine Arbeitspakete, häufig integriert, weil kleine Änderungen schneller geprüft und stabiler ausgeliefert werden. Ein großer Rewrite mit festem Umstellungstag ist das Gegenteil davon. Über lange Zeit müssen zwei Systeme gepflegt werden, und eines davon bringt noch keinen Nutzen.

Kosten, Matrix und KI als Werkzeug

9:56 Sechs Kriterien liegen hinter uns. Im letzten Kapitel kommt das siebte dazu, die Frage nach Kosten und Nutzen über einen längeren Zeitraum. Danach führen wir alles in einer kompakten Matrix zusammen. Und zum Schluss die Frage, die heute bei keinem Modernisierungsprojekt fehlt: Was können KI-Werkzeuge dabei leisten, und wo liegen ihre Grenzen?

10:17 Bei Modernisierungen wird gern nur eine Zahl verglichen: Was kostet die Entwicklung? Das greift zu kurz. Das siebte Kriterium betrachtet drei bis fünf Jahre und rechnet alles ein, was in dieser Zeit anfällt. Dazu gehören der Parallelbetrieb zweier Systeme, die Datenmigration, Schulungen und die Produktivität, die während der Umstellung verloren geht.

10:37 Und ein Posten, der fast immer fehlt: die Fachfunktionen, die sich verzögern, weil das Team mit dem Umbau beschäftigt ist. Erst mit dieser Rechnung wird sichtbar, welche Option den größten Wert bei einem Risiko bringt, das sich das Unternehmen leisten kann. Damit der Vergleich nicht zwischen Nichtstun und Großprojekt stattfindet, lohnen sich drei Szenarien.

10:58 Das minimale Szenario umfasst nur, was nötig ist, um akute Risiken zu senken, also vor allem Updates. Das inkrementelle ergänzt ein Sicherheitsnetz aus Tests und baut gezielt die kritischsten Bereiche um. Das transformative wagt den großen Schritt: neue Plattform, neue Architektur oder Rewrite größerer Teile. Die Schichtung zeigt, dass diese Szenarien aufeinander aufbauen.

11:20 Das mittlere Szenario ist oft das überzeugendste, weil es früh Nutzen bringt und den Weg zum großen Schritt offenhält, ohne ihn zu erzwingen. Diese Matrix fasst zusammen, wohin die sieben Kriterien in typischen Situationen tendieren. Sie ist kein Regelwerk, sondern eine Abkürzung für das häufigste Ergebnis. Zwei Zeilen verdienen besondere Aufmerksamkeit. Wenn zentrale Geschäftsregeln kaum dokumentiert sind, beginnt jeder Weg mit demselben Schritt: Verhalten erfassen und absichern.

11:49 Und wenn es weder Tests noch einen fachlich Verantwortlichen gibt, ist ein Big Bang ausgeschlossen. Dann steht zuerst eine Bestandsaufnahme an. Die letzte Zeile ist ein Warnsignal. Wird ein Rewrite nur damit begründet, dass es auf der grünen Wiese schneller gehe, lohnt sich ein zweiter, kritischer Blick. KI-Werkzeuge und Coding-Agents sind bei Modernisierungen eine echte Hilfe. Sie inventarisieren Abhängigkeiten, erklären fremden Code und entwerfen Characterization Tests.

12:18 Für wiederkehrende Migrationen, etwa den Sprung auf eine neue Frameworkversion, gibt es rezeptbasierte Werkzeuge wie OpenRewrite, die Änderungen reproduzierbar ausführen statt jedes Mal neu zu generieren. Die Grenzen sind aber klar. Eine Erklärung der KI ist eine Hypothese, kein Beleg. Ein generierter Test ist noch kein verlässliches Testorakel, und ob eine merkwürdige Regel gewollt ist, weiß nur die Fachseite.

12:42 Deshalb: kleine Diffs auf eigenem Branch, Review und Tests als Pflicht, und die Freigabe bleibt beim Menschen.

Übung

12:50 Jetzt sind Sie an der Reihe. Sieben Kriterien sind nur so gut wie ihre Anwendung auf einen echten Fall. In dieser Übung nehmen Sie entweder Ihre eigene Anwendung oder Zählwerk und führen die Kriterien zu einer begründeten Entscheidung und einem ersten, kleinen Schritt zusammen. Hier noch einmal Zählwerk im Überblick. Ein Monolith auf einem veralteten Application Server, eine zentrale Datenbank, eine SOAP-Schnittstelle zur Kasse, ein nächtlicher Abrechnungslauf, kaum Tests und Releases nur einmal im Quartal.

13:18 Vier Vorschläge liegen auf dem Tisch: aktualisieren, umbauen, in Container verschieben oder komplett neu schreiben. Jeder Vorschlag hat Fürsprecher, und jeder hat gute Argumente. Genau darin liegt der Reiz dieser Übung. Es geht nicht darum, den einen richtigen Vorschlag zu finden, sondern darum, mit den sieben Kriterien zu begründen, welcher Weg für welchen Teil der Anwendung trägt.

13:41 Der Ablauf führt vom Groben ins Konkrete. Am Anfang steht eine knappe Beschreibung in fünf Sätzen: Wert, Hauptproblem, Tests, Kopplung und Kapazität. Danach gehen Sie die Kriterien einzeln durch und notieren, welcher Weg dadurch wahrscheinlicher wird. Meist zeigt sich dabei, dass verschiedene Bereiche verschiedene Antworten brauchen.

14:00 Aus dem Ganzen entsteht ein Pilot, klein genug, um ihn zurückzunehmen, und mit zwei Kennzahlen, an denen sich der Erfolg ablesen lässt. Zum Schluss halten Sie fest, wann Sie abbrechen, wann Sie weitermachen und wann die Entscheidung eine Ebene höher muss. Bei dieser Aufgabe geht es nicht um das richtige Kästchen in der Matrix.

14:20 Geübt wird die Fähigkeit, eine Modernisierungsstrategie entlang nachvollziehbarer Kriterien zu begründen und sie gegen die anderen Wege abzugrenzen. Fertig sind Sie, wenn zu jedem Kriterium eine Antwort steht, für jeden Bereich eine Strategie mit Begründung und dazu ein Pilot mit zwei messbaren Zielen. Ein Hinweis aus der Praxis: Wenn am Ende ein einziger Weg für die ganze Anwendung steht, schauen Sie noch einmal genau hin.

14:43 Meist ist das Ergebnis eine Kombination, und gerade die macht eine Entscheidung belastbar.

Und jetzt?

14:49 Was bleibt? Die Frage Update, Refactoring, Replatforming oder Rewrite hat keine allgemeine Antwort. Für Ihre Anwendung gibt es aber eine begründbare, und oft fällt sie für jeden Bereich anders aus. Die sieben Kriterien helfen, diese Antwort zu finden, bevor ein teures Großprojekt beginnt. Wenn Sie tiefer einsteigen wollen, wie man ein Sicherheitsnetz um gewachsenen Code legt, in kleinen Schritten umbaut und KI-Werkzeuge dabei kontrolliert einsetzt, dann ist das Seminar KI-gestütztes Refactoring und Legacy-Modernisierung der nächste Schritt.

15:21 Alles Weitere finden Sie auf learning-master.de.