Migration zu Next.js / Astro in Hamburg

#Warum Migrationsprojekte in Hamburg anders aussehen

Wer in Hamburg über Website-Migration spricht, spricht selten über grüne Wiese. Die Stadt trägt zwei digitale Erbschaften mit sich, die anderswo in Deutschland seltener zusammenkommen. Die erste ist TYPO3: Als Medien- und Agenturstadt hat Hamburg in den Nullerjahren überdurchschnittlich viele Verlags- und Unternehmensauftritte auf TYPO3 aufgebaut, oft von Agenturen, die es heute nicht mehr gibt. Diese Installationen laufen noch, aber die Extension-Landschaft ist eingefroren, die PHP-Version am Ende ihres Supports und der letzte Entwickler, der die Templates verstand, hat das Haus vor Jahren verlassen. Die zweite Erbschaft ist der Handel: gewachsene WooCommerce-Shops, die 2014 klein anfingen und heute unter Plugin-Schichten ächzen, daneben Magento-1-Installationen, deren offizieller Support schon im Juni 2020 endete und die seither auf geliehener Zeit laufen.

Dazu kommt der Mittelstand mit WordPress-Installationen, die ein Jahrzehnt auf dem Buckel haben: Theme vom damaligen Freelancer, dreißig Plugins, von denen die Hälfte keine Updates mehr bekommt, und eine Ladezeit, die jede Werbekampagne teurer macht als nötig. Für alle drei Ausgangslagen ist die Migration zu einem modernen Frontend mit Astro oder Next.js ein realistischer Ausweg, aber nur, wenn sie als das behandelt wird, was sie ist: ein Umzug mit Inventar, nicht ein Neuanfang mit Abrissbirne. Genau so führen wir Migrationsprojekte für Hamburger Unternehmen durch.

#Wann Migration statt Relaunch die richtige Entscheidung ist

Die Begriffe werden gern vermischt, dabei bezeichnen sie verschiedene Dinge. Ein Relaunch erneuert Design und Inhalte innerhalb des bestehenden Systems. Eine Migration wechselt die technische Basis und nimmt Inhalte, URLs und Suchmaschinen-Sichtbarkeit mit. Die Entscheidung zwischen beiden ist keine Geschmacksfrage, sondern eine Rechnung.

Für eine Migration spricht, wenn das Altsystem selbst das Problem ist: TYPO3-Versionen, deren Upgrade-Pfad teurer wäre als ein Neuaufbau des Frontends. WordPress-Themes, in denen jede Änderung Nebenwirkungen an unerwarteten Stellen auslöst. Shops, deren Seitenladezeiten trotz Caching-Plugins nicht unter die Schwelle kommen, ab der Google und Kunden geduldig bleiben. Sicherheitslagen, in denen ein öffentlich erreichbares CMS mit veralteten Erweiterungen ein Risiko darstellt, das kein Wartungsvertrag mehr wegpflegt.

Für einen Relaunch im Bestand spricht dagegen, wenn das System gesund ist und nur der Auftritt veraltet wirkt. Ein gepflegtes WordPress mit aktuellem PHP, schlankem Theme und aufgeräumter Plugin-Liste braucht keine neue Architektur, sondern gute Gestaltung. Wir prüfen das im Audit ohne Vorfestlegung, denn wir verdienen an beiden Wegen, aber nur einer davon ist für Ihren Fall der richtige.

Ein ehrlicher Indikator aus der Praxis: Wenn Ihre Redaktion das CMS mag und nur die Besucher unter der Website leiden, ist die Trennung von Backend und Frontend die eleganteste Lösung. Das CMS bleibt, das Frontend wird ersetzt. Wenn dagegen auch die Redaktion täglich gegen das System kämpft, gehört die Backend-Frage mit auf den Tisch.

#Astro oder Next.js: die Entscheidung fällt pro Route

