Next.js Migration & Rettung
Pages Router zu App Router, ein anderes Framework zu Next.js oder eine geerbte Codebasis, die niemand anfassen will — inkrementell migriert, im laufenden Betrieb, ohne Feature-Freeze.
Zwei Situationen führen die meisten Teams hierher. Entweder ist eine bestehende Next.js-Anwendung dem Pages Router entwachsen und der inkrementelle Weg ist nicht offensichtlich — oder eine von jemand anderem gebaute Anwendung ist zu etwas geworden, das das aktuelle Team nicht mehr zu deployen wagt.
Beides ist lösbar. Keines erfordert einen Rewrite.
Pages Router zu App Router
Die beiden Router arbeiten zusammen. Das ist die gesamte Strategie: eine
gemeinsame Anwendung, in der app/ und pages/ koexistieren, migriert von den
Blättern her, wobei jede Route hinter ihrem eigenen Pull Request und ihrer
eigenen Verifikation umzieht.
Wir beginnen bei Routen mit wenig Traffic und geringem Risiko, um die
gemeinsamen Muster aufzubauen — Layouts, Datenzugriff, Error Boundaries — und
arbeiten uns dann zu den Routen vor, auf die es ankommt. Datenabrufe wandern
aus getServerSideProps in den Komponentenbaum. Client-State, der nur existiert
hat, um das alte Rendering-Modell auszugleichen, verschwindet meist ganz.
Ein anderes Framework zu Next.js
Create React App, Vite-SPAs, Gatsby und ein langer Schwanz maßgeschneiderter Webpack-Konfigurationen. Der mechanische Teil sind Routing und Build-Konfiguration; der Teil, der Urteilsvermögen braucht, ist die Entscheidung, welche Annahmen der Anwendung Framework-Artefakte waren und welche echte Anforderungen.
Geerbte Codebasen
Bevor wir etwas ändern, lesen wir alles. Zwei Wochen Orientierung ergeben eine Abhängigkeitskarte, ein Rendering-Inventar jeder Route, eine Liste dessen, was tot ist, und ein priorisiertes Risikoregister. Dieses Dokument gehört Ihnen, unabhängig davon, wie Sie sich danach entscheiden — es ist das, was die Codebasis wieder steuerbar macht, und mehrere Kunden haben es intern übernommen und die Arbeit selbst erledigt.
Wir halten das für ein vernünftiges Ergebnis.