Next.js zu Astro migrieren – wenn Ihr Projekt eigentlich Content ist.

Ja – das ist der wichtigste technische Punkt dieser Migration. Astro ist UI-Framework-agnostisch und hat eine offizielle React-Integration, neben Preact, Svelte, Vue, SolidJS und Alpine.js. Eine bestehende Komponente wird importiert und über eine client:*-Direktive als Insel montiert. Komponenten mehrerer Frameworks lassen sich kombinieren, aber nur innerhalb einer .astro-Datei. Ihre Komponentenbibliothek wird also nicht weggeworfen, sondern selektiver eingesetzt.

Die Konzepte werden nicht portiert, sondern ersetzt. In Astro ist Server-Rendering die Voreinstellung, nicht eine Komponenten-Eigenschaft: Standardmäßig wird die gesamte Seite vorgerendert und als HTML ausgeliefert. Dynamik entsteht dort, wo Sie sie anfordern – über export const prerender = false plus Adapter für die Route oder über Server Islands mit server:defer für einzelne Bereiche. Wer tief in App-Router-Komposition investiert hat, sollte diesen Aufwand vor der Entscheidung ehrlich beziffern.

Meistens ja. Der Pages Router liegt näher an einem klassischen Seitenmodell: eine Datei, eine Route, ein Datenaufruf pro Seite. Genau das bildet Astro direkt ab – dateibasiertes Routing, Daten beim Build oder beim serverseitigen Rendern der Route. Aufwendiger wird es dort, wo verschachtelte Layouts mit eigenen Ladezuständen und Server-Component-Komposition tief verzahnt sind. Wir zählen diese Stellen in Schritt eins, bevor irgendjemand eine Zahl nennt.

Middleware-Muster sind eine Eigenschaft von Next.js, kein allgemeines Web-Konzept – deshalb gibt es keinen Port, sondern eine Sortierung nach Zweck. Weiterleitungen und Rewrites gehören ohnehin in die 301-Liste oder in Ihre Hosting- und CDN-Schicht. Personalisierung lässt sich als Server Island über server:defer lösen, das unabhängig serverseitig rendert, ohne das erste Rendering zu blockieren. Zugriffsschutz für echte Benutzerkonten ist dagegen ein Anwendungsthema – und ein Argument dafür, diesen Teil in Next.js zu lassen.

Kein Eins-zu-eins-Gegenstück, und das sagen wir lieber vorher als hinterher. ISR-Semantik ist Next-spezifisch. In Astro führen drei Wege zum selben Ziel: vorgerendertes HTML, das bei Inhaltsänderung neu gebaut und deployt wird; einzelne Routen mit export const prerender = false plus Adapter, die bei jedem Aufruf serverseitig rendern; und Server Islands über server:defer, bei denen Shell und Hauptinhalt aggressiv gecacht werden, während personalisierte Elemente nachladen. Wer feingranular über tausende Routen revalidiert, migriert nicht – der entwirft neu.

Erst wird sortiert, dann portiert. Endpunkte, die zur Website gehören – Formularannahme, Webhook, Suchindex, Newsletter-Anmeldung –, laufen nach demselben Muster wie jede dynamische Route: export const prerender = false und der Adapter für Ihre Ziel-Laufzeit. Endpunkte, die fachlich zur Anwendung gehören, bleiben besser dort, wo die Anwendung ist, oder werden ein eigener Dienst. Sie mitzunehmen, nur weil sie im selben Repository lagen, ist die häufigste vermeidbare Fehlentscheidung bei diesem Wechsel.

Die Aufrufe werden ersetzt, die Bilddateien nicht. Astro bringt eine eingebaute Bildoptimierung mit: Die Image-Komponente setzt alt, loading und decoding und leitet die Bildmaße ab, damit kein Cumulative Layout Shift entsteht; die Picture-Komponente erzeugt mehrere Formate und Größen mit Fallback. Sharp ist der Default-Image-Service. Zwei Punkte kosten Zeit: Remote-Bilder müssen in der Konfiguration freigegeben werden, und Bilder aus public/ umgehen die Verarbeitung komplett – Letzteres ist beim Umzug oft ein stiller Qualitätsverlust, wenn niemand hinsieht.

