Migration zu Next.js / Astro in Berlin

#Das MVP von damals ist die Hypothek von heute

Die typische Berliner Migrationsanfrage beginnt nicht mit einem alten System, sondern mit einem jungen, das zu schnell gealtert ist. Die Website wurde in der Gründungsphase in wenigen Wochen aufgesetzt, oft 2018 oder 2019, mit einem gekauften Theme, einem Page Builder und der ausdrücklichen Ansage, dass das Ganze nur bis zur nächsten Finanzierungsrunde halten muss. Das war damals die richtige Entscheidung: Geschwindigkeit schlägt Architektur, solange unklar ist, ob das Produkt überhaupt einen Markt findet. Sieben Jahre später ist aus dem Provisorium die Hauptbühne eines Unternehmens mit fünfzig Mitarbeitenden geworden, und jede Änderung am Auftritt dauert länger, als das Feature gebraucht hat, das gerade angekündigt werden soll.

Dazu kommt eine zweite Eigenheit, die Berliner Projekte von denen in anderen deutschen Städten unterscheidet: Der Auftritt war nie einsprachig gedacht. Deutsch und Englisch laufen von Anfang an parallel, das Team arbeitet auf Englisch, die Kunden sitzen in mehreren Ländern, und die Mehrsprachigkeit wurde im alten System mit einem Plugin nachgerüstet, das inzwischen selbst zur Fehlerquelle geworden ist. Und schließlich die dritte Konstante: Agenturwechsel. Wer drei Dienstleister in fünf Jahren hatte, jeder mit eigenem Stil und keiner mit Übergabedokumentation, besitzt eine Website, die niemand mehr vollständig versteht.

Für diese Ausgangslage ist der Umstieg auf ein Frontend mit Astro oder Next.js der Weg, der die aufgebauten Werte mitnimmt: Inhalte, URLs, Rankings und die eingespielte Redaktionsroutine. Was zurückbleibt, ist die Schicht, die tatsächlich Probleme macht.

#Migration oder Relaunch: eine Frage der Substanz

Bevor über Frameworks gesprochen wird, gehört eine nüchterne Frage beantwortet: Ist das bestehende System krank oder nur unmodern? Ein Relaunch erneuert Gestaltung und Inhalte innerhalb der vorhandenen Technik. Eine Migration tauscht die technische Basis und nimmt alles Erhaltenswerte mit. Beide Wege haben ihre Berechtigung, und wer sie verwechselt, bezahlt doppelt.

Für die Migration spricht, wenn die Technik selbst der Engpass ist: ein Page Builder, der jede Seite in ein Geflecht aus Shortcodes verwandelt hat, das sich ohne ihn nicht mehr öffnen lässt. Ladezeiten, die Werbebudget verbrennen, weil jeder Klickpreis auf einer trägen Landingpage schlechter konvertiert. Ein Plugin-Stapel, bei dem niemand mehr sagen kann, welche Erweiterung wofür da ist, und bei dem jedes Update ein kleines Glücksspiel bleibt. Oder ein anstehender Rebrand mit Domainwechsel, bei dem ohnehin jede URL angefasst werden muss und die Gelegenheit günstig ist, die technische Basis gleich mitzuwechseln.

Für den Relaunch im Bestand spricht, wenn das Fundament trägt: aktuelles PHP, ein schlankes Theme, eine Plugin-Liste, die auf eine Bildschirmseite passt. Dann ist neue Gestaltung im vorhandenen System der schnellere und günstigere Weg, und wir sagen das in der Bestandsaufnahme genauso deutlich. Ein brauchbarer Selbsttest vorab: Wenn Ihr Marketing-Team eine neue Landingpage ohne Entwicklerhilfe und ohne Angstschweiß veröffentlichen kann, ist Ihr System vermutlich gesünder, als es sich anfühlt.

#Astro und Next.js ohne Lagerdenken

In Berliner Gesprächen ist die Framework-Frage oft schon vorentschieden, bevor wir am Tisch sitzen, denn viele Teams bringen React-Erfahrung mit und tendieren deshalb zu Next.js. Diese Erfahrung ist ein echtes Argument, aber sie ist nicht das einzige, und für einen Marketing-Auftritt ist sie selten das ausschlaggebende.

