Astro Upgrade: von Astro 5 oder 6 auf die aktuelle Major-Linie.

Im Wurzelverzeichnis Ihres Repositories liegt eine package.json. Unter den Abhängigkeiten steht ein Eintrag astro; dessen erste Zahl ist die Major-Version. Zur Gegenprobe zeigt die Lock-Datei Ihres Paketmanagers, was zuletzt tatsächlich installiert wurde. Wenn niemand im Haus an das Repository kommt, ist das der eigentliche Befund – und wichtiger als die Zahl selbst, denn ohne Zugriff lässt sich auch kein Sicherheits-Fix einspielen. Schicken Sie uns in dem Fall die URL, wir sehen für Sie nach.

Weil „läuft" und „wird gepflegt" zwei verschiedene Dinge sind. Astro folgt Semantic Versioning und liefert laut Upgrade-Dokumentation Security-Fixes für genau eine vorherige Major-Version. Aktuell ist die Astro-7-Linie; Astro 5 und älter liegt damit außerhalb. Dazu kommt der praktische Teil: Wenn Sie in einem Jahr etwas ändern wollen, ist der Sprung dann größer als heute. Wenn Ihre Seite allerdings klein, statisch und ohnehin bald abgelöst ist, sagen wir Ihnen offen, dass Sie das Geld sparen sollten.

Manchmal ja, und wir rechnen das gegeneinander, statt es zu behaupten. Für den Vergleich zählen vier Dinge: wie viele Integrationen noch gepflegt werden, wie tief eigener Code an Framework-Interna hängt, ob der Build heute reproduzierbar durchläuft und wie groß das Route-Inventar ist. Zwei Sprünge auf einem gepflegten Projekt sind meist deutlich günstiger als ein Neubau. Drei Sprünge auf einer Codebasis mit verwaisten Integrationen kippen die Rechnung regelmäßig – dann empfehlen wir den Neubau.

In der Regel nicht. Das Upgrade läuft in einem eigenen Branch; Ihre Website bleibt bis zum Umschalten unverändert online, und Inhalte, Korrekturen und neue Landingpages gehen weiter über den normalen Weg live. Der Upgrade-Branch wird in kurzen Abständen nachgezogen. Eine Einschränkung nennen wir ehrlich: Wenn Ihr Team im selben Zeitraum das Inhaltsmodell umbauen oder neue Seitentypen einführen will, verabreden wir eine Reihenfolge. Das kostet Tage, keine Quartale.

Jeder Schritt liegt als Commit vor, und das Umschalten läuft über die reguläre Deployment-Pipeline. Der Rückweg ist ein Revert plus ein Deployment des vorherigen Stands – ein Handgriff. Wichtiger ist aber, dass es meistens gar nicht so weit kommt: Die Vorschau-Umgebung zeigt den neuen Stand vollständig, bevor irgendetwas umgeschaltet wird, und Sie klicken sie selbst durch. Der Rollback-Weg steht schriftlich fest, bevor jemand die Produktionsumgebung anfasst.

Nicht durch Anschauen. Vor dem Upgrade entsteht ein Route-Inventar aus Sitemap, Build-Ausgabe und Analytics – inklusive dynamischer Routen, Paginierung, Feeds und Sprachvarianten. Danach werden beide Stände gebaut und verglichen: Ist jede Route vorhanden, stimmen Titel, Meta-Angaben, kanonische URLs und strukturierte Daten, verhalten sich Bilder und Islands wie vorher? Weil statisches HTML die Standardauslieferung ist, ist das ein Vergleich zweier Build-Ergebnisse und keine Geschmacksfrage.

Ja – nach einem Audit. Wir sehen uns Repository, Astro-Version, Rendering-Modus, Adapter, Content Collections, Integrationen und Build an und geben einen schriftlichen Befund ab. Der kann drei Ergebnisse haben: upgraden wie es ist, erst stabilisieren und dann upgraden, oder neu bauen. Wenn wir den Code nicht verantworten können, sagen wir ab. Der Ablauf dafür steht unter Astro Support und Wartung.

On-Demand-Rendering braucht in Astro einen Adapter für die Ziel-Laufzeit; offiziell gepflegt sind unter anderem Node, Vercel und Cloudflare. Beim Major-Sprung wird der Adapter gemeinsam mit dem Framework gehoben, und die Laufzeitumgebung wird auf der Zielplattform getestet, nicht nur lokal – genau dort tauchen Unterschiede auf, die im Entwicklungsmodus unsichtbar bleiben. Dazu gehören Umgebungsvariablen, Caching-Regeln und Weiterleitungen. Rein statisch ausgelieferte Projekte sind an dieser Stelle deutlich unkomplizierter.

Astro ist UI-Framework-agnostisch, und mehrere Frameworks dürfen auf einer Seite koexistieren. Beim Upgrade ist die relevante Frage nicht das Nebeneinander, sondern ob jede einzelne Integration die Ziel-Major unterstützt. Deshalb steht diese Prüfung ganz vorn: Wenn eine Integration nicht mitkommt, blockiert sie sonst das gesamte Upgrade. Dann gibt es drei Wege – ersetzen, die Insel neu bauen oder die Pflege selbst übernehmen. Diese Entscheidung treffen wir mit Ihnen vor dem Sprung, nicht mittendrin.

