Wenn du eine Sitecore JSS-Implementierung betreibst, hast du die Neuigkeiten wahrscheinlich schon gehört – oder du findest es gerade heraus, weil niemand in deinem Team Ankündigungen zum Produktlebenszyklus liest. Auf jeden Fall ist hier die Situation: Das Sitecore JavaScript SDK (JSS) wie du es kennst, erreicht 2026 das End of Life, und die Uhr läuft auf einen Juni-Termin zu, der schneller kommt, als du denkst.

Ich habe genug Enterprise-CMS-Migrationen durchgemacht, um zu wissen, dass allein die Planungsphase die meisten Teams 3–6 Monate dauert. Die tatsächliche Migration? Weitere 3–6 Monate für alles, das nicht trivial ist. Wenn du das also Anfang 2025 liest, bist du nicht zu früh dran – du bist genau rechtzeitig. Wenn du das später liest... musst du gestern anfangen.

Lassen Sie uns aufschlüsseln, was tatsächlich passiert, welche Optionen du hast, und wie du eine Entscheidung triffst, die dein Team nicht in Panik versetzt.

Inhaltsverzeichnis

Sitecore JSS End of Life 2026: Migration Options Before June

Was passiert tatsächlich mit Sitecore JSS

Sitecore verfolgt seit einigen Jahren aggressiv seine Composable-DXP-Strategie. Die On-Premise- und selbst gehosteten Sitecore XP/XM-Plattformen, für die JSS entwickelt wurde, werden zugunsten von Sitecore XM Cloud – ihrem SaaS-Angebot – eingestellt.

Hier ist der Zeitplan, der zählt:

  • Sitecore XP 10.x endet 2026 bei der Mainstream-Unterstützung
  • JSS SDK-Versionen gebunden an XP/XM On-Prem verlieren aktive Entwicklung und Sicherheitspatches
  • Juni 2026 ist das Schlüsseldatum, an dem sich die erweiterten Supportbedingungen erheblich ändern
  • Sitecore XM Cloud wird die einzige aktiv entwickelte Sitecore Headless-Plattform in Zukunft

Was „End of Life" praktisch bedeutet: keine neuen Funktionen, keine proaktiven Sicherheitspatches und schließlich keine Antwort auf Support-Tickets. Deine Website funktioniert am 30. Juni nicht einfach nicht mehr. Aber wenn etwas kaputt geht – eine Sicherheitslücke, ein Kompatibilitätsproblem mit einem neuen Browser, ein Node.js-Versionskonflikt – bist du auf dich allein gestellt.

Ich habe Teams versuchen sehen, EOL-Plattformen auszusitzen. Es funktioniert eine Zeit lang. Dann funktioniert es wirklich, wirklich nicht.

Warum das mehr bedeutet als ein typisches EOL

Das ist nicht wie das Upgrade von React 17 zu React 18, wo du ein paar Abhängigkeiten aktualisierst und ein paar Breaking Changes über ein Wochenende behebst. Sitecore JSS ist tief mit dem Sitecore-Backend gekoppelt. Der Layout Service, der Content Resolver, die Rendering Host-Architektur – alles ist spezifisch dafür, wie Sitecore Inhalte für dein JavaScript-Frontend bereitstellt.

Wenn JSS End of Life erreicht, verlierst du nicht nur ein Frontend-SDK. Du verlierst die gesamte Brücke zwischen deinen Inhalten und deiner Präsentationsschicht. Das bedeutet, dass jede Migrationsmöglichkeit beide Seiten dieser Gleichung neu überdenken muss.

Der andere Faktor, der dies dringend macht: Sitecores Lizenzierungsmodell hat sich dramatisch verändert. Wenn du derzeit für Sitecore XP/XM On-Prem-Lizenzen zahlst, werden deine Verlängerungsbedingungen dich in Richtung XM Cloud drängen, egal ob du das willst oder nicht. Der Preisdruck allein macht ein Bleiben zunehmend teuer.

Der Sitecore XM Cloud Weg

Beginnen wir mit der offensichtlichen Option: folge Sitecores empfohlenem Upgrade-Weg zu XM Cloud.

Was du bekommst

XM Cloud ist Sitecores SaaS Headless CMS. Es kommt mit:

  • Ein neues SDK (Sitecore JavaScript Rendering SDK, der Nachfolger von JSS)
  • Built-in Support für Next.js als primäres Rendering-Framework
  • Sitecore Pages – ein visueller Page Builder für Content-Autoren
  • Verwaltetes Hosting und Infrastruktur
  • Integrationspunkte mit anderen Sitecore Composable-Produkten (CDP, Personalize, Search, etc.)