Jede Sprachfassung ist eine eigene Route mit eigenem URL-Präfix, und genau dort liegt die Migrationsarbeit: URL-Mapping pro Sprache, hreflang-Paare, Canonicals. Die Inhalte modellieren wir pro Sprache in Content Collections; das Zod-Schema validiert jede Fassung einzeln und meldet fehlende Übersetzungen im Build statt auf der Live-Seite. Ehrlich zum Aufwand: Jede weitere Sprache ist nach der Zahl der Templates der zweitgrößte Terminschieber. Diese Website hier läuft selbst zweisprachig – wir kennen die Stolperstellen aus dem eigenen Betrieb.

Ja. Eine Astro-Site ist ein eigenes Paket mit eigenem Build; ob es im bestehenden Monorepo neben der Anwendung liegt oder in einem separaten Repository, ist eine Organisations- und keine Framework-Entscheidung. Gemeinsam genutzte React-Komponenten lassen sich als Workspace-Paket importieren, weil Astro React offiziell einbindet. Der ehrliche Haken: Komponenten, die Next-spezifische Importe voraussetzen, müssen an diesen Stellen umgeschrieben werden. Wie viele das sind, steht nach der Bestandsaufnahme fest – nicht vorher.

Nein. Statisch ist bei Astro der Standard, und vorgerendertes HTML läuft praktisch überall. Für On-Demand-Rendering gibt es offizielle Adapter im @astrojs-Scope für Node, Vercel und Cloudflare – Sie können also bleiben, in eine eigene Node-Umgebung wechseln oder zu Cloudflare gehen. Wir entscheiden das nach Ihrer Betriebsrealität, nicht nach Geschmack: Wer heute ein funktionierendes Deployment mit Preview-Umgebungen und einer eingespielten Pipeline hat, sollte es nicht nebenbei mitmigrieren.

Das hängt davon ab, wie viel Client-JavaScript Ihre Seiten heute wirklich brauchen. Der strukturelle Unterschied ist eindeutig: Astro entfernt standardmäßig sämtliches Client-seitige JavaScript aus Komponenten, während Hydration im React-Modell der Normalfall ist. Zahlen nennen wir trotzdem erst, wenn wir gemessen haben. Wir erheben Ihre Core Web Vitals vor und nach dem Wechsel mit Ihren eigenen Feld-Daten – fremde Benchmarks sagen über Ihr Projekt nichts aus.

Nicht, wenn der Umzug geplant wird. Wir ziehen vor Beginn alle indexierten URLs, halten die URL-Struktur nach Möglichkeit identisch und schreiben für jede Abweichung eine 301-Weiterleitung, bevor migriert wird. Titel, Überschriftenstruktur und strukturierte Daten der tragenden Seiten bleiben stabil, die Weiterleitungen werden vor dem Go-live getestet. Nach dem Launch beobachten wir Indexierung und Positionen mehrere Wochen und korrigieren nach. Eine Garantie gibt es nicht, und wer sie ausspricht, kann sie nicht halten.

Den Rahmen bestimmen drei Größen, und die Seitenanzahl gehört nicht dazu: die Zahl unterschiedlicher Seitentypen, die Tiefe des Content-Modells und die Zahl der Next-spezifischen Bausteine, an denen etwas hängt. Als Erfahrungswert: eine Docs- oder Marketing-Site mit wenigen Layouts, einer Sprache und ohne CMS liegt bei 4 bis 7 Wochen, ein gewachsener Auftritt mit CMS, zwei Sprachen und mehreren dynamischen Routen bei 8 bis 14 Wochen. Größeres schneiden wir in Phasen. Alle Variablen stehen unter Zeitrahmen.

Ihre alte Seite bleibt online, bis die neue abgenommen ist – gebaut wird parallel auf Staging. Die Umstellung selbst ist ein Wechsel des Ziels mit fertig getesteten Weiterleitungen, geplant in eine verkehrsarme Stunde. Eine Zusage über null Sekunden geben wir nicht, weil DNS- und Cache-Verhalten nicht in unserer Hand liegen. Zur Menge: Content Collections bringen ein eingebautes Caching für tausende Einträge mit. 4.000 Beiträge sind damit eine Build-Frage. Aufwendig wird es erst, wenn diese 4.000 Beiträge zwölf verschiedene Layouts benutzen.

Ja, und das ist oft der vernünftigere Weg. Der übliche Zuschnitt: Die Anwendung bleibt in Next.js, während Marketing-Site, Blog und Dokumentation nach Astro ziehen. Zwei Deployments unter einer gemeinsamen Domain, aufgeteilt über Routing-Regeln oder Subdomains. Das Produktteam behält seinen Stack, das Marketing bekommt eine Seite, die es ohne Entwicklung pflegen kann. Innerhalb eines Projekts migrieren wir andernfalls seitentypweise, beginnend bei den Routen ohne Interaktivität.

