Migration zu Next.js / Astro in München

#München: Konzernumfeld, Mittelstand und ein eigenes Migrationsklima

Migrationsprojekte in München haben eine Eigenheit, die in kaum einer anderen deutschen Stadt so ausgeprägt ist: Die Technik ist selten der schwierigste Teil. Die Stadt ist geprägt von Konzernzentralen und einem Mittelstand, der ihnen zuliefert. Um die Automobilindustrie herum arbeitet ein dichtes Netz von Zulieferern und Engineering-Dienstleistern, die Versicherungswirtschaft konzentriert sich hier wie nirgendwo sonst im Land, und mit dem Verlagsstandort rund um das Burda-Umfeld und die großen Fachverlage kommt eine dritte Branche dazu, die seit Jahrzehnten publiziert und entsprechend viel digitales Erbe mitschleppt. Wer für diese Unternehmen eine Website migriert, migriert nicht nur URLs, sondern durchläuft Freigabeprozesse: IT-Sicherheit, Einkauf, Datenschutz, manchmal alle drei nacheinander.

Das zweite Münchner Merkmal ist das Preisniveau. Die Agenturdichte zwischen Schwabing und dem Werksviertel ist hoch, die Tagessätze gehören zu den höchsten in Deutschland, und genau das treibt seit einigen Jahren das Interesse an Nearshoring: gleiche Qualität, deutschsprachige Projektführung, aber eine Kostenstruktur, die nicht an Münchner Büromieten hängt. Wir arbeiten seit 2007 mit WordPress und führen Migrationsprojekte für deutsche Unternehmen remote und auf Deutsch, mit einem Lieferprozess, der auf Freigabeorganisationen ausgelegt ist. Diese Seite beschreibt, wie das für Münchner Verhältnisse konkret aussieht.

Das dritte Merkmal ist das Altsystem-Profil. Der Münchner Mittelstand hat in den Nullerjahren überdurchschnittlich oft auf TYPO3 und Contao gesetzt, häufig eingeführt von Agenturen, die es nicht mehr gibt oder die das Produkt nicht mehr betreuen. Diese Installationen laufen, aber jede PHP-Aktualisierung wird zum Projekt, und die Frage nach dem Upgrade-Pfad beantwortet niemand mehr verbindlich. Dazu kommen WordPress-Auftritte mit einem Jahrzehnt Theme- und Plugin-Geschichte sowie zweisprachige Corporate-Sites, deren englische Fassung einst nachträglich angebaut wurde und seither ein hreflang-Provisorium trägt.

#Migration oder Relaunch: erst rechnen, dann entscheiden

Die beiden Begriffe bezeichnen verschiedene Projekte. Ein Relaunch erneuert Gestaltung und Inhalte im bestehenden System. Eine Migration wechselt die technische Basis und nimmt Inhalte, URLs und Sichtbarkeit mit. Welcher Weg der richtige ist, entscheidet keine Präferenz, sondern eine Bestandsaufnahme.

Für eine Migration spricht, wenn das System selbst zur Belastung geworden ist: ein TYPO3, dessen Versionssprung teurer würde als ein neues Frontend. Ein Contao, für das im Haus niemand mehr Verantwortung übernehmen will. Ein WordPress-Theme, in dem jede Änderung Nebenwirkungen erzeugt, oder eine Sicherheitslage, in der ein öffentlich erreichbares CMS mit eingefrorenen Erweiterungen bei jedem Audit als Befund auftaucht. Gerade der letzte Punkt hat in München Gewicht: Wo Vendor-Audits und Informationssicherheits-Richtlinien den Takt vorgeben, ist ein statisches Frontend ohne öffentlich erreichbares CMS ein Argument, das die IT-Sicherheit versteht.

Für einen Relaunch im Bestand spricht, wenn das System gesund ist und nur der Auftritt gealtert wirkt. Ein gepflegtes WordPress mit aktuellem PHP und schlankem Theme braucht keine neue Architektur, sondern bessere Gestaltung und Inhalte. Wir prüfen das im Audit ohne Vorfestlegung und schreiben die Empfehlung so auf, dass sie intern weitergereicht werden kann, denn in Münchner Organisationen liest sie am Ende nicht nur das Marketing, sondern auch IT und Einkauf.