Was du verlierst

Hier ist, worüber Leute nicht genug sprechen:

  • xDB und Experience Analytics – XM Cloud enthält nicht die Analytics-Plattform von XP. Du wirst Sitecore CDP (separates Produkt, separate Lizenz) oder eine Third-Party-Analytics-Lösung benötigen.
  • Marketing-Automatisierung – EXM (Email Experience Manager) existiert nicht in XM Cloud. Du schaust auf Sitecore Send oder einen anderen ESP.
  • Benutzerdefinierte Pipeline-Prozessoren und Event Handler – Alle benutzerdefinierten C#-Codes, die in deinem Sitecore-Backend laufen? Sie müssen neu architekt oder ersetzt werden. XM Cloud ist SaaS – du kannst keinen benutzerdefinierten serverseitigen Code bereitstellen.
  • Preiskontrolle – Du wechselst von einem perpetuellen Lizenzmodell zu SaaS-Abonnement-Preisen. Für einige Organisationen ist dies eine Budget-Umstrukturierungsaufgabe, die Monate dauert, bis sie genehmigt wird.

Realistische XM Cloud-Migrationskosten

Basierend auf dem, was ich bei mehreren Enterprise-Migrationen 2024–2025 gesehen habe:

Komponente Geschätzter Kostenbereich Timeline
Discovery & Architektur $30.000 - $75.000 4–8 Wochen
Content Modeling & Migration $40.000 - $120.000 6–12 Wochen
Frontend Rebuild (Next.js SDK) $80.000 - $250.000 8–16 Wochen
Integration Überarbeitung $30.000 - $100.000 4–8 Wochen
QA & UAT $25.000 - $60.000 4–6 Wochen
XM Cloud Lizenz (jährlich) $100.000 - $250.000+ Fortlaufend

Diese Zahlen variieren stark je nach Website-Komplexität, Anzahl der Inhaltsitems und wie viel benutzerdefinierten Sitecore-Code du über die Jahre angesammelt hast. Eine einfache Marketing-Website könnte am unteren Ende landen. Ein Multi-Site-, Multi-Sprachen-Enterprise-Setup mit hoher Personalisierung? Budget für das obere Ende und addiere dann eine Reserve.

Wann XM Cloud Sinn macht

Bleibe bei Sitecore, wenn:

  • Dein Content-Team ist tief in die Sitecore-Authoring-Erfahrung trainiert
  • Du nutzt Sitecores Personalisierungsfunktionen intensiv und planst, Sitecore CDP zu adoptieren
  • Du hast eine große Sitecore-Partner-Beziehung und möchtest diese Investition beibehalten
  • Der Beschaffungsprozess deiner Organisation macht es einfacher, einen bestehenden Anbieter zu erweitern, als einen neuen zu integrieren

Sitecore JSS End of Life 2026: Migration Options Before June - architecture

Headless mit einem anderen CMS

Hier ist die Sache, die Sitecores Migrations-Dokumentation dir nicht sagen wird: Dieses EOL ist eine Gelegenheit. Wenn du frustriert über Sitecores Komplexität, Lizenzkosten oder Developer Experience warst, ist jetzt deine Chance, Alternativen zu evaluieren, ohne dass jemand fragt „warum wechseln wir?"

Die Antwort ist einfach: weil wir sowieso migrieren müssen.

Top Headless CMS Alternativen

Contentful ist seit Jahren das Standard-Enterprise-Headless-CMS. Starkes Content Modeling, gute APIs, ein reifes Ökosystem. Die Preisgestaltung beginnt bei etwa $300/Monat für kleine Teams, skaliert aber schnell – Enterprise-Pläne kosten $3.000–$5.000+/Monat. Ihr Compose-Produkt bietet einige der Page-Building-Funktionen, die deine Content-Autoren von Sitecore vermissen könnten.

Sanity ist mein persönlicher Favorit für Developer Experience. Der strukturierte Content-Ansatz, die GROQ-Absprache und die Echtzeit-Zusammenarbeitsfunktionen sind wirklich hervorragend. Ihr Preismodell basierend auf API-Nutzung statt Plätzen macht es im großen Maßstab vorhersagbarer. Pläne reichen von kostenlos (überraschend großzügig) bis zu benutzerdefinierter Enterprise-Preisgestaltung.

