Migration zu Next.js / Astro in Wuppertal

Nach dem Go-live ist die Migration nicht vorbei, sie ändert nur ihre Form. Bei WordPress gibt es dafür das Dashboard: Es zeigt Updates für Kern, Themes und Plugins, und ein Klick spielt sie ein. Bei einer Website auf Astro oder Next.js gibt es diesen Knopf nicht. Stattdessen gibt es eine Datei mit Abhängigkeiten, eine Sperrdatei, Release-Pläne der Projekte und Sicherheitsmeldungen, die jemand lesen muss. Diese Seite beschreibt, was an die Stelle der Plugin-Updates tritt, in welchem Takt ich aktualisiere und was eine Wartungsvereinbarung für ein solches Projekt umfasst. Wie die Wartung einer WordPress-Installation aussieht, steht auf meiner Seite WordPress-Wartung in Wuppertal und wird hier nicht wiederholt.

#Was an die Stelle der Plugin-Updates tritt

Eine Astro- oder Next.js-Website ist ein Node.js-Projekt. Ihre Bausteine stehen in der package.json: das Framework selbst, Integrationen, Bibliotheken für Formulare oder Bilder, Werkzeuge zum Testen. Jedes dieser Pakete bringt wiederum eigene Pakete mit. Die Aufgabe, die bei WordPress “Plugins aktualisieren” heißt, heißt hier “Abhängigkeiten pflegen” und hat vier Teile:

1. Das Framework auf eine unterstützte Version halten.
2. Die Laufzeit, also Node.js, auf einer Version halten, die der Hersteller noch mit Sicherheitskorrekturen versorgt.
3. Sicherheitsmeldungen zu den eingesetzten Paketen lesen und bewerten.
4. Jede Änderung so einspielen, dass sie nachvollziehbar ist und sich zurücknehmen lässt.

Der vierte Punkt ist der Vorteil gegenüber dem Dashboard-Klick: Eine Änderung ist ein Commit in einem Repository mit Vorschau-Adresse und Testlauf. Ein misslungenes Update lässt sich zurückrollen, ohne dass eine Datenbank mitgezogen werden muss.

Foto: Morty, CC BY-SA 4.0, Wikimedia Commons.

#Die Sperrdatei hält den Stand fest

Neben der package.json liegt eine Sperrdatei, bei npm die package-lock.json. Sie legt fest, welche genaue Version jedes Pakets installiert wird, auch der Pakete, die Sie nie direkt ausgewählt haben. Die npm-Dokumentation beschreibt npm ci als Befehl für automatisierte Umgebungen: Er verlangt eine vorhandene package-lock.json, schreibt nie in package.json oder die Sperrdatei und bricht mit einem Fehler ab, wenn beide nicht zusammenpassen (docs.npmjs.com, npm ci).

Für Sie bedeutet das: Der Build, den ich heute prüfe, ist derselbe, der morgen auf dem Server entsteht. Eine neue Version eines Pakets gelangt nur in die Website, wenn jemand sie bewusst in die Sperrdatei aufnimmt und der Testlauf bestanden ist. Die Sperrdatei gehört deshalb in das Repository, und ich ändere sie nur in nachvollziehbaren Commits.

#Next.js: Support-Richtlinie und Sicherheitsfreigaben

Die Support-Richtlinie von Next.js kennt zwei Phasen. Eine Hauptversion bleibt in “Active LTS”, bis die nächste erscheint, und erhält Funktionen, Fehlerkorrekturen und Sicherheitspatches. Danach wechselt sie für zwei Jahre nach ihrem Erscheinen in “Maintenance LTS” und bekommt nur noch kritische Fehlerkorrekturen und wesentliche Sicherheitsupdates. Der Betrieb mit Produktivdaten wird für Active oder Maintenance LTS empfohlen.