Die technische Trennlinie verläuft zwischen Inhalt und Anwendung. Astro erzeugt Seiten zur Build-Zeit als statisches HTML und schickt JavaScript nur dorthin, wo eine einzelne Komponente es anfordert. Für Unternehmensauftritte, Produkt-Landingpages, Blogs und Dokumentation ist das die Architektur mit dem geringsten Ballast: nichts rendert auf einem Server, nichts wartet auf Hydration, und die Angriffsfläche eines statischen Builds ist minimal. Next.js entfaltet seinen Wert dort, wo Seiten pro Nutzer anders aussehen: Dashboards, Konfiguratoren, Portale mit Login, Suchen mit komplexer Filterlogik.

Die für Berliner Teams oft entscheidende Nachricht: Das ist keine Entweder-oder-Wahl, und React-Kompetenz ist in beiden Welten nutzbar, denn Astro bettet React-Komponenten dort ein, wo Interaktivität gebraucht wird. In vielen Projekten landet der Marketing-Auftritt als Astro-Build auf der Domain und die eigentliche Anwendung als Next.js-Projekt auf einer Subdomain oder unter einem Routen-Präfix. Wir dokumentieren diese Zuordnung pro Route mit Begründung, damit sie auch nach dem nächsten Personalwechsel nachvollziehbar bleibt. Die stadtunabhängige Langfassung dieser Abwägung steht im Leitfaden zur Website-Migration mit Next.js und Astro.

#Rankings, URLs und der Sonderfall Rebrand

Organische Sichtbarkeit hängt an URLs, Inhalten und Verlinkung, nicht am Framework. Wer beim Umzug Adressen verliert, verliert Rankings, und zwar unabhängig davon, wie schnell das neue Frontend ist. Deshalb beginnt jedes Projekt mit einem vollständigen URL-Inventar aus Crawl, Search-Console-Daten und Server-Logs, und zwar getrennt für jede Sprachfassung. Die Logs sind dabei Pflicht, nicht Kür: Sie zeigen die Adressen, die kein Crawler mehr findet, über die aber weiterhin Besucher kommen, etwa aus alten Newslettern, Pitch-Decks und Partnerverlinkungen.

In Berlin kommt regelmäßig eine Verschärfung dazu, die anderswo die Ausnahme ist: der Rebrand. Das Unternehmen heißt nach der Finanzierungsrunde anders, die neue Marke braucht eine neue Domain, und nicht selten sollen dabei zwei oder drei historisch gewachsene Alt-Domains gleich mit konsolidiert werden, Überbleibsel früherer Produktnamen und Landingpage-Experimente. Damit wird aus dem einfachen Mapping eine Matrix: jede Adresse auf jeder Alt-Domain braucht ein Ziel auf der neuen, die Umzüge werden in der Search Console angemeldet, und externe Verweise mit Gewicht werden identifiziert und wo möglich direkt aktualisiert statt nur umgeleitet.

Zum Erhalt gehört auch, was man nicht sieht: strukturierte Daten, die bisher ein Plugin erzeugt hat, werden im neuen Frontend nachgebaut, das hreflang-Gerüst für Deutsch und Englisch wird exakt auf die neuen URLs gesetzt, und vor dem Produktivumschaltung läuft ein automatisierter Abgleich alt gegen neu über das komplette Inventar. Abweichungen sollen im Testsystem auffallen, nicht im Bericht des nächsten Quartals.

#Zweisprachig publizieren, während umgebaut wird

Die Redaktionsfrage entscheidet in der Praxis über die Akzeptanz des gesamten Projekts. Ein Content-Team, das mitten im Kampagnenjahr wochenlang nicht veröffentlichen darf, wird jede Migration zu Recht bekämpfen. Deshalb bauen wir das neue Frontend gegen das laufende System: WordPress bleibt als Backend aktiv, Ihre Redaktion publiziert ohne Unterbrechung auf Deutsch und Englisch, und die Inhalte fließen über die REST-API oder WPGraphQL in die Builds des neuen Frontends. Der Content-Freeze schrumpft auf die Stunden rund um den Umstellungstermin.

Dieser Aufbau beantwortet auch die Schulungsfrage: Das Werkzeug der Redaktion ändert sich nicht, nur die Auslieferung. Für zweisprachige Teams heißt das konkret, dass die eingespielten Übersetzungs- und Freigabe-Workflows weiterlaufen, während das neue Frontend die Sprachlogik sauberer abbildet als das nachgerüstete Plugin im Altsystem. Wo das Backend selbst Teil des Problems ist, etwa weil Jahre von Page-Builder-Inhalten nicht sinnvoll über eine Schnittstelle zu holen sind, extrahieren und bereinigen wir die Inhalte einmalig und bauen das Backend schlank neu auf. Das ist mehr Aufwand am Anfang und weniger Reibung in jedem Jahr danach. Wenn das WordPress-Fundament ohnehin auf der Agenda steht, greifen Migration und laufende WordPress-Entwicklung in Berlin ineinander.