Der Einwand ist berechtigt, trifft aber weniger hart, als er klingt. Der Großteil Ihres Codes bleibt React – dafür stellen Sie ein wie bisher. Eine .astro-Datei ist im Kern HTML mit einem Skriptteil davor; wer React kann, ist nach unserer Erfahrung in wenigen Tagen produktiv. TypeScript ist eingebaut, mit drei tsconfig-Presets und astro check für die Typprüfung. Ehrlich bleibt trotzdem: Eine Stellenanzeige mit „Next.js“ bekommt mehr Bewerbungen als eine mit „Astro“. Deshalb schreiben wir die README so, dass sie ohne uns verständlich ist.

Sie können, und dafür ist gesorgt, bevor es nötig wird. Das Repository gehört Ihnen, mit vollständiger Historie; die Zugänge laufen auf Ihren Namen, der Build ist in einer README erklärt. Astro ist freie Open-Source-Software unter MIT-Lizenz – es gibt keine Lizenz, die bei einem Anbieterwechsel erlischt. Zu den Upgrades: Astro folgt Semantic Versioning, aktuelle Major-Linie ist Astro 7, und Extended Maintenance mit Security-Fixes gibt es für genau eine vorherige Major-Version. Ein planbarer Rhythmus – aber keiner, den man drei Jahre ignorieren kann.

Für das, was wir gebaut haben, wir. Vor dem Go-live steht eine Abnahme mit Mängelliste; Fehler in unserer Umsetzung beheben wir danach im vertraglich vereinbarten Gewährleistungszeitraum ohne zusätzliche Rechnung. Nicht dazu gehören inhaltliche Fehler, Ausfälle von Drittdiensten und Änderungen, die Ihr Team selbst einspielt. Weil jede Änderung ein Commit ist, lässt sich im Zweifel nachvollziehen, was wann passiert ist – und zurückrollen. Für den laufenden Betrieb gibt es Support und Wartung als eigene Vereinbarung.

Ja. Inhalte liegen dann in Content Collections mit Zod-Schema oder in einem angebundenen Headless CMS – Astro ist CMS-agnostisch und arbeitet als reine Präsentationsschicht. Ohne CMS bearbeitet Ihr Team Markdown direkt im Repository, das Schema meldet fehlende Felder vor dem Deploy. Zusätzlich richten wir auf Wunsch die Pflege per Chat ein: Text ändern, Beitrag anlegen, Bild tauschen als Nachricht an einen Telegram-Bot, jede Änderung als nachvollziehbarer Commit. Neue Seitentypen und Layouts bleiben Entwicklungsarbeit.

Wenn Ihr Produkt eine Anwendung ist. Wenn geteilter Client-State über Routen hinweg zum Produktversprechen gehört. Wenn große Teile der Oberfläche echt interaktiv sind statt dekorativ interaktiv. Und wenn es schlicht läuft, gemessen schnell genug ist und niemand Schmerzen hat – das letzte Kriterium wird am häufigsten unterschätzt. Eine Migration kostet Zeit, Aufmerksamkeit und Risiko; sie muss etwas zurückgeben, das über „moderner“ hinausgeht. Sehen wir das in Ihrem Fall nicht, steht es so in der Empfehlung.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz; für das Framework selbst fällt keine Lizenzgebühr an. Kosten entstehen durch Entwicklung, Hosting und die Dienste, die Sie anbinden – also durch das Projekt, nicht durch das Werkzeug.

Astro ist ein quelloffenes Projekt, das öffentlich im withastro-Repository auf GitHub entwickelt wird. Der Lizenztext steht unter MIT, das Copyright darin liegt bei Fred K. Schott. Es gibt kein Abonnement und keinen Anbieter, der Ihnen den Zugang abschalten könnte.

Standardmäßig nicht: Die gesamte Seite wird vorgerendert, an den Browser gehen statische HTML-Seiten. Eine Laufzeit brauchen Sie erst für Rendering auf Anfrage – dann kommt ein Adapter dazu, offiziell für Node, Vercel oder Cloudflare.

Die Voraussetzungen stimmen: Server-Rendering als Standard, statisches HTML in der Auslieferung, eine Bildkomponente, die Maße ableitet und damit Layout-Verschiebungen vermeidet. Den Ausschlag geben trotzdem URL-Kontinuität, Inhalt und interne Verlinkung – nicht das Framework.