Stand November 2026 nennt die Seite 16.x (erschienen am 21. Oktober 2025) als Active LTS und 15.x (21. Oktober 2024) als Maintenance LTS. Für 15.x ist das ursprüngliche Ende am 21. Oktober 2026 verlängert worden, Sicherheitsfreigaben sind bis zum 31. Januar 2027 angekündigt. Version 14.x und älter stehen in der Liste der nicht mehr unterstützten Versionen. Wer auf einer solchen Version läuft, erhält laut Richtlinie nur in seltenen Ausnahmen noch einen Patch.

Seit Juli 2026 veröffentlicht das Next.js-Team Sicherheitsfreigaben nach einem festen Programm: Ungefähr einmal im Monat kündigt es auf dem Blog eine kommende Freigabe mit Zeitplan und dem höchsten erwarteten Schweregrad an, dringende Fälle erscheinen weiterhin außerhalb des Plans (Next.js-Blog, 13. Juli 2026). Ein Beispiel ist die Freigabe vom 3. November 2026: Sie brachte 16.4.5 und 15.5.29 und behebt eine Schwachstelle mit hohem und sechs mit mittlerem Schweregrad (Next.js-Blog, November 2026). Die meisten dort beschriebenen Fälle betreffen Anwendungen mit aktivierten Cache Components oder Edge-Routen. Ob Ihre Website betroffen ist, hängt also von der Konfiguration ab, und genau das prüfe ich bei jeder Meldung, bevor ich entscheide, wie dringend das Update ist.

#Astro: Upgrade-Befehl, Anleitungen und erweiterte Wartung

Astro nennt in der Dokumentation zum Upgrade einen Befehl, der Astro und die offiziellen Integrationen gemeinsam aktualisiert: npx @astrojs/upgrade. Hauptversionen enthalten laut Dokumentation Änderungen, die bestehenden Code betreffen, und jede ist in einer Anleitung “Upgrade to vX” mit dem Abschnitt “What should I do?” je Änderung beschrieben. Zur Support-Richtlinie steht dort, dass das Kernteam für eine vorherige Hauptversion erweiterte Wartung nur für Sicherheitskorrekturen leistet.

Wie groß ein Sprung sein kann, zeigt Astro 7. Laut npm-Registry erschien 7.0.0 am 22. Juni 2026. Die Anleitung zum Wechsel auf Astro 7 nennt unter anderem Vite 8, einen strengeren Rust-Compiler, der unsauber verschachteltes HTML nicht mehr stillschweigend korrigiert, einen neuen Standard-Prozessor für Markdown und eine geänderte Behandlung von Leerraum. Solche Änderungen gehören in einen geplanten Termin mit Vorschau und Abgleich der Seiten, nicht in ein nebenbei eingespieltes Patch-Update. Kleine Versionen innerhalb einer Hauptversion spiele ich dagegen in kurzen Abständen ein, damit sich nichts aufstaut.

#Node.js: die Laufzeit hat ihren eigenen Kalender

Beide Frameworks laufen auf Node.js, und Node.js hat einen eigenen Veröffentlichungsplan (nodejs.org, frühere Versionen). Gerade Versionen werden zu LTS-Versionen, ungerade laufen nur kurz. Die genauen Termine pflegt die Release-Arbeitsgruppe in einer Datei auf GitHub. Daraus der Stand für die relevanten Versionen:

Für Astro und Next.js zählt das doppelt. Astro 7 verlangt laut Installationsanleitung Node.js 22.23.4 oder höher und schließt ungerade Versionen wie 23 aus. Next.js nennt als Mindestversion 20.9, doch Node.js 20 steht auf nodejs.org als beendet. Praktisch ist also Node.js 22 die älteste Version, auf der ich ein neues Projekt noch aufsetzen würde, und ihr Ende am 30. April 2027 steht im Kalender der Wartung. Ab Node.js 27 stellt das Projekt auf einen jährlichen Rhythmus um, mit einem halben Jahr Alpha und einem halben Jahr Current vor der LTS-Phase (Stand November 2026, die Termine für 27 stehen in derselben Datei).

#Dependabot oder Renovate