#Freigabeprozesse und Vendor-Audits: der Münchner Sonderfall

In vielen Städten beginnt ein Migrationsprojekt mit dem Kickoff. In München beginnt es häufig mit einem Fragebogen. Konzerntöchter, Zulieferer mit Kundenvorgaben und versicherungsnahe Unternehmen haben Lieferantenprozesse, die auch für Website-Dienstleister gelten: Sicherheitsfragebogen, Auftragsverarbeitungsvertrag, Nachweis über Unterauftragsverarbeiter, manchmal ein Gespräch mit der Informationssicherheit. Wer als Dienstleister erst im Projekt merkt, dass es diese Stufe gibt, verliert Wochen.

Wir behandeln die Freigabe deshalb als eigene Projektetappe mit eigenem Ergebnis. Zum Standardpaket gehören die Beschreibung der Entwicklungs- und Auslieferungskette vom Repository bis zur Auslieferung, ein Zugriffs- und Berechtigungskonzept, die Liste der eingesetzten Dienste mit Verarbeitungsorten und ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Sicherheitsfragebögen beantworten wir schriftlich und so, dass die Antworten einer Nachprüfung standhalten, statt sie mit Marketingvokabular zu füllen. Und wir sagen auch, was wir nicht vorweisen: Wer eine bestimmte Zertifizierung des Dienstleisters zwingend fordert, erfährt das von uns im ersten Gespräch, nicht nach der Beauftragung.

Der zweite Teil des Sonderfalls betrifft die Abnahmen. Freigabeorganisationen brauchen Etappen mit dokumentierten Ergebnissen, weil interne Stakeholder wechseln und Entscheidungen begründet werden müssen. Unser Lieferprozess ist darauf gebaut: Jede Etappe endet mit einem Dokument, das für sich stehen kann, vom URL-Inventar über die Framework-Zuordnung bis zur Produktivumschaltung-Unterlage mit geprobtem Rückweg zum Altsystem. Das ist Mehraufwand gegenüber einem Zuruf-Projekt, aber er zahlt sich genau dann aus, wenn die IT-Leitung den Umzugstermin freigeben soll und wissen will, was passiert, falls etwas schiefgeht.

#Astro, Next.js oder beides: eine Vorlage für die Freigaberunde

In freigabepflichtigen Häusern ist die Framework-Wahl keine Frage des Entwicklergeschmacks, sondern eine Entscheidung, die IT-Leitung, Einkauf und Fachabteilung gemeinsam abzeichnen und Jahre später noch begründen können müssen. Wir bereiten sie deshalb als Entscheidungsvorlage pro Seitentyp auf, mit den Kriterien, die eine Freigabestelle tatsächlich prüft: Angriffsfläche, Betriebsverantwortung, Personalabhängigkeit, Folgekosten. Astro rendert Seiten zur Build-Zeit als statisches HTML und liefert JavaScript nur aus, wo eine Komponente es anfordert. Für Produktseiten, Referenzen, Karrierebereich und Newsroom heißt das in der Sprache eines Sicherheitsfragebogens: kein Server im Anfragepfad, keine öffentlich erreichbare Anwendung, die erklärt und gepatcht werden müsste, ein Lastprofil ohne Kapazitätsdiskussion. Next.js kommt in die Vorlage, sobald Seiten pro Nutzer unterschiedlich aussehen, also bei Kundenportalen, Produktkonfiguratoren, Händlerbereichen mit Login und komplexen Suchen. Dann steht dem Mehrwert ein bewusst dokumentierter Betriebsaufwand gegenüber.

Das Ergebnis der Vorlage lautet für viele Münchner Unternehmen: beides, mit sauber gezogener Grenze. Der Auftritt läuft als Astro-Build, das Portal als Next.js-Anwendung hinter derselben Domain. Wichtiger als die Wahl selbst ist, dass sie pro Seitentyp schriftlich begründet ist, denn eine Revision fragt nicht, ob die Architektur modern war, sondern warum ein statisch abbildbarer Inhalt eine Serverinfrastruktur bekommen hat oder eine interaktive Anwendung in ein statisches Modell gepresst wurde. Beide Antworten kosten über Jahre Betriebsbudget, wenn sie falsch ausfallen.