#Produktivumschaltung mit Sicherheitsnetz

Berliner Unternehmen haben Kalender voller Termine, die eine Website nicht verpassen darf: Produkt-Launches, Presse-Embargos, Messeauftritte, Kampagnenstarts. Ein Migrations-Produktivumschaltung gehört in die Lücke zwischen solchen Terminen, und er gehört so gebaut, dass er sich zurückdrehen lässt. Der Wechsel passiert per DNS- oder Routing-Umstellung, das Altsystem bleibt vollständig lauffähig, und der Rückweg wird vor dem Termin tatsächlich durchgespielt, nicht nur in einem Dokument behauptet. Tritt im Live-Betrieb ein Problem auf, das sich nicht kurzfristig lösen lässt, ist der alte Zustand in Minuten wiederhergestellt und die Analyse passiert ohne Publikum.

Nach der Umstellung beginnt das Messfenster. Beobachtet werden Indexierung und Crawling in der Search Console für beide Sprachfassungen, die Rankings der wichtigsten Suchbegriffe, Core Web Vitals aus echten Nutzerdaten und die Fehlerraten der Redirect-Schicht. Bei Rebrands mit Domainwechsel setzen wir das Fenster bewusst länger an, weil Suchmaschinen einen Domainumzug langsamer verarbeiten als einen Frontend-Tausch unter gleicher Adresse. Erst wenn die Kurven stabil sind, wird das Altsystem eingefroren und archiviert. Wer nach der Migration noch an der Auslieferung drehen will, findet den nächsten Baustein in der Cloudflare-Workers-Entwicklung in Berlin: Das statische Frontend und die Redirect-Logik wandern dann an den Netzwerkrand.

#DSGVO und die Due-Diligence-Frage

Datenschutz ist bei einer Migration kein nachgelagertes Kapitel, sondern Teil der Architekturentscheidung, und in Berlin kommt die Frage aus zwei Richtungen zugleich: von der Aufsicht, die zu den strengsten des Landes zählt, und von Investoren, deren Due-Diligence-Checklisten inzwischen Datenflüsse und Auftragsverarbeitung abfragen. Eine Migration ist der beste Zeitpunkt, beides in Ordnung zu bringen, denn ohnehin wird jede Komponente angefasst.

Konkret klären wir drei Dinge. Erstens die Datengeographie: Wo laufen Builds, wo liegt die Auslieferung, und wie wird die Verarbeitung personenbezogener Daten auf EU-Standorte begrenzt. Zweitens das Inventar der Drittdienste: In gewachsenen Installationen stecken regelmäßig Einbettungen und Tracking-Schnipsel aus früheren Agenturphasen, die niemand mehr nutzt, die aber weiter Daten laden. Der Umzug ist der Moment, an dem diese Altlasten nicht mitgenommen werden. Drittens die Dokumentation: Nach der Migration übergeben wir die Datenflüsse so aufbereitet, dass Ihre Datenschutzbeauftragte das Verarbeitungsverzeichnis aktualisieren kann, ohne die neue Architektur selbst auseinandernehmen zu müssen.

Ein Nebeneffekt mit Gewicht: Ein statisch ausgeliefertes Frontend ohne öffentlich erreichbares CMS reduziert die Angriffsfläche drastisch. Für ein Unternehmen, das im nächsten Finanzierungsprozess nach Sicherheitsvorfällen gefragt wird, ist das ein Punkt auf der richtigen Seite der Tabelle.

#Drei Muster aus Berliner Projekten

Die Details sind verfremdet, die Muster nicht: Jedes davon ist uns in Berlin mehr als einmal begegnet.

Das Scale-up vor der Series B: Ein Software-Anbieter hatte seinen Auftritt 2019 als schnelles WordPress-MVP aufgesetzt, zweisprachig per Plugin, gepflegt von wechselnden Werkstudierenden. Vor der Finanzierungsrunde sollte der Auftritt das Unternehmen tragen, das man geworden war, nicht das von 2019. Der Weg: Inhalte und URL-Historie blieben, das Frontend wurde als Astro-Build mit sauberem hreflang-Gerüst neu aufgesetzt, WordPress blieb als Backend für das Content-Team. Die Marketing-Seiten wurden messbar schneller, und die englische Fassung, vorher ein Anhängsel, wurde zur gleichwertigen Ausspielung für die internationalen Zielmärkte.