Beide Werkzeuge öffnen Pull Requests, wenn ein Paket veraltet ist. Dependabot ist in GitHub eingebaut und wird über eine Datei dependabot.yml im Repository konfiguriert. Die GitHub-Dokumentation trennt zwei Dinge, die man leicht vermischt:

• Versionsupdates halten Abhängigkeiten aktuell, auch wenn keine Schwachstelle bekannt ist. Standardmäßig gilt eine Wartezeit von drei Tagen, bevor eine neue Version berücksichtigt wird.
• Sicherheitsupdates reagieren auf Meldungen zu bekannten Schwachstellen. Die Wartezeit gilt für sie nicht. Sie werden separat aktiviert (Dependabot-Sicherheitsupdates).

Renovate liest seine Einstellungen unter anderem aus einer renovate.json (Renovate-Dokumentation). Welches Werkzeug passt, hängt von Ihrem Repository ab: Liegt der Code bei GitHub, ist Dependabot der kürzeste Weg. Wichtiger als die Wahl ist, dass die Pull Requests nicht ungelesen liegen bleiben. Ein Werkzeug, das zwanzig offene Vorschläge sammelt, ersetzt keine Wartung, es verlagert nur das Warten. Ich sichte die Vorschläge, bündele zusammengehörige Änderungen und lasse jede Zusammenführung durch den Testlauf gehen.

#Wie oft aktualisiert wird

Ein starrer Takt für alles wäre falsch, weil die Quellen unterschiedlich schnell arbeiten. Mein Vorgehen, jeweils schriftlich vereinbart:

• Sicherheitsmeldungen: Ich lese sie, sobald sie erscheinen, und bewerte, ob Ihre Konfiguration betroffen ist. Ist sie es, plane ich das Update ein und halte die Begründung fest. Ist sie es nicht, steht auch das im Bericht.
• Framework-Patches und kleine Versionen: einmal im Monat, passend zum ungefähr monatlichen Takt der Next.js-Sicherheitsfreigaben.
• Hauptversionen von Astro oder Next.js: als eigenes Vorhaben mit Vorschau, sobald die bisherige Version in die Maintenance-Phase wechselt. Das Ende der Maintenance-Phase ist dafür die späteste Frist, nicht der Zielzeitpunkt.
• Node.js: ein Wechsel der Hauptversion rechtzeitig vor deren Ende, aus der Tabelle oben.
• Sperrdatei: Aktualisierung zusammen mit dem monatlichen Durchlauf.

#Wenn eine Schwachstelle Personendaten betrifft

Eine ungepatchte Schwachstelle kann zu einer Datenpanne führen, etwa wenn ein Formular Anfragen speichert oder ein Login-Bereich Kundendaten zeigt. Die Aufsichtsbehörde für Unternehmen in Nordrhein-Westfalen ist die Landesbeauftragte für Datenschutz und Informationsfreiheit (LDI NRW). Nach ihrer Seite zur Meldepflicht für Verantwortliche müssen Verletzungen des Schutzes personenbezogener Daten unverzüglich, möglichst binnen 72 Stunden, gemeldet werden, wenn von ihnen mehr als nur ein geringes Risiko für die Rechte und Freiheiten natürlicher Personen ausgeht. Auch ein Fall mit geringem Risiko wird intern dokumentiert. Ob gemeldet wird, liegt bei Ihnen als Verantwortlichem. Mein Teil ist, den technischen Hergang zu belegen: welche Version lief, welche Meldung vorlag, wann das Update eingespielt wurde. Das gelingt nur, wenn die Wartung ihre Schritte protokolliert.

#Was eine Wartungsvereinbarung umfasst

Ich bin ein einzelner Entwickler und arbeite ausschließlich aus der Ferne und schriftlich. Die Vereinbarung beschreibt eine Methode, keine Reaktionszeit und keine Verfügbarkeitszahl.

