Von Sitecore zu Next.js: die Neugestaltung, für die Sie ohnehin bezahlen.

Was wird von Sitecore nach Next.js übertragen und was nicht??

Übernehmen können Sie Ihre Inhaltselemente und Feldwerte, außerdem die Seitenhierarchie. Ihre Darstellungen, Personalisierungsregeln und xConnect-Daten kommen dagegen nicht mit. Zuerst zählen die Felder: Die mit der CLI als .yml-Dateien serialisierten Elemente liefern die Rohfelder; aus Ihren Vorlagen werden im Zielsystem Inhaltstypen, aus Ihren Medien Assets mit neuen URLs. Aber Renderings wandern gar nicht mit. Jedes einzelne bauen Sie als Next.js-Komponente neu (von Ihrem aktuellen HTML und CSS bleibt kaum etwas erhalten). Planen Sie also erst gar nicht damit, hier etwas wiederzuverwenden.

Prüfen Sie, was standardmäßig verloren geht. Ihre xDB-basierte Personalisierung müssen Sie sichten; danach erstellen Sie jede Regel neu, ersetzen sie oder setzen sie außer Kraft, statt anzunehmen, dass sie dem Inhalt folgt. Sitecore-Formular-Workflows bauen Sie neu auf. Pipelines und Ereignisbehandler stellen Sie um, geplante Aufgaben ebenso. Und dafür nutzen Sie API-Routen, Edge-Funktionen oder Webhooks. Wenn Sie das integrierte Solr oder Azure Search nutzen, kommt noch ein Schritt dazu: Entwerfen Sie Index, Facetten und Abfragelogik neu und wählen Sie einen Ersatz wie Algolia oder Coveo.

Wie planen Sie die URL-Struktur und Weiterleitungen, damit Ihr Suchverkehr erhalten bleibt??

Für die URL-Zuordnung exportieren Sie alle Live-URLs Ihrer aktuellen Website und weisen jeder ein freigegebenes Ziel zu, bevor Sie mit dem Bau beginnen. Raten Sie nicht. Crawlen Sie die Live-Website, statt sich auf die Sitemap zu verlassen. Gleichen Sie das Ergebnis danach mit Ihren Serverprotokollen ab: So finden Sie verlässlich die Seiten, die tatsächlich Traffic und Links bringen.

Lassen Sie URLs möglichst unverändert, denn eine unveränderte URL braucht keine Weiterleitung. Das hält den Umzug einfach. Muss sich eine URL ändern, setzen Sie eine serverseitige 301- oder 308-Weiterleitung ein, die Google mitteilt, dass die Seite dauerhaft verschoben wurde. Vermeiden Sie Weiterleitungsketten: Jede alte Adresse soll direkt auf die endgültige zeigen. Behalten Sie die Weiterleitungen mindestens ein Jahr bei und testen Sie sie mit dem URL-Prüftool oder einem Skript, denn eine Stichprobe ist noch lange kein Test.

Beachten Sie genau, was Ihr Feldexport auslässt. Canonical-Tags und hreflang-Attribute stehen nicht darin, strukturierte Daten ebenfalls nicht. Auch Meta-Tags, die Ihre Sitecore-Renderings dynamisch erzeugen, müssen Sie von Hand erfassen. Fangen Sie damit an. Die kostenlose Bewertung liest Canonical-Angaben und strukturierte Daten auf Ihren Stichprobenseiten aus und liefert Ihnen eine erste Arbeitsliste, bevor Sie sich mühsam durch Vorlagen und Renderings arbeiten.

Wie werden Inhalte aus Sitecore übertragen: Export, API oder Crawling??

Inhalte übertragen Sie zuerst per Export, danach über die API Ihres Ziels. Per Crawling holen Sie nur nach, was auf beiden Wegen nicht ankommt. Beginnen Sie auf der Festplatte. Installieren Sie das CLI-Serialisierungs-Plugin und schreiben Sie mit dem Unterbefehl „pull“ Ihre Elemente als .yml-Dateien heraus, gesteuert über Ihre „Module.json“-Dateien. Liegen die Dateien auf der Festplatte, können Sie sie in die Versionskontrolle legen und die Unterschiede zwischen den Durchläufen vergleichen. Und genau das macht jeden Durchlauf verlässlicher.

Schreiben Sie danach ein Skript, das diese Dateien liest und die Einträge über die API in Ihr Headless-CMS anlegt. Jede Vorlage entspricht dabei einem Inhaltstyp. Rechnen Sie fest mit mehreren Durchläufen. Prüfen Sie Medien, Links und Rich-Text jedes Mal selbst, denn der Export verifiziert sie nicht. Aber Rich-Text ist die tückischste Falle: Er enthält interne Links, die Sie auf die neuen URLs umschreiben müssen.

Setzen Sie einen Crawler ein, wenn Ihre gerenderten Seiten Inhalte zeigen, die in keinem Elementfeld stehen. Vergleichen Sie genau. Legen Sie die gecrawlten Inhalte direkt neben die exportierten Felder: So sehen Sie auf einen Blick, welche Seiten allein durch den Export unvollständig geblieben sind.

Was erhalten Ihre Redakteure bei Next.js im Vergleich zu Sitecore??