Der Rebrand mit drei Alt-Domains: Nach einer Umbenennung sollten die neue Marken-Domain und drei historisch gewachsene Alt-Domains zu einem Auftritt zusammenfließen. Das URL-Inventar über alle vier Domains war der eigentliche Projektkern: jede Adresse bekam ein Ziel, die Umzüge wurden in der Search Console angemeldet, und die wichtigsten externen Verweise wurden bei den Quellen direkt aktualisiert. Das Frontend, ein Astro-Build mit Next.js-Anwendung unter einem Routen-Präfix, war planmäßig der kleinere Teil. Die Sichtbarkeit zog nach der erwartbaren Schwankungsphase auf der neuen Domain wieder an, ohne dass eine der Alt-Domains Traffic ins Leere verlor.

Das System nach drei Agenturwechseln: Ein Mittelständler mit digitalem Geschäftsmodell hatte in fünf Jahren drei Agenturen verschlissen, jede hatte Plugins, Custom Fields und Weiterleitungen hinterlassen, dokumentiert war nichts. Vor der Migration stand eine Rekonstruktion: Inventar aller Anpassungen, Workshops mit den Fachbereichen zur Frage, was davon tatsächlich gebraucht wird, dann erst die Umstellung. Gut die Hälfte der gefundenen Funktionen war tot und entfiel ersatzlos. Migriert wurde am Ende ein deutlich kleineres System als das, das auf dem Server lag, und genau darin lag der Gewinn.

#Wann wir von einer Migration abraten

Es gibt Anfragen, bei denen die ehrliche Antwort nein lautet. Wenn die Unzufriedenheit beim Inhalt liegt, bei veralteten Texten, fehlender Positionierung oder einem Blog, der seit zwei Jahren schweigt, dann liefert ein neues Framework dieselben Schwächen nur schneller aus. Wenn das WordPress gesund ist und nur das Design alt aussieht, ist der Relaunch im Bestand der wirtschaftlichere Weg. Wenn in den nächsten Wochen ein Launch, eine Messe oder eine Kampagne ansteht, ist der Zeitpunkt falsch, denn eine Migration ohne ruhiges Messfenster holt sich ihre Abkürzungen später zurück. Und wenn niemand im Haus das neue System verantworten wird und auch kein Betriebspartner vorgesehen ist, entsteht nur die nächste undokumentierte Altlast, die in drei Jahren der nächste Dienstleister rekonstruieren darf.

Auch für Shops gilt ein eigener Maßstab: Ein laufender WooCommerce-Checkout wird nicht nebenbei mitmigriert. Ob der Shop im Bestand optimiert oder in Etappen umgezogen wird, klären wir gemeinsam mit der WooCommerce-Entwicklung in Berlin, bevor eine Frontend-Entscheidung fällt. Diese Abgrenzungen stehen am Anfang der Bestandsaufnahme, nicht am Ende des Angebots.

#Zusammenarbeit auf Augenhöhe mit Ihrem Team

Wir arbeiten mit Berliner Unternehmen remote-first, auf Deutsch oder Englisch, je nachdem, wie Ihr Team aufgestellt ist, und liefern Code, Pull-Request-Beschreibungen und Dokumentation auf Wunsch durchgängig auf Englisch. Das Projekt läuft in Etappen mit einzeln abnehmbaren Ergebnissen: Bestandsaufnahme mit Rekonstruktion und Empfehlung, Zielarchitektur pro Route, Parallelaufbau mit vollständigem Mapping, Produktivumschaltung mit geprobtem Rückweg, Messfenster mit Bericht. Nach jeder Etappe entscheiden Sie, ob es weitergeht, und die Preisgestaltung ist individuell pro Etappe statt als Pauschale über ein Projekt mit unbekannten Variablen.

Am Ende steht die Übergabe: dokumentierte Architektur, versionierte Redirect-Schicht, nachvollziehbare Build-Prozesse und eine Einweisung, mit der Ihr Team oder Ihr nächster Entwickler ohne Archäologie weiterarbeiten kann. Das ist das eigentliche Projektziel, gerade in einer Stadt, in der Dienstleisterwechsel zur Biografie vieler Websites gehören: ein System, das den nächsten Wechsel nicht fürchten muss. Der Einstieg ist unverbindlich: eine Bestandsaufnahme mit einer Empfehlung, hinter der wir auch dann stehen, wenn sie gegen die Migration ausfällt. Dann wissen Sie es früh, bevor ein Projekt Budget bindet, das an anderer Stelle gebraucht wird.

Zuletzt aktualisiert: 10. Juli 2026