Die Frameworkfrage wird oft wie eine Glaubensfrage behandelt. In Projekten ist sie eine Tabelle mit Seitentypen. Astro rendert Seiten zur Build-Zeit als statisches HTML und liefert JavaScript nur dort aus, wo eine Komponente es ausdrücklich anfordert. Für Inhaltsseiten, also Unternehmensauftritte, Magazine, Dokumentationen und Landingpages, ist das die effizienteste Architektur, die derzeit verfügbar ist: schnelle Auslieferung, kein Server im Anfragepfad, minimale Angriffsfläche. Next.js spielt seine Stärken aus, sobald Seiten pro Nutzer unterschiedlich aussehen müssen: Kundenportale, konfigurierbare Produkte, Suchen mit komplexen Filtern, personalisierte Inhalte.

Die ehrliche Antwort für die meisten Hamburger Mittelständler lautet deshalb: beides, aber an verschiedenen Stellen. Der Marketing-Auftritt und das Magazin laufen als Astro-Build, das Händlerportal als Next.js-Anwendung, beide hinter derselben Domain, sauber per Routing getrennt. Wer pauschal alles in Next.js baut, bezahlt für Inhaltsseiten eine Serverinfrastruktur, die statisches HTML nicht braucht. Wer pauschal alles in Astro presst, verbiegt interaktive Anwendungen in ein Modell, das dafür nicht gedacht ist.

Ein zweiter Punkt wird oft übersehen: die Frage, wer nach der Migration am System arbeitet. Astro-Projekte mit Markdown- oder CMS-Anbindung sind für kleinere Teams gut wartbar. Next.js-Anwendungen setzen React-Erfahrung voraus, die im Team vorhanden sein oder eingekauft werden muss. Wir dokumentieren die Entscheidung pro Route mit Begründung, damit sie in zwei Jahren nachvollziehbar bleibt, auch wenn die Beteiligten wechseln. Eine ausführliche, stadtunabhängige Gegenüberstellung finden Sie in unserem Leitfaden zur Website-Migration mit Next.js und Astro.

#URL-Erhalt: das Kapitel, an dem Migrationen scheitern

Wenn eine Migration organischen Traffic kostet, liegt es fast nie am neuen Framework und fast immer an verlorenen URLs. Deshalb beginnt bei uns jedes Projekt mit einem vollständigen URL-Inventar aus drei Quellen: einem Crawl des Altsystems, den Leistungsdaten der Search Console und den Server-Logs der letzten Monate. Die Logs sind dabei die unterschätzte Quelle, denn sie zeigen auch die Adressen, die kein Crawler mehr findet, aber Besucher noch aufrufen: alte Newsletter-Links, Lesezeichen, Verweise aus Foren und PDF-Dokumenten.

Jede Adresse aus diesem Inventar bekommt eine Entscheidung: Sie lebt unter gleicher URL weiter, sie wird per 301 auf einen Nachfolger umgeleitet, oder sie wird bewusst mit korrektem Statuscode verabschiedet. Bewusst heißt: dokumentiert, nicht vergessen. Bei gewachsenen Systemen kommen dabei regelmäßig URL-Familien zum Vorschein, die niemand mehr auf dem Zettel hatte, etwa TYPO3-Adressen mit index.php-Parametern, die parallel zu ihren sprechenden RealURL-Fassungen indexiert wurden und seit Jahren Duplicate Content erzeugen. Die Migration ist die Gelegenheit, solche Altlasten aufzuräumen, statt sie mitzuschleppen.

Zum URL-Erhalt gehört mehr als das Redirect-Mapping. Strukturierte Daten, die im Altsystem per Plugin erzeugt wurden, müssen im neuen Frontend nachgebaut und automatisiert verglichen werden, sonst verlieren Sie Rich-Snippet-Darstellungen, ohne es zu merken. Mehrsprachige Auftritte brauchen ein hreflang-Gerüst, das exakt die neuen URLs abbildet, denn fehlerhafte hreflang-Verweise fallen erst Wochen später in den Berichten auf. Auch Sitemaps, Canonical-Verweise und die interne Verlinkung wandern mit auf die Prüfliste. Vor dem Produktivumschaltung läuft ein automatisierter Abgleich alt gegen neu über das gesamte Inventar, damit Abweichungen im Testsystem auffallen und nicht im Live-Betrieb.