Storyblok verdient ernsthafte Überlegung, wenn dein Content-Team visuelles Editing benötigt. Ihr visueller Editor ist das nächstgelegene Äquivalent zu dem, was Sitecore Pages bietet, was den Übergang für nicht-technische Nutzer erleichtern kann. Die Preisgestaltung beginnt bei $106/Monat und geht bis zu benutzerdefinierten Enterprise-Ebenen.

Strapi ist die Open-Source-Option. Selbst gehostet, vollständig anpassbar, keine Pro-Seat-Lizenzierung. Wenn dein Team starke Backend-Entwickler hat und du volle Kontrolle willst, ist Strapi v5 überraschend fähig. Der Trade-off ist, dass du für Hosting, Skalierung und Sicherheit verantwortlich bist.

Hygraph (ehemals GraphCMS) ist stark, wenn dein Team in GraphQL denkt. Native Federation-Unterstützung macht es interessant für Organisationen mit verteilter Content-Ownership.

Wir haben Teams bei Migrationen zu mehreren dieser Plattformen durch unsere Headless-CMS-Entwicklungsdienste geholfen, und die richtige Wahl hängt völlig von deinem spezifischen Content-Modell, den Fähigkeiten deines Teams und deinen Budget-Einschränkungen ab.

CMS-Vergleich für Sitecore-Migrationen

Funktion Sitecore XM Cloud Contentful Sanity Storyblok Strapi
Visuelles Page Editing Ja (Pages) Begrenzt (Compose) Ja (Presentation) Ja (Visual Editor) Nein (Plugin erforderlich)
Content Modeling Flexibilität Mittel Hoch Sehr hoch Mittel Hoch
Developer Experience Mittel Gut Hervorragend Gut Gut
Content Author Experience Gut Mittel Mittel Hervorragend Mittel
Personalisierung eingebaut Via CDP Add-on Nein Nein Nein Nein
Multi-Site-Unterstützung Ja Ja (spaces) Ja (datasets) Ja (spaces) Ja (multi-tenant)
Geschätzte jährliche Kosten (Enterprise) $100K-$250K+ $36K-$60K+ $15K-$50K+ $15K-$36K+ Selbst-gehostete Kosten
Migrationskomplexität von Sitecore Hoch Mittel Mittel Mittel Mittel-Hoch

Frontend-Framework-Überlegungen

Hier wird die Migration aus technischer Perspektive interessant. Sitecore JSS unterstützte ursprünglich React, Angular, Vue und sogar React Native. In der Praxis sind 80%+ der JSS-Implementierungen, auf die ich gestoßen bin, React-basiert.

Wenn du migrierst, musst du also auch deinen Frontend-Stack wählen.

Next.js

Wenn du zu XM Cloud wechselst, verwendest du Next.js – es ist das einzig offiziell unterstützte Rendering-Framework. Aber auch wenn du Sitecore verlässt, ist Next.js eine starke Standard-Wahl.

Next.js 15 (stabil seit Ende 2024) mit dem App Router bietet dir Server Components, Streaming und ausgezeichnete Performance aus dem Kasten. Das Ökosystem ist massiv. Next.js-Entwickler zu finden ist relativ einfach im Vergleich zum Finden von Sitecore-Entwicklern.

Wir machen viel Next.js-Entwicklung für genau diese Art von Migration, und die Performance-Verbesserungen, die Teams sehen, wenn sie von Sitecore JSS kommen, sind normalerweise erheblich – 40–60% Verbesserungen bei Core Web Vitals-Scores sind üblich.

Astro

Wenn deine Sitecore-Website hauptsächlich inhaltsgesteuert ist (Marketing-Seiten, Dokumentation, Blogs) und keine schweren interaktiven Funktionen hat, verdient Astro ernsthafte Überlegung. Es liefert standardmäßig Null JavaScript und lässt dich React-, Vue- oder Svelte-Komponenten nur dort bringen, wo du Interaktivität brauchst.

Ich habe Astro-Websites sehen, die perfekte Lighthouse-Scores bei inhaltsreichen Seiten erreicht haben, die auf Sitecore JSS 60–70 bekamen. Der Unterschied ist dramatisch. Schau dir unsere Astro-Entwicklungsfähigkeiten an, wenn dieser Weg dich interessiert.

Remix / React Router v7