In die Vorlage gehört auch das Lieferantenrisiko nach dem Projekt. Astro-Projekte mit CMS-Anbindung kann ein kleines Team oder ein Betriebspartner ohne seltene Spezialkenntnisse pflegen. Next.js-Anwendungen setzen React-Kompetenz voraus, die intern vorhanden sein oder eingekauft werden muss, und zwar zu Münchner Konditionen, falls sie lokal eingekauft wird. Wer die Framework-Entscheidung ohne diese Position freigibt, genehmigt ein Projekt mit verdeckten Folgekosten. Eine stadtunabhängige Gegenüberstellung der beiden Frameworks finden Sie in unserem Leitfaden zur Website-Migration mit Next.js und Astro.

#URL-Erhalt und die zweisprachige Corporate-Site

Wenn Migrationen organische Sichtbarkeit kosten, liegt es fast nie am Framework und fast immer an verlorenen URLs. Jedes Projekt beginnt deshalb mit einem vollständigen URL-Inventar aus drei Quellen: Crawl des Altsystems, Leistungsdaten der Search Console und Server-Logs der letzten Monate. Die Logs zeigen, was kein Crawler mehr findet, aber Menschen noch aufrufen: Links aus Newslettern, PDF-Datenblättern, Partnerportalen und Intranets. Gerade bei Zulieferern mit langlebigen Produktdokumenten sind diese Adressen wertvoller als ihr Traffic vermuten lässt, denn hinter einem einzelnen Aufruf steht dort oft ein laufender Beschaffungsvorgang.

Jede Adresse aus dem Inventar bekommt eine Entscheidung: weiterleben unter gleicher URL, 301-Weiterleitung auf einen Nachfolger oder dokumentierte Verabschiedung mit korrektem Statuscode. Bei TYPO3- und Contao-Systemen fördert das Inventar regelmäßig Parameterfassungen und doppelt indexierte Varianten zutage, die seit Jahren Duplicate Content erzeugen. Die Migration ist der Moment, diese Altlasten aufzuräumen statt mitzunehmen.

Die Münchner Besonderheit ist die Zweisprachigkeit. DE/EN-Auftritte sind bei international liefernden Unternehmen der Normalfall, und die englische Fassung ist historisch oft nachträglich angebaut: eigene URL-Logik, unvollständige Übersetzungen, ein hreflang-Gerüst, das nie ganz stimmte. In der Migration behandeln wir jede Sprachversion als eigenes Inventar mit eigenem Mapping und bauen das hreflang-Gerüst auf den neuen Adressen vollständig neu, inklusive der unbequemen Entscheidungen: Was passiert mit Seiten, die nur auf Deutsch existieren? Verweist die englische Startseite auf die deutsche oder auf eine internationale Fassung? Diese Fragen werden vor dem Produktivumschaltung schriftlich entschieden, und der Abgleich alt gegen neu läuft automatisiert über beide Sprachversionen.

#Redaktion und Fachabteilungen während der Migration

Die häufigste Sorge in Erstgesprächen betrifft den Alltag: Kann weiter publiziert werden? Die Antwort ist ja, und sie ist architektonisch begründet. Bleibt WordPress als redaktionelles Backend bestehen, arbeitet die Redaktion durchgehend in der gewohnten Oberfläche, mit denselben Rollen und Freigaben. Das neue Frontend bezieht die Inhalte über die REST-API oder WPGraphQL und baut daraus die ausgelieferten Seiten. Der Content-Freeze schrumpft auf wenige Stunden um den Umzugstermin.

In Münchner Organisationen kommt eine zweite Dimension dazu: Es publiziert selten nur die Unternehmenskommunikation. Personalabteilungen pflegen Stellenanzeigen, Produktmanagement aktualisiert Datenblätter, Investor Relations und Compliance haben Veröffentlichungspflichten mit Terminen, die sich nicht nach dem Projektplan richten. Wir erfassen diese Publikationsströme im Audit und planen den Produktivumschaltung um sie herum, statt von den Abteilungen Terminverzicht zu verlangen. Bei TYPO3- und Contao-Abschaltungen, wo das Backend mitwandert, gibt es statt eines langen Freeze einen terminierten Übergabepunkt je Inhaltstyp, damit die Fachabteilung weiß, ab wann sie im neuen System arbeitet.