Sitecore bündelt strukturierte Felder und Live-Vorschau in einer gemeinsamen Arbeitsumgebung für Ihre Redaktion. Und wie visuell sich diese Oberfläche wirklich anfühlt, hängt am Ende von der gewählten Frontend-Technik ab. Ihr Redaktionsteam merkt diese Entscheidung jeden Tag. Entscheiden Sie sich für Sanity, klicken Redakteure in der Vorschau auf ein Element und landen direkt beim passenden Feld im Sanity Studio. Die Dokumentation nennt Live-Vorschau, Klick-Bearbeitung und Drag-and-Drop für den Seitenaufbau, dazu einen Schnellstart für den Next.js App Router.

Wählen Sie die Technik danach aus, was Ihre Website leisten muss. Für eine reine Content- oder Marketing-Präsenz kann Astro genügen, aber Sie verzichten auf die visuelle Arbeitsfläche eines Editors, auf Plugins und auf einen gehosteten Admin-Bereich; ein CMS Ihrer Wahl müssen Sie also ergänzen. Für interaktive Anwendungen, Personalisierung oder viele Redakteure passt Next.js mit Sanity oder Contentful besser. Suche, Formulare und Personalisierungsfunktionen bauen Sie dann allerdings selbst darum herum. Ohne Konfiguration läuft keine der beiden Varianten.

Lassen Sie sich heute einen konkreten Bearbeitungsvorgang vorführen. Erst wenn Sie den Ablauf sehen, merken Sie, wie viel von der gewohnten Arbeitsfläche Sie wirklich behalten müssen.

Wie lange dauert eine Migration von Sitecore zu Next.js, und wovon hängt der Aufwand ab??

Planen Sie mehr Zeit ein. Sengo schätzt die Migration eines mittelständischen Unternehmens von XP zu SitecoreAI auf 9 bis 14 Monate, große Webauftritte mit mehreren Standorten auf mehr als 18 Monate. Aber wo Sie in diesem Zeitfenster landen, bestimmen Ihre URLs, Inhaltstypen, Medien, Integrationen und Sprachversionen. Die meisten dieser Faktoren können Sie schon heute realistisch einschätzen.

Ihr eigentlicher Vergleich heißt XM Cloud gegen ein Headless-CMS, denn schon der Wechsel von XP zu XM Cloud bedeutet eine Neuprogrammierung mit Next.js. Der Content-Speicher kommt erst danach. Das CMS ist nur der Content-Store hinter einem Frontend derselben Bauart. Den größten Teil des Aufwands verursachen das Neuerstellen der Darstellungen als Komponenten, das Überarbeiten von Integrationen und die Migration der Inhalte in mehreren Durchgängen, egal für welchen Store Sie sich entscheiden. Die Wahl des Stores ist hier nicht der schwere Teil.

Zählen Sie zuerst Ihre Vorlagen. Liegen Sie nach Sengos Faustregel unter 50 Vorlagen und nutzen kaum eigenen Code, kann der direkte Wechsel zu SitecoreAI gelingen. Listen Sie danach Ihre eigenen Pipelines, Ereignisbehandler und geplanten Aufgaben auf: Jedes dieser Elemente braucht einen neuen Ort, den Sie erst schaffen müssen. Zählen Sie auch die Sprachversionen durch. Jede einzelne Sprache vergrößert Ihre Inhaltsdurchläufe und verlängert Ihre Liste an Weiterleitungen.

Wann sollten Sie nicht von Sitecore zu Next.js wechseln??

Wechseln Sie nicht von Sitecore zu Next.js, wenn Ihre aktuelle Website ihre Ziele erfüllt, der Support noch lange genug läuft und Ihr Team keine Probleme hat, die eine Neugestaltung lösen würde. Erzwingen Sie es nicht. Eine Neugestaltung ohne Problem, das sie behebt, verbrennt nur Budget.

Prüfen Sie zuerst Ihre Version. Sitecore 10.4 wird bis zum 31. Dezember 2027 unterstützt, Version 10.3 bis zum 31. Dezember 2025, und 10.5 unterstützt Windows Server 2025, SQL Server 2025 und Solr 10. Setzen Sie Version 10.4 ein, haben Sie Zeit für eine saubere Planung. Bei einem Upgrade bleiben die bestehenden Funktionen an ihrem gewohnten Platz; bei einer Neuinstallation verlieren Sie Ihre MVC-Renderings und Ihre xDB-basierte Personalisierung.

Bleiben Sie auch dann dabei, wenn Ihre Website auf einer unersetzlichen xDB-Personalisierung beruht oder Ihre Suche auf dem integrierten Solr läuft, den Sie nicht neu aufbauen möchten. Dasselbe gilt, wenn Ihre Seiten in der Bewertung ohnehin gut abschneiden. Machen Sie den Test. Dann sehen Sie klarer, ob Ihre Probleme an der Plattform oder an Ihren Seiten liegen. Ich plane solche Umstellungen und führe sie durch: von Alt-Systemen und WordPress-Umgebungen hin zu diesen Stacks. Und manchmal lautet mein Rat: Bleiben Sie, wie Sie sind. [Das ist eine berechtigte Antwort, wenn die Fakten dafür sprechen.]

Fragen und Antworten.

Weiterlesen.

1. 01Sitecore-AlternativenUnterstützungsdaten, Lizenzinformationen und die Wege weg von XP.
2. 02AEM-AlternativenWas Sie ausführen sollten, wenn Sie nur einen Teil der Suite nutzen.
3. 03Next.js-SEO-AuditRendering-Modus, Metadaten, Hydration-Kosten.