Remix (jetzt mit React Router verschmolzen) ist eine solide Wahl, wenn du Server-Side Rendering mit ausgezeichneter progressiver Enhancement willst. Es ist besonders gut für Form-schwere Anwendungen und Websites, wo du die beste mögliche Experience willst, auch wenn JavaScript ausfällt.

Planung deiner Migrations-Timeline

Hier ist eine realistische Timeline, wenn du in Q1 2025 startest und die Fertigstellung vor Juni 2026 anvisierst:

Phase 1: Discovery & Entscheidung (Wochen 1–8)

  • Überprüfe deine aktuelle Sitecore-Implementierung
  • Katalogisiere alle Content-Typen, Templates und Komponenten
  • Identifiziere Integrationen (CRM, ERP, Analytics, Marketing-Tools)
  • Evaluiere 2–3 CMS-Optionen mit Proof-of-Concept-Implementierungen
  • Erhalte Budget-Genehmigung (das dauert immer länger als du denkst)

Phase 2: Architektur & Content Modeling (Wochen 8–14)

  • Designe dein neues Content-Modell
  • Kartiere Sitecore-Templates zu neuen CMS-Content-Typen
  • Plane deine Component-Architektur
  • Richte CI/CD-Pipelines ein
  • Baue deine Content-Migrations-Skripte

Phase 3: Build (Wochen 14–30)

  • Implementiere deine Frontend-Komponenten
  • Baue API-Integrationen
  • Führe Content Migration aus (iterativ – versuche nicht, alles auf einmal zu machen)
  • Implementiere Personalisierung und Analytics
  • Richte Preview und Authoring Workflows ein

Phase 4: QA, Schulung & Launch (Wochen 30–40)

  • Vollständiges Regressions-Testing
  • Performance-Testing und Optimierung
  • Content-Author-Schulung
  • Gestaffelter Rollout (nach Website-Sektion oder Geographie, wenn Multi-Site)
  • DNS-Cutover und Überwachung

Das sind ungefähr 10 Monate. Wenn du später als Q1 2025 startest, musst du entweder die Timeline komprimieren (riskant) oder akzeptieren, dass du das Juni-2026-Datum möglicherweise überschreitest (handhabbar, aber nicht ideal).

Die versteckten Kosten, über die niemand spricht

Jede Migrationsschätzung, die ich je gesehen habe, unterschätzt drei Dinge:

Content Migration ist nie sauber

Dein Sitecore-Inhalt hat Jahre angesammelter Überreste. Verwaiste Items, duplizierte Templates, Felder, die vor fünf Jahren „temporär" hinzugefügt wurden. Migration von Inhalten ist nicht ein Lift-and-Shift – es ist eine Cleanup-Operation. Budget 20–30% mehr Zeit ein, als du für Content Migration denkst.

Personalisierungs-Schulden

Wenn du Sitecores Personalisierungsregeln nutzt, musst du herausfinden, wohin diese gehen. Die meisten Headless-CMS-Plattformen haben keine eingebaute Personalisierung. Du wirst ein separates Tool benötigen – ob das Sitecore CDP, Uniform, Ninetailed oder eine benutzerdefinierte Lösung ist. Und die Rekonstruktion deiner Personalisierungslogik ist zeitaufwändig, weil sie selten gut dokumentiert ist.

SEO-Risiko

Jede Migration trägt SEO-Risiko mit sich. URL-Strukturen ändern sich, Meta-Tags werden vergessen, Redirect-Maps haben Lücken. Ich habe Websites gesehen, die nach einer schlecht geplanten Migration 20–30% des organischen Traffic verloren haben. Baue eine vollständige URL-Kartierung früh auf und implementiere 301-Umleitungen, bevor du launchst. Überwache Search Console genau die ersten 90 Tage nach der Migration.

Team-Umschulung

Deine Content-Autoren kennen Sitecore. Sie haben Muscle Memory für den Experience Editor. Der Wechsel zu einem neuen CMS bedeutet Umschulung, und das bedeutet reduzierte Produktivität für Wochen. Unterschätze dies nicht – es ist nicht nur ein Kostenfaktor, es ist eine Change-Management-Herausforderung.

Wenn du dich von dem Umfang überwältigt fühlst, ist das normal. Zögere nicht, uns zu kontaktieren – wir haben mehrere Teams durch genau diese Art von Sitecore-Migration geleitet und können dir helfen, den richtigen Weg herauszufinden.

FAQ

Was ist genau das Sitecore JSS End-of-Life-Datum?