Wenn das Ziel-Backend WordPress ist, greifen Migration und laufende Betreuung ineinander: Die WordPress-Entwicklung in München deckt den Weiterbetrieb nach der Übergabe ab, vom Backend-Update bis zur neuen Landingpage, mit demselben Ansprechpartner wie im Migrationsprojekt.

#DSGVO und Datengeographie im Konzernumfeld

Eine Migration verändert Datenflüsse, und in München fragt danach nicht nur der Datenschutzbeauftragte, sondern oft auch der Kunde des Kunden: Zulieferer erben die Compliance-Anforderungen ihrer Abnehmer. Drei Punkte klären wir standardmäßig. Erstens die Verarbeitungsorte: Statische Builds lassen sich auf europäischen Standorten erzeugen und ausliefern, und wo global verteilte Plattformen im Spiel sind, konfigurieren wir die Verarbeitung so, dass personenbezogene Daten in der EU bleiben, dokumentiert für das Verarbeitungsverzeichnis. Zweitens die Alt-Einbettungen: Zehn Jahre alte Installationen laden regelmäßig Drittdienste, die niemand mehr nutzt, aber weiter Daten übertragen. Der Umzug ist der richtige Moment für dieses Inventar. Drittens die Dokumentation: Nach der Migration beschreiben wir die neuen Datenflüsse so, dass Ihr Datenschutzbeauftragter das Verzeichnis aktualisieren kann, ohne die Architektur selbst auseinandernehmen zu müssen.

Ein Nebeneffekt, der in Freigabegesprächen regelmäßig den Ausschlag gibt: Ein statisches Frontend hat kein öffentlich erreichbares CMS, keine Datenbankverbindung in der ausgelieferten Seite und entsprechend wenig Angriffsfläche. Für Organisationen, deren letzter Audit-Befund auf veraltete CMS-Erweiterungen zurückging, ist das kein Randthema, sondern ein Argument gegenüber der eigenen IT-Sicherheit. Wer nach der Migration noch eine Schicht weiterdenkt, verlagert Auslieferung und Weiterleitungslogik zusätzlich an den Netzwerkrand; wie das aussieht, beschreibt unsere Seite zur Cloudflare-Workers-Entwicklung in München.

#Drei Fallmuster aus Projekten mit Münchner Prägung

Die Namen sind entfernt, die Konstellationen nicht: So beginnen Migrationsprojekte in dieser Stadt typischerweise.

Der Zulieferer mit der zweisprachigen TYPO3-Site: Ein Industrieunternehmen mit Abnehmern in der Automobilbranche betrieb einen DE/EN-Auftritt auf einem TYPO3, dessen betreuende Agentur die Wartung gekündigt hatte. Der Weg zur Beauftragung führte über den Einkauf: Sicherheitsfragebogen, Auftragsverarbeitungsvertrag, Freigabe der Auslieferungskette. Erst danach begann die eigentliche Arbeit: Inhalte aus der TYPO3-Datenbank extrahieren, beide Sprachversionen als getrennte URL-Inventare mappen, hreflang neu aufbauen, Frontend als Astro-Build gegen ein frisches WordPress-Backend. Der Produktivumschaltung lag bewusst außerhalb der Messezeiten des Kunden, und die Freigabeunterlage mit Rückweg zum Altsystem ging vor dem Termin an die IT-Leitung.

Das versicherungsnahe Unternehmen mit dem Page-Builder-Erbe: Ein Dienstleister aus dem Versicherungsumfeld kam mit einem WordPress, das unter einem Page-Builder-Theme und Jahren von Plugin-Schichten kaum noch wartbar war. Die interne Informationssicherheit hatte das öffentlich erreichbare CMS bereits zweimal als Befund notiert. Die Lösung war die Trennung von Backend und Frontend: WordPress wanderte hinter eine Zugriffsbeschränkung und blieb Redaktionssystem, das Frontend entstand neu als statischer Build. Der Audit-Befund war damit strukturell erledigt, nicht kosmetisch, und die Redaktion behielt ihre gewohnte Arbeitsumgebung.