Für den Redaktionsalltag ändert sich normalerweise nichts – das CMS bleibt das CMS. Technisch wird aber das SDK Ihres Systems mitgezogen, und die Abfragen, mit denen Astro Inhalte holt, werden gegen den neuen Stand geprüft. Solange der Upgrade-Branch offen ist, veröffentlicht Ihre Redaktion wie gewohnt weiter. Wir empfehlen lediglich, in dieser Zeit keine Feldstrukturen im CMS umzubauen, weil sich das mit dem Upgrade überschneiden würde.

Eine Zahl ohne Befund wäre geraten, deshalb steht hier keine. Der Aufwand hängt an sechs Dingen: der Anzahl übersprungener Major-Versionen, der Zahl und dem Pflegezustand Ihrer UI-Integrationen, der Frage, ob Routen on demand rendern und damit ein Adapter dazugehört, der Größe des Route-Inventars als Prüffläche, der Tiefe des Content-Modells und dem Zustand Ihrer Pipeline. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit offengelegten Annahmen. Zur Einordnung: Astro-Kosten.

Als Planungsspanne: Ein gepflegtes, rein statisches Projekt mit wenigen Integrationen und genau einem Major Rückstand liegt im Bereich weniger Tage. Zwei Majors Rückstand mit mehreren Integrationen, CMS-Anbindung und on-demand gerenderten Routen eher bei zwei bis vier Wochen. Drei oder mehr Majors mit verwaisten Integrationen und einem Build, der heute nicht durchläuft: vier bis acht Wochen – und dort gehört die Neubau-Frage auf den Tisch. Das sind Erfahrungswerte für die Planung, keine Zusage.

Ein Major-Upgrade ist keine Migration: URLs, Inhalte und Struktur bleiben, es wechselt der Unterbau. Trotzdem prüfen wir genau die Stellen, an denen eine geänderte Voreinstellung leise etwas verschieben kann – Titel, Meta-Angaben, kanonische URLs, hreflang, strukturierte Daten, Sitemap und Weiterleitungen, jeweils im Abgleich zwischen altem und neuem Build. Danach behalten wir die Search Console und die Felddaten in den ersten Wochen im Blick. Absolute Zusagen geben wir dazu nicht; wir zeigen, was wir prüfen.

Ja, das ist ein sinnvolles Format, wenn Sie ein eigenes Team haben. Üblich ist eine Kombination: Wir liefern den Versionsbefund, das Route-Inventar und die Prüfliste, Ihr Team führt den Sprung durch, und wir gehen den Pull Request und den Build-Vergleich durch. Häufig übernehmen wir zusätzlich die Stellen, an denen es hakt – Adapter, Content-Modell oder eine Integration, die nicht mitkommt. Das ist meist die günstigste Variante für Teams, die Astro danach selbst weiterführen wollen.

Indem Upgrades aufhören, ein Projekt zu sein. Praktisch heißt das: kleine Updates laufend, ein festes Fenster pro Major-Zyklus, ein Build, der in der Pipeline reproduzierbar durchläuft, und eine Person, die verantwortlich ist. Bei einem Takt von zwei Major-Versionen innerhalb eines Jahres reicht ein jährlicher Termin nicht mehr zuverlässig aus. Genau dafür gibt es die laufende Betreuung – und für kleine statische Seiten sagen wir offen, dass ein geplantes Update-Fenster genügt.

Ein schneller Major-Takt ist nicht dasselbe wie Instabilität. Astro folgt Semantic Versioning: Breaking Changes landen ausdrücklich in Major-Versionen und werden mit Upgrade-Hinweisen veröffentlicht, statt unangekündigt in einem Minor aufzutauchen. Das macht Planung möglich, verlangt aber auch, dass geplant wird. Wer keinen Prozess für Major-Sprünge hat, empfindet den Takt als Belastung; wer einen hat, bekommt vorhersehbare, dokumentierte Änderungsfenster. Die Grundlagen dazu stehen unter Was ist Astro?.

Die aktuelle Major-Linie ist Astro 7. Astro 7.0 erschien am 22. Juni 2026, Astro 7.2 am 6. August 2026. Die davor liegende Linie, Astro 6.0, wurde am 10. März 2026 stabil. Eine tagesaktuelle Patch-Version nennen wir hier bewusst nicht, weil sie sich laufend ändert.

Astro folgt Semantic Versioning und bietet laut Upgrade-Dokumentation Extended Maintenance – ausschließlich Security-Fixes – für genau eine vorherige Major-Version. Bei aktueller Astro-7-Linie heißt das: Astro 6 bekommt noch Sicherheits-Fixes, Astro 5 und älter nicht mehr.

Technisch ja, wirtschaftlich selten sinnvoll. Jede Major hat eigene Breaking Changes und einen eigenen Upgrade-Pfad. Wir springen deshalb Major für Major und lassen das Projekt zwischen den Schritten jeweils bauen – so bleibt zuordenbar, welcher Sprung welche Änderung ausgelöst hat.

Astro selbst steht unter MIT-Lizenz, es fallen also keine Lizenzkosten an. Bezahlt wird die Arbeit: Befund, Sprung, Anpassungen an Integrationen und Adapter, Regressionsprüfung und Umschalten. Bei einem gepflegten Projekt mit einem Major Rückstand ist das ein überschaubarer Posten.

Im Normalfall nicht. Der neue Stand wird gebaut und in einer Vorschau-Umgebung geprüft, das Umschalten läuft über die reguläre Deployment-Pipeline. Ausfallzeit entsteht dabei nicht durch das Upgrade selbst, sondern höchstens durch parallele Eingriffe an Hosting, Laufzeit oder DNS – die planen wir getrennt.