Sitecore JSS gebunden an Sitecore XP/XM On-Premise-Plattformen erreicht End of Life zusammen mit diesen Plattformen, wobei Juni 2026 der kritische Meilenstein ist. Nach diesem Datum endet die aktive Unterstützung und Sicherheitspatches für das Legacy JSS SDK. Sitecores successor SDK für XM Cloud ist ein separates Produkt, das ein XM Cloud-Abonnement erfordert.

Kann ich Sitecore JSS nach dem End-of-Life-Datum weiter ausführen?

Technisch ja. Deine Website wird nicht einfach nicht mehr funktionieren. Aber du erhältst keine Sicherheitsupdates, keine Bug-Fixes und keinen Support von Sitecore. Wenn eine kritische Sicherheitslücke im JSS Rendering Host oder Layout Service entdeckt wird, musst du sie selbst patchen. Für jede Organisation, die mit sensiblen Benutzerdaten umgeht, ist dies ein Compliance-Risiko, das schwer zu rechtfertigen ist.

Wie viel kostet es, von Sitecore JSS zu XM Cloud zu migrieren?

Die meisten Enterprise-Migrationen kosten zwischen $200.000 und $500.000+ je nach Komplexität, Anzahl der Websites, Content-Volumen und Integrationserfordernissen. Dies umfasst Discovery, Architektur, Entwicklung, Content-Migration, QA und Schulung. Die jährliche XM Cloud-Lizenzierung kostet normalerweise $100.000–$250.000+ zusätzlich zu den Migrationskosten.

Ist es billiger, zu einem anderen Headless CMS zu wechseln, als zu XM Cloud zu upgraden?

Oft ja – besonders bei laufenden Kosten. Plattformen wie Sanity, Contentful und Storyblok haben niedrigere jährliche Lizenzierungskosten als XM Cloud. Der Migrationsaufwand ist jedoch ähnlich oder etwas höher, weil du zu einer völlig anderen Content-Plattform wechselst, anstatt im Sitecore-Ökosystem zu bleiben. Die Gesamtkosteneffizienz über 3–5 Jahre spricht normalerweise für Nicht-Sitecore-Optionen für die meisten Organisationen.

Was passiert mit meinen Sitecore-Personalisierungsregeln, wenn ich migriere?

Wenn du zu XM Cloud wechselst, benötigst du Sitecore CDP und Sitecore Personalize (separate Produkte mit separaten Lizenzen), um Personalisierungsfähigkeiten zu replizieren. Wenn du zu einem anderen CMS wechselst, brauchst du eine Third-Party-Personalisierungsplattform wie Uniform, Ninetailed oder eine benutzerdefinierte Implementierung. Auf jeden Fall solltest du damit rechnen, deine Personalisierungsregeln von Grund auf zu rekonstruieren.

Welches Frontend-Framework sollte ich für meine Sitecore-Migration verwenden?

Next.js ist die häufigste Wahl und die einzige Option, wenn du zu XM Cloud wechselst. Für inhaltsreiche Websites mit minimaler Interaktivität bietet Astro überlegene Performance. Remix ist stark für Form-schwere Anwendungen. Wenn deine aktuelle JSS-Implementierung React-basiert ist (die meisten sind), bietet Next.js den reibungslosesten Übergang für dein Entwicklungsteam.

Wie lange dauert eine typische Sitecore JSS-Migration?

Plane für 8–12 Monate vom Kickoff bis zum Launch für eine Enterprise-Scale-Migration. Einfache Single-Site-Implementierungen könnten in 4–6 Monaten abgeschlossen sein. Multi-Site-, Multi-Sprachen-Setups mit komplexen Integrationen können 12–18 Monate dauern. Die Discovery- und Entscheidungsphase allein dauert normalerweise 6–8 Wochen, und das ist, bevor irgendwelche Entwicklungen beginnen.

Sollte ich warten, bis Sitecore erweiterte Unterstützung ankündigt, bevor ich migriere?

Zähle nicht darauf. Sitecores strategische Ausrichtung ist eindeutig auf XM Cloud ausgerichtet, und sie haben starke finanzielle Anreize, Kunden von Legacy-Plattformen zu bringen. Selbst wenn eine Form von erweit erter Unterstützung angeboten wird, wird sie wahrscheinlich mit Premium-Preisen kommen und wird keine neuen Funktionen oder proaktiven Sicherheitspatches enthalten. Das Starten deiner Migrations-Planung jetzt gibt dir Optionen; Warten nimmt dir Optionen weg.