Nicht enthalten sind neue Funktionen, Inhalte und Gestaltung. Grafik, Mockups und Layout liefern Sie, ich setze sie um. Das Stundenkontingent einer Vereinbarung gilt je Monat und wird nicht in den nächsten übertragen. Zusätzliche Arbeit, etwa ein größerer Versionssprung, stimme ich vorher schriftlich mit Ihnen ab.

#Checkliste für Ihr Projekt

Diese Fragen taugen auch, wenn Sie die Wartung selbst oder mit einem anderen Dienstleister betreiben:

• Liegt der Code in einem Repository, und ist die Sperrdatei darin?
• Welche Hauptversion von Astro oder Next.js läuft, und steht sie auf der Support-Seite des Herstellers als unterstützt?
• Welche Node.js-Version läuft auf dem Server und im Build, und wann endet sie?
• Ist Dependabot oder Renovate eingerichtet, und liest jemand die Vorschläge?
• Gibt es einen Testlauf, der vor jeder Veröffentlichung Build, Formulare und die wichtigsten Seiten prüft?
• Wer liest die Sicherheitsmeldungen des Frameworks, und wo wird die Entscheidung dazu festgehalten?
• Kann der vorherige Stand mit einem Handgriff wiederhergestellt werden?

#So läuft der Einstieg mit mir

Sie schicken mir den Zugang zum Repository, die Angabe, wo die Website gehostet wird, und die Liste der Formulare und Dienste, die angebunden sind. Ich sichte package.json, Sperrdatei und Node.js-Version, vergleiche sie mit den Plänen der Hersteller und schicke Ihnen schriftlich eine Bestandsaufnahme: was unterstützt ist, was bald ausläuft und womit ich beginnen würde. Danach entscheiden Sie, ob Sie eine laufende Vereinbarung wollen oder einzelne Aufträge.

#Häufige Fragen

#Muss ich bei Astro oder Next.js überhaupt etwas aktualisieren, wenn die Seite läuft?

Ja, aber nicht aus Prinzip. Die Website selbst verändert sich nicht, doch die Pakete, aus denen sie gebaut wurde, können Schwachstellen enthalten, und die Hersteller beenden irgendwann den Support einer Version. Bei Next.js erscheinen laut Blog ungefähr monatlich geplante Sicherheitsfreigaben.

#Wie lange wird eine Next.js-Version unterstützt?

Eine Hauptversion ist Active LTS, bis die nächste erscheint, danach zwei Jahre nach ihrem Erscheinen Maintenance LTS. Für 15.x hat Next.js das Ende verlängert, Sicherheitsfreigaben sind bis 31. Januar 2027 angekündigt (Stand November 2026).

#Was passiert, wenn ein Update die Seite kaputt macht?

Updates entstehen auf einer Vorschau-Adresse und gehen erst nach dem Testlauf live. Der vorherige Stand liegt im Repository und lässt sich zurückspielen.

#Brauche ich Dependabot oder Renovate?

Nötig ist ein Verfahren, das veraltete Pakete sichtbar macht. Dependabot und Renovate leisten das automatisch, sie öffnen aber nur Vorschläge. Die Prüfung und Entscheidung bleibt Arbeit.

#Sind Sicherheitsupdates und normale Updates dasselbe?

Nein. Dependabot trennt Versionsupdates von Sicherheitsupdates, und für Letztere gilt keine Wartezeit. Ein Sicherheitsupdate prüfe ich vorrangig, ein Versionsupdate läuft im monatlichen Durchlauf.

#Schreiben Sie mir zur Wartung nach der Migration

Schicken Sie mir über die Kontaktseite die Adresse Ihrer Website, das eingesetzte Framework mit Version, den Hoster und die Stelle, an der der Code liegt. Wenn die Migration noch bevorsteht, beschreibt meine Seite zur Migration zu Astro und Next.js das Vorgehen, und zu den Frameworks selbst finden Sie Astro-Entwicklung in Wuppertal und Next.js-Entwicklung in Wuppertal. Ich antworte schriftlich an Werktagen und stelle Ihnen eine erste Einschätzung ohne Berechnung zusammen.