#Redaktion im laufenden Betrieb: WordPress bleibt das Backend

Die Sorge, die in Erstgesprächen am häufigsten auf den Tisch kommt, betrifft nicht die Technik, sondern den Alltag: Können wir während der Migration weiter publizieren? Die Antwort ist ja, und die Architektur ist der Grund. In den meisten unserer Projekte bleibt WordPress als redaktionelles Backend vollständig bestehen. Ihre Redaktion arbeitet in der gewohnten Oberfläche, mit denselben Workflows, Rollen und Freigaben. Das neue Frontend bezieht die Inhalte über die REST-API oder WPGraphQL und baut daraus die ausgelieferten Seiten.

Das hat drei praktische Konsequenzen. Erstens gibt es keinen wochenlangen Content-Freeze: Bis zum Produktivumschaltung erscheinen neue Inhalte im alten Frontend, danach im neuen, und der Umzugstermin selbst kostet die Redaktion wenige Stunden, nicht Wochen. Zweitens entfällt die Schulungsfrage weitgehend, denn das Werkzeug der Redaktion ändert sich nicht, nur das, was Besucher sehen. Drittens sinkt das Projektrisiko, weil Inhalte und Frontend getrennt umziehen: Geht im Frontend etwas schief, sind die Inhalte davon unberührt.

Bei TYPO3-Altsystemen ist der Weg ein anderer, weil das Backend dort meist Teil des Problems ist. Hier extrahieren wir die Inhalte aus der Datenbank, bereinigen sie und überführen sie entweder in ein frisches WordPress-Backend oder, bei überschaubaren Seitenmengen, direkt in versionierte Markdown-Inhalte im Astro-Projekt. Für Redaktionen, die aus TYPO3 kommen, ist der Wechsel auf den WordPress-Editor erfahrungsgemäß eine Erleichterung, keine Hürde. Wenn Sie ohnehin über die Weiterentwicklung Ihres WordPress-Fundaments nachdenken, greifen Migration und laufende WordPress-Entwicklung in Hamburg ineinander: ein Ansprechpartner für Backend und Frontend.

#Messfenster und Rückkehr zum vorherigen Stand: der Teil, der Vertrauen schafft

Ein Produktivumschaltung ohne Rückweg ist kein Mut, sondern Fahrlässigkeit. Deshalb gehört zu jedem unserer Migrationsprojekte ein dokumentierter und vorher geprobter Rückkehrplan. Der Umzug selbst passiert per DNS- oder Routing-Wechsel, das Altsystem bleibt vollständig lauffähig und wird nicht angerührt. Stellt sich im Live-Betrieb ein Problem heraus, das sich nicht binnen kurzer Zeit beheben lässt, dreht der Wechsel in Minuten zurück, und die Fehleranalyse passiert ohne Druck im Testsystem.

Nach dem Produktivumschaltung beginnt das Messfenster, typischerweise vier bis acht Wochen. Beobachtet werden Indexierungsstand und Crawling-Verhalten in der Search Console, Rankings der wichtigsten Suchbegriffe, Core Web Vitals aus echten Nutzerdaten und die Fehlerraten der Redirect-Schicht. Kleine Bewegungen in den ersten zwei Wochen sind normal, denn Suchmaschinen verarbeiten die neuen Signale erst nach und nach. Entscheidend ist der Trend über das gesamte Fenster. Erst wenn die Kennzahlen stabil auf oder über dem Ausgangsniveau liegen, wird das Altsystem eingefroren, archiviert und abgeschaltet. Die Archivkopie bewahren wir auf, denn die Erfahrung zeigt: Die Frage nach einem Inhalt von vor sechs Jahren kommt immer dann, wenn niemand mehr damit rechnet.

