Progressive Modernisierung gewachsener Frontends

Ein Rewrite klingt verlockend, wenn ein Frontend über Jahre gewachsen ist und die Wartung spürbar schwerer fällt - unabhängig davon, ob die Basis Vue 2, eine jahrzehntealte WordPress-Installation oder ein anderer historisch gewachsener Stack ist. In der Praxis ist ein vollständiger Neubau selten die richtige Antwort - nicht weil er technisch unmöglich wäre, sondern weil er den laufenden Geschäftsbetrieb für Monate an ein ungewisses Ergebnis koppelt. Bei der Migration der Bit.ly-Marketing-Websites auf Nuxt.js/SSR war genau dieser schrittweise Ansatz entscheidend, um die laufende Content-Produktion nicht zu unterbrechen.

Warum "alles neu" selten die richtige Frage ist

Ein gewachsenes Frontend trägt in der Regel echten Geschäftsbetrieb: Bestellprozesse, interne Tools, Kundenschnittstellen. Ein Big-Bang-Rewrite setzt all das für die Dauer des Projekts aufs Spiel - und liefert erst am Ende einen Gegenwert. Die bessere Frage ist nicht "neu bauen oder nicht", sondern "wo zuerst ansetzen, ohne den Betrieb zu gefährden".

Der schrittweise Weg

• Den Bereich mit dem größten Verhältnis von Wirkung zu Risiko identifizieren
• Klare Interop-Grenzen zwischen altem und neuem Code schaffen, bevor migriert wird
• Einzelne Module migrieren, jedes für sich abnehmbar und produktiv einsetzbar
• Das Team schrittweise auf die neue Basis mitnehmen, statt sie vor vollendete Tatsachen zu stellen

Ein Beispiel: Vue 2 zu Vue 3

Die Migration Modul für Modul erlaubt es, alten und neuen Code parallel laufen zu lassen, während sich die Basis von Vue 2 zu Vue 3 verschiebt. Composition API und <script setup> lassen sich in neu migrierten Modulen nutzen, ohne dass der Rest der Anwendung sofort mitziehen muss. Entscheidend ist eine klare Grenze: welche Module sind migriert, welche noch nicht, und wie kommunizieren sie miteinander - nicht Tempo um jeden Preis.

Dasselbe Prinzip bei ganz anderen Ausgangspunkten

Das Prinzip ist nicht auf Vue beschränkt.

Jahrzehntealte WordPress-Seiten

Bei einer jahrzehntealten WordPress-Seite kann es bedeuten, einzelne Templates oder Seitenbereiche schrittweise auf eine moderne Oberfläche umzustellen, während der Rest der Seite unverändert weiterläuft.

Gewachsene jQuery-Frontends

Bei einem gewachsenen jQuery-Frontend kann es bedeuten, zuerst den Bereich mit dem größten Wartungsaufwand zu isolieren und dort neu aufzubauen, statt die gesamte Seite in einem Schritt zu ersetzen. Der gemeinsame Nenner ist immer derselbe: eine klare Grenze zwischen Alt und Neu, statt eines Zwischenzustands, in dem für Monate weder das eine noch das andere vollständig funktioniert.

Wo KI-gestützte Codegenerierung hilft - und wo nicht

Für einzelne, klar abgegrenzte Module beschleunigt KI-gestützte Codegenerierung die eigentliche Migrationsarbeit spürbar - Boilerplate, wiederkehrende Muster, erste Entwürfe für migrierte Komponenten. Die Interop-Grenze selbst - welche Module migriert sind, welche noch nicht, und wie beide Seiten miteinander kommunizieren - ist dagegen eine architektonische Entscheidung, die geprüft und bewusst getroffen werden muss. Ein falsch gezogener Schnitt zeigt sich oft erst Monate später, wenn sich alter und neuer Code auf eine Art überschneiden, die niemand vorgesehen hatte.

Wann sich das nicht lohnt

Bei sehr kleinen, isolierten Frontends ohne nennenswerte Historie ist ein Neubau oft schneller und risikoärmer als eine schrittweise Migration mit Interop-Overhead. Der hier beschriebene Ansatz zahlt sich aus, sobald echter Geschäftsbetrieb am Software-System hängt und ein Ausfall spürbare Kosten hätte.