Der Fachverlag mit dem Kampagnenkalender: Ein Verlagshaus plante die Ablösung seines gewachsenen Auftritts, hatte aber laufende Kampagnen und einen Shop, dessen Umsatz an Erscheinungsterminen hängt. Statt eines Hauruck-Umzugs fiel die Entscheidung für Etappen: zuerst die Inhalts- und Landingpages als Astro-Build, der Shop blieb vorerst im Bestand und folgte nach der Saison. Für solche Konstellationen arbeiten Migrations- und WooCommerce-Entwicklung in München Hand in Hand, mit einem gemeinsamen URL-Inventar und einem Redirect-Stand pro Etappe.

#Wann wir von einer Migration abraten

Eine Entscheidungsvorlage, die nur den Weg zur Beauftragung kennt, ist keine Vorlage, sondern ein Verkaufsdokument. Deshalb dokumentieren wir im Audit auch die Fälle, in denen das Projekt nicht stattfinden sollte. Liegt die Unzufriedenheit im Inhalt, bei veralteten Texten und fehlender Positionierung, liefert ein neues Frontend dieselben Schwächen nur schneller aus, und das Budget wäre in der Redaktion besser angelegt. Trägt das vorhandene WordPress-Fundament, mit aktuellem PHP, gepflegtem Theme und solidem Hosting, holt gezielte Optimierung im Bestand den Großteil des Effekts zu einem Bruchteil des Aufwands heraus. Und wo niemand im Haus die neue Architektur verantworten wird und kein Betriebspartner vorgesehen ist, entsteht mit der Migration nur die nächste Altlast, die in einigen Jahren der nächste Dienstleister vorfindet.

Ein Münchner Spezialfall gehört ebenfalls hierher: Wenn Ihr Freigabeprozess für den Dienstleisterwechsel länger dauern würde als die verbleibende Lebenszeit des Altsystems bis zur nächsten harten Deadline, etwa einem PHP-Support-Ende, dann ist die richtige Reihenfolge, zuerst das Altsystem abzusichern und die Migration danach geordnet aufzusetzen. Beides zugleich unter Termindruck zu erzwingen erzeugt genau die Abkürzungen, die sich später doppelt rächen. Wir sagen das im Audit offen, auch wenn es das Projekt verschiebt.

#Ablauf für B2B-Organisationen: Etappen, Abnahmen, Übergabe

Wir arbeiten mit Münchner 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 über alle Sprachversionen, Bewertung der Inhalte und eine schriftliche Empfehlung, die so begründet ist, dass sie eine Freigaberunde übersteht, gegebenenfalls auch als Empfehlung gegen das Projekt. Parallel dazu läuft die Vendor-Freigabe mit Ihrem Einkauf und Ihrer IT-Sicherheit, damit sie den Projektstart nicht blockiert.

Danach folgen Framework-Zuordnung pro Seitentyp, Parallelaufbau gegen das laufende Backend, Produktivumschaltung mit geprobtem Rückweg und ein Messfenster von vier bis acht Wochen, in dem Indexierung, Rankings und Core Web Vitals gegen den Ausgangsstand laufen. Jede Etappe endet mit einem Ergebnis, das für sich stehen kann, und einer Entscheidung, ob es weitergeht. Die Preisgestaltung ist individuell und wird pro Etappe geschätzt, sodass Einkauf und Fachabteilung mit belastbaren Zahlen arbeiten statt mit einer Pauschale über ein Projekt voller Unbekannter.

Die letzte Etappe ist die Übergabe, und sie ist als Freigabedokument gebaut: Architektur, Redirect-Schicht und Build-Prozesse liegen so beschrieben vor, dass Ihre IT sie ohne uns betreiben und eine Revision sie ohne uns nachvollziehen kann. Dazu gehören die Einweisung Ihres Teams und auf Wunsch ein Betriebsmodell mit klaren Zuständigkeiten, damit das Lieferantenrisiko nach Projektende bewertbar bleibt statt offen. Der Einstieg passt in Ihren Freigabelauf: ein Audit mit begründeter Empfehlung und einer Aufwandsschätzung pro Etappe, formuliert so, dass Einkauf und IT-Leitung direkt damit arbeiten können.

Zuletzt aktualisiert: 10. Juli 2026