Wer nach der Migration noch eine Schicht weiterdenken will, kombiniert das statische Frontend mit einer Edge-Architektur: Auslieferung und Weiterleitungslogik wandern dann an den Netzwerkrand. Wie das für Hamburger Projekte aussieht, beschreibt unsere Seite zur Cloudflare-Workers-Entwicklung in Hamburg.

#DSGVO und Datengeographie

Eine Migration verändert die Datenflüsse, und das gehört in die Projektplanung, nicht in die Nacharbeit. Drei Fragen klären wir standardmäßig. Erstens: Wo wird gebaut und ausgeliefert? Statische Builds lassen sich auf europäischen Standorten erzeugen und ausliefern, und bei global verteilten Plattformen konfigurieren wir die Verarbeitung so, dass personenbezogene Daten in der EU verarbeitet werden. Zweitens: Was passiert mit Formularen und eingebetteten Diensten? Der Umzug ist der richtige Moment, um Alt-Einbettungen zu inventarisieren, denn in zehn Jahre alten Installationen finden sich regelmäßig Drittdienste, die längst niemand mehr nutzt, aber weiter Daten laden. Drittens: Verzeichnis der Verarbeitungstätigkeiten. Nach der Migration dokumentieren wir die neuen Datenflüsse so, dass Ihr Datenschutzbeauftragter das Verzeichnis aktualisieren kann, ohne die Architektur reverse-engineeren zu müssen.

Ein Nebeneffekt, der in Gesprächen mit Hamburger Unternehmen oft den Ausschlag gibt: Ein statisches Frontend ohne öffentlich erreichbares CMS reduziert die Angriffsfläche erheblich. Das Backend liegt hinter einer Zugriffsbeschränkung, die ausgelieferten Seiten enthalten keine Datenbankverbindung, die kompromittiert werden könnte. Für Unternehmen, deren letzte Sicherheitsvorfälle auf veraltete CMS-Erweiterungen zurückgingen, ist das kein Randthema.

#Drei Fallmuster aus Hamburger Migrationsprojekten

Anonymisiert, aber typisch für die Ausgangslagen, die uns in dieser Stadt begegnen.

Der Logistiker mit zwei Systemen für dieselben Inhalte: Ein mittelständisches Logistikunternehmen mit Sitz am Hafenrand betrieb eine öffentliche WordPress-Site aus dem Jahr 2015 und parallel ein TYPO3-Intranet, in dem Karriereseiten, Zertifizierungen und Unternehmensmeldungen ein zweites Mal gepflegt wurden. Zwei Redaktionswege, zwei Wartungsverträge, und keiner der beiden Stände war verlässlich aktuell: Bewerber fanden auf der öffentlichen Seite andere Stellenanzeigen als im Intranet, und die Fachabteilungen wussten nie, welche Fassung galt. Die Migration war hier in erster Linie eine Konsolidierung. Ein WordPress-Backend wurde zur einzigen Inhaltsquelle, ein Astro-Frontend übernahm den öffentlichen Auftritt, und die bislang im TYPO3 gepflegten internen Inhalte wanderten in einen zugriffsbeschränkten Bereich derselben Plattform. Jeder Inhalt wird seither genau einmal gepflegt, das TYPO3 wurde nach dem Messfenster abgeschaltet, und einer der beiden Wartungsverträge entfiel ersatzlos.

Der Shop vor der Kampagnensaison: Ein Händler plante die Migration seines in die Jahre gekommenen WooCommerce-Frontends, hatte aber eine Herbstkampagne im Kalender, die den Jahresumsatz prägt. Die Entscheidung fiel gegen den Hauruck-Umzug und für eine Etappenmigration: Zuerst wanderten die Inhalts- und Landingpages als Astro-Build auf die neue Architektur, der Checkout blieb unangetastet im Bestand. Die Kampagne lief auf den neuen, schnellen Landingpages, der Kaufabschluss auf dem bewährten System. Der Checkout-Umzug folgte nach der Saison, mit Ruhe und ohne Umsatzrisiko. Für Projekte dieser Art arbeiten Migrations- und WooCommerce-Entwicklung in Hamburg Hand in Hand.

Das Agentur-Erbe ohne Dokumentation: Ein Mittelständler übernahm mit einem Firmenzukauf eine TYPO3-Installation, deren betreuende Agentur nicht mehr existierte. Kein Zugang zur Versionsverwaltung, keine Dokumentation, Extensions in einem Zustand, der ein Upgrade wirtschaftlich sinnlos machte. Der Weg: Inhalte aus der Datenbank extrahieren und bereinigen, die tatsächlich genutzten Funktionen in Workshops mit den Fachabteilungen identifizieren, dann Neuaufbau als Astro-Frontend mit WordPress-Backend. Zwei Drittel der alten Extensions stellten sich als ungenutzt heraus und entfielen ersatzlos. Das Projekt war weniger Migration als geordnete Erbschaftsannahme, und genau so haben wir es geplant.

#Wann sich eine Migration nicht lohnt

Der Abschnitt, der auf Agentur-Websites gern fehlt. Eine Migration ist die falsche Antwort, wenn das eigentliche Problem im Inhalt liegt: Veraltete Texte und fehlende Pflege werden durch ein neues Framework nicht besser, nur schneller ausgeliefert. Sie ist ebenfalls die falsche Antwort für gesunde WordPress-Installationen mit gutem Hosting und gepflegtem Theme, deren Ladezeiten im grünen Bereich liegen; dort erreicht gezielte Optimierung im Bestand den Großteil des Effekts für einen Bruchteil des Aufwands. Und sie ist verfrüht, wenn im Haus niemand die Verantwortung für die neue Architektur übernehmen kann und auch kein Betriebspartner eingeplant ist, denn ein modernes Frontend ohne Pflege altert genauso wie ein altes.

Auch der Zeitpunkt kann gegen das Projekt sprechen: Wer drei Wochen vor der wichtigsten Saison des Jahres migrieren will, sollte es nicht tun. Dann verschieben wir den Termin lieber gemeinsam, statt ihn zu halten und die Risiken mitzunehmen. Eine Migration, die aus Termindruck ohne Messfenster durchgezogen wird, holt sich ihre Abkürzungen später doppelt zurück.

#Zusammenarbeit: wie ein Migrationsprojekt mit uns abläuft

Wir arbeiten mit Hamburger Unternehmen remote-first und deutschsprachig, mit festen Ansprechpartnern und in Etappen, die einzeln abgenommen werden. Am Anfang steht das Migrations-Audit: Bestandsaufnahme des Altsystems, URL-Inventar, Bewertung der Inhalte und eine begründete Empfehlung. Fällt sie gegen die Migration aus, steht das genauso im Bericht wie der günstigere Weg im Bestand. Danach folgen Framework-Entscheidung pro Route, Parallelaufbau gegen das laufende Backend, Produktivumschaltung mit geprobtem Rückweg und das Messfenster mit Bericht.

Jede Etappe endet mit einem Ergebnis, das für sich stehen kann, und einer Entscheidung, ob es weitergeht. Das schützt beide Seiten: Sie binden sich nicht an ein Großprojekt mit ungewissem Ende, und wir arbeiten gegen definierte Abnahmekriterien statt gegen wandernde Erwartungen. Die Preisgestaltung ist individuell und wird pro Etappe geschätzt, nicht als Pauschale über ein Projekt, dessen Unbekannte am Anfang niemand seriös beziffern kann.

Zum Abschluss gehört die Übergabe: Dokumentation der Architektur, der Redirect-Schicht und der Build-Prozesse, Einweisung Ihres Teams und auf Wunsch ein Betriebsmodell für die laufende Pflege. Das Ziel ist ein System, das Ihr Haus versteht und weiterentwickeln kann, nicht eine neue Abhängigkeit. Der erste Schritt kostet Sie ein Gespräch und uns ein paar Tage Analyse: Sie bekommen das Audit mit einer Aufwandsschätzung pro Etappe und entscheiden intern, ob und wann es weitergeht.

Zuletzt aktualisiert: 10. Juli 2026