Sitecore JSS endet Juni 2026: Ihre Migrations-Optionen
Ihr Deploy läuft durch. Ihr Marketing-Team veröffentlicht eine Kampagne. Dann — 11 Monate später — kommt ein Sitecore-Support-Ticket mit einer einzigen Zeile zurück: "JSS hat end of life Juni 2026 erreicht. Keine weiteren Patches." Sie haben 18 Monate Zeit, bevor Security-Patches aufhören, bevor Ihre CDN-Integration beim nächsten Node-Upgrade bricht, bevor Ihr Content-Team in einem CMS eingesperrt ist, das keine Fixes mehr bereitstellt. Die Rechnung ist eng: Discovery dauert 6–8 Wochen, Vendor-Demos weitere 4, Content-Migration 10–14 Wochen, wenn Ihre Taxonomie sauber ist (ist sie nicht). Das lässt 2–3 Monate Spielraum vor Juni 2026. XM Cloud möchte, dass Sie in der Sitecore-Familie bleiben. Contentful und Sanity wollen Ihre API-Aufrufe. Strapi möchte, dass Sie Ihr Schema besitzen. Jeder Weg löst ein anderes Problem — aber nur, wenn Sie jetzt mit der Planung beginnen.
Ich habe genug Enterprise-CMS-Migrationen durchlaufen, um zu wissen, dass die Planungsphase allein die meisten Teams 3–6 Monate in Anspruch nimmt. Die tatsächliche Migration? Weitere 3–6 Monate für alles Nichttriviale. Wenn Sie das also Anfang 2026 lesen, sind Sie nicht früh dran — Sie sind pünktlich. Wenn Sie das später lesen... müssen Sie gestern beginnen.
Lassen Sie uns aufschlüsseln, was wirklich passiert, welche Optionen Sie haben, und wie Sie eine Entscheidung treffen, die Ihr Team nicht in Panik versetzt.
Inhaltsverzeichnis
- Was wirklich mit Sitecore JSS passiert
- Warum das wichtiger ist als ein typisches EOL
- Der Sitecore XM Cloud-Weg
- Headless mit einem anderen CMS
- Vergleich der Migrationspfade
- Überlegungen zum Frontend-Framework
- Planung Ihrer Migrations-Zeitleiste
- Die versteckten Kosten, über die niemand spricht
- FAQ

Was wirklich mit Sitecore JSS passiert
Sitecore verfolgt seit einigen Jahren aggressiv seine Composable-DXP-Strategie. Die On-Premise- und Self-Hosted-Sitecore XP/XM-Plattformen, für die JSS entwickelt wurde, werden zugunsten von Sitecore XM Cloud — ihrem SaaS-Angebot — eingestellt.
Hier ist die Zeitleiste, die zählt:
- Sitecore XP 10.x tritt 2026 in den End of Mainstream Support ein
- JSS SDK-Versionen gebunden an XP/XM On-Prem verlieren aktive Entwicklung und Security-Patches
- Juni 2026 ist das Schlüsseldatum, bei dem Extended-Support-Bedingungen erheblich verschoben werden
- Sitecore XM Cloud wird die einzige aktiv entwickelte Sitecore-Headless-Plattform in Zukunft
Was "end of life" in praktischer Hinsicht bedeutet: keine neuen Features, keine proaktiven Security-Patches und eventually keine beantworteten Support-Tickets. Ihre Site wird am 30. Juni nicht aufhören zu funktionieren. Aber wenn etwas kaputt geht — eine Sicherheitslücke, ein Kompatibilitätsproblem mit einem neuen Browser, ein Node.js-Versionkonflikt — sind Sie auf sich allein gestellt.
Ich habe Teams gesehen, die versucht haben, EOL-Plattformen auszusitzen. Es funktioniert eine Weile. Dann funktioniert es echt, echt nicht mehr.
Warum das wichtiger ist als ein typisches EOL
Das ist nicht wie ein Upgrade von React 17 auf React 18, bei dem Sie ein paar Abhängigkeiten erhöhen und ein paar Breaking Changes über ein Wochenende beheben. Sitecore JSS ist tief an das Sitecore-Backend gekoppelt. Der Layout Service, der Content Resolver, die Rendering-Host-Architektur — alles ist spezifisch dafür, wie Sitecore Inhalte zu Ihrem JavaScript-Frontend bereitstellt.
Wenn JSS EOL geht, verlieren Sie nicht nur einen Frontend SDK. Sie verlieren die gesamte Brücke zwischen Ihrem Content und Ihrer Präsentationsschicht. Das bedeutet, dass jeder Migrationspfad erfordert, beide Seiten dieser Gleichung zu überdenken.
Der andere Faktor, der dies dringend macht: Sitecore's Lizenzierungsmodell hat sich dramatisch geändert. Wenn Sie derzeit für Sitecore XP/XM On-Prem-Lizenzen bezahlen, werden Ihre Erneuerungsbedingungen Sie in Richtung XM Cloud drücken, ob Sie das wollen oder nicht. Allein der Preisdruck macht Stillstand zunehmend teuer.
Der Sitecore XM Cloud-Weg
Lassen Sie uns mit der offensichtlichen Option beginnen: Folgen Sie Sitecore's empfohlenem Upgrade-Pfad zu XM Cloud.
Was Sie bekommen
XM Cloud ist Sitecore's SaaS-Headless-CMS. Es kommt mit:
- Einem neuen SDK (Sitecore JavaScript Rendering SDK, der Nachfolger von JSS)
- Eingebauter Unterstützung 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 Sie verlieren
Hier ist, was die Leute nicht genug diskutieren:
- xDB und Experience Analytics — XM Cloud enthält nicht die Analytics-Plattform von XP. Sie benötigen Sitecore CDP (separate Produkt, separate Lizenz) oder eine Drittanbieter-Analytics-Lösung.
- Marketing Automation — EXM (Email Experience Manager) existiert nicht in XM Cloud. Sie schauen auf Sitecore Send oder einen anderen ESP.
- Benutzerdefinierte Pipeline-Prozessoren und Event Handler — All dieser benutzerdefinierte C#-Code, der in Ihrem Sitecore-Backend läuft? Er muss neu konzipiert oder ersetzt werden. XM Cloud ist SaaS — Sie können keinen benutzerdefinierten Server-seitigen Code bereitstellen.
- Preiskontrolle — Sie wechseln von einem perpetuellen Lizenzmodell zu SaaS-Abonnementpreisen. Für einige Organisationen ist dies eine Budgetumstrukturierungsübung, die Monate dauert, bis sie genehmigt wird.
Realistische XM Cloud Migrations-Kosten
Basierend auf dem, was ich in mehreren Enterprise-Migrationen durch 2026 gesehen habe:
| Komponente | Geschätzter Kostenbereich | Zeitleiste |
|---|---|---|
| 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 Rework | $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+ | Laufend |
Diese Zahlen variieren stark je nach Site-Komplexität, Anzahl der Content-Items und wie viel benutzerdefinierten Sitecore-Code Sie im Laufe der Jahre angehäuft haben. Eine einfache Marketing-Site könnte am unteren Ende landen. Ein Multi-Site-, Multi-Sprachen-Enterprise-Setup mit starker Personalisierung? Budget für das obere Ende und addieren Sie dann eine Eventualrücklage.
Wenn XM Cloud sinnvoll ist
Bleiben Sie bei Sitecore, wenn:
- Ihr Content-Team tief in der Sitecore Authoring Experience trainiert ist
- Sie Sitecore's Personalisierungsfeatures stark nutzen und planen, Sitecore CDP zu übernehmen
- Sie eine große Sitecore-Partner-Beziehung haben und diese Investition bewahren möchten
- Sitecore's Beschaffungsprozess Ihrer Organisation es einfacher macht, einen bestehenden Vendor zu erweitern, als einen neuen zu integrieren

Headless mit einem anderen CMS
Hier ist die Sache, die Sitecore's Migrations-Docs Ihnen nicht sagen wird: Dieses EOL ist eine Gelegenheit. Wenn Sie mit Sitecore's Komplexität, Lizenzierungskosten oder Developer Experience frustriert waren, ist dies Ihre Chance, Alternativen zu evaluieren, ohne dass jemand fragt "warum wechseln wir?"
Die Antwort ist einfach: weil wir ohnehin migrieren müssen.
Top Headless CMS-Alternativen
Contentful ist seit Jahren das Standard-Enterprise-Headless-CMS. Starke Content-Modellierung, gute APIs, ein reifes Ökosystem. Die Preisgestaltung beginnt bei etwa $300/Monat für kleine Teams, skaliert aber schnell — Enterprise-Pläne laufen bei $3.000-$5.000+/Monat. Ihr Compose-Produkt bietet einige der Page-Building-Funktionen, die Ihre Content-Autoren von Sitecore vermissen könnten.
Sanity ist mein persönlicher Favorit für Developer Experience. Der Structured-Content-Ansatz, die GROQ-Abfragesprache und die Real-Time-Kollaborationsfunktionen sind wirklich ausgezeichnet. Ihr Preismodell basierend auf API-Nutzung anstelle von Sitzen macht es in großem Maßstab vorhersehbarer. Die Pläne reichen von kostenlos (überraschend großzügig) bis zu Custom-Enterprise-Preisen.
Storyblok ist einen genauen Blick wert, wenn Ihr Content-Team visuelles Editing braucht. Ihr Visual Editor kommt dem, das Sitecore Pages bietet, am nächsten, was den Übergang für nicht-technische Benutzer erleichtern kann. Die Preisgestaltung beginnt bei $106/Monat und geht bis zu Custom-Enterprise-Stufen.
Strapi ist die Open-Source-Option. Self-Hosted, vollständig anpassbar, keine pro-Sitz-Lizenzierung. Wenn Ihr Team starke Backend-Entwickler hat und Sie volle Kontrolle wollen, ist Strapi v5 überraschend fähig. Der Nachteil ist, dass Sie für Hosting, Skalierung und Sicherheit verantwortlich sind.
Hygraph (ehemals GraphCMS) ist stark, wenn Ihr Team in GraphQL denkt. Die native Federation-Unterstützung macht es interessant für Organisationen mit verteiltem Content-Besitz.
Wir haben Teams durch Migrationen zu mehreren dieser Plattformen geholfen über unsere Headless CMS Development Services, und die richtige Wahl hängt ganz von Ihrem spezifischen Content-Modell, den Fähigkeiten Ihres Teams und den Budget-Einschränkungen ab.
CMS-Vergleich für Sitecore-Migrationen
| Feature | Sitecore XM Cloud | Contentful | Sanity | Storyblok | Strapi |
|---|---|---|---|---|---|
| Visuelles Page Editing | Ja (Pages) | Begrenzt (Compose) | Ja (Presentation) | Ja (Visual Editor) | Nein (Plugin nötig) |
| Content Modeling Flexibilität | Mittel | Hoch | Sehr Hoch | Mittel | Hoch |
| Developer Experience | Mittel | Gut | Ausgezeichnet | Gut | Gut |
| Content Author Experience | Gut | Mittel | Mittel | Ausgezeichnet | Mittel |
| Personalisierung Eingebaut | Via CDP Add-On | Nein | Nein | Nein | Nein |
| Multi-Site Support | Ja | Ja (Spaces) | Ja (Datasets) | Ja (Spaces) | Ja (Multi-Tenant) |
| Geschätzte jährliche Kosten (Enterprise) | $100K-$250K+ | $36K-$60K+ | $15K-$50K+ | $15K-$36K+ | Self-Hosted Kosten |
| Migrationskomplexität von Sitecore | Hoch | Mittel | Mittel | Mittel | Mittel-Hoch |
Überlegungen zum Frontend-Framework
Hier wird die Migration aus einer Engineering-Perspektive interessant. Sitecore JSS unterstützte ursprünglich React, Angular, Vue und sogar React Native. In der Praxis sind 80%+ der JSS-Implementierungen, denen ich begegnet bin, React-basiert.
Also wenn Sie migrieren, müssen Sie auch Ihren Frontend-Stack auswählen.
Next.js
Wenn Sie zu XM Cloud wechseln, nutzen Sie Next.js — es ist die einzige offiziell unterstützte Rendering-Plattform. Aber auch wenn Sie Sitecore verlassen, ist Next.js eine starke Standard-Wahl.
Next.js 15 (stabil ab Ende 2024) mit dem App Router gibt Ihnen Server Components, Streaming und hervorragende Leistung direkt ab der Stange. Das Ökosystem ist massiv. Next.js-Entwickler zu finden ist relativ unkompliziert im Vergleich zu Sitecore-Entwicklern zu finden.
Wir machen viel Next.js Development für genau diese Art von Migration, und die Leistungsverbesserungen, die Teams nach Sitecore JSS sehen, sind normalerweise bedeutsam — 40-60% Verbesserungen in Core Web Vitals Scores sind üblich.
Astro
Wenn Ihre Sitecore Site hauptsächlich inhaltsgesteuert ist (Marketing-Seiten, Dokumentation, Blogs) und keine schweren interaktiven Features hat, verdient Astro ernsthafte Überlegung. Es liefert standardmäßig null JavaScript und lässt Sie React-, Vue- oder Svelte-Komponenten nur dort bringen, wo Sie Interaktivität brauchen.
Ich habe Astro-Sites gesehen, die perfekte Lighthouse-Scores auf inhaltsreichen Seiten erreichen, die auf Sitecore JSS bei 60-70 punkteten. Der Unterschied ist dramatisch. Schauen Sie sich unsere Astro Development Fähigkeiten an, wenn dieser Weg Sie interessiert.
Remix / React Router v7
Remix (jetzt mit React Router verschmolzen) ist eine solide Wahl, wenn Sie Server-Side Rendering mit hervorragender Progressive Enhancement wollen. Es ist besonders gut für formularintensive Anwendungen und Sites, wo Sie die beste mögliche Erfahrung mögen, auch wenn JavaScript fehlschlägt.
Planung Ihrer Migrations-Zeitleiste
Hier ist eine realistische Zeitleiste, wenn Sie in Q1 2026 beginnen und vor Juni 2026 abschließen möchten:
Phase 1: Discovery & Entscheidung (Wochen 1-8)
- Führen Sie ein Audit Ihrer aktuellen Sitecore-Implementierung durch
- Katalogisieren Sie alle Content-Typen, Templates und Components
- Identifizieren Sie Integrationen (CRM, ERP, Analytics, Marketing Tools)
- Evaluieren Sie 2-3 CMS-Optionen mit Proof-of-Concept-Implementierungen
- Erhalten Sie Budget-Genehmigung (das dauert immer länger als gedacht)
Phase 2: Architektur & Content Modeling (Wochen 8-14)
- Entwerfen Sie Ihr neues Content-Modell
- Mappen Sie Sitecore-Templates zu neuen CMS-Content-Typen
- Planen Sie Ihre Component-Architektur
- Richten Sie CI/CD-Pipelines ein
- Erstellen Sie Ihre Content-Migrations-Skripte
Phase 3: Build (Wochen 14-30)
- Implementieren Sie Ihre Frontend-Komponenten
- Bauen Sie API-Integrationen
- Führen Sie Content-Migration durch (iterativ — versuchen Sie nicht, alles auf einmal zu tun)
- Implementieren Sie Personalisierung und Analytics
- Richten Sie Preview- und Authoring-Workflows ein
Phase 4: QA, Training & Launch (Wochen 30-40)
- Vollständiges Regressions-Testing
- Performance-Testing und Optimierung
- Content-Author-Training
- Staged Rollout (nach Site-Bereich oder Geographie, wenn Multi-Site)
- DNS-Cutover und Monitoring
Das sind ungefähr 10 Monate. Wenn Sie später als Q1 2026 beginnen, müssen Sie entweder die Zeitleiste komprimieren (risiko) oder akzeptieren, dass Sie möglicherweise über Juni 2026 hinausgehen (handhabbar, aber nicht ideal).
Die versteckten Kosten, über die niemand spricht
Jede Migrations-Schätzung, die ich je gesehen habe, unterschätzt drei Dinge:
Content-Migration ist nie sauber
Ihr Sitecore-Content hat Jahre von angehäuftem Schrott. Verwaiste Items, duplizierte Templates, Felder, die vor fünf Jahren "vorübergehend" hinzugefügt wurden. Content-Migration ist kein Lift-and-Shift — es ist eine Cleanup-Operation. Budget 20-30% mehr Zeit als Sie denken für Content-Migration.
Personalisierungs-Schuld
Wenn Sie Sitecore's Personalisierungsregeln nutzen, müssen Sie herausfinden, wohin diese gehen. Die meisten Headless-CMS-Plattformen haben keine eingebaute Personalisierung. Sie benötigen ein separates Tool — sei es Sitecore CDP, Uniform, Ninetailed oder eine benutzerdefinierte Lösung. Und das Nachbilden Ihrer Personalisierungslogik ist zeitaufwändig, weil es selten gut dokumentiert ist.
SEO-Risiko
Jede Migration trägt SEO-Risiko. URL-Strukturen ändern sich, Meta-Tags werden übersehen, Umleitungsmaps haben Lücken. Ich habe Sites gesehen, die 20-30% des organischen Traffics nach einer schlecht geplanten Migration verloren haben. Erstellen Sie eine vollständige URL-Zuordnung frühzeitig und implementieren Sie 301-Umleitungen, bevor Sie starten. Überwachen Sie Search Console genau für die ersten 90 Tage nach der Migration.
Team-Umschulung
Ihr Content-Autoren kennen Sitecore. Sie haben Muskelgedächtnis für den Experience Editor. Ein Wechsel zu einem neuen CMS bedeutet Umschulung, und das bedeutet reduzierte Produktivität für Wochen. Unterschätzen Sie das nicht — es ist nicht nur ein Kostenfaktor, es ist eine Change-Management-Herausforderung.
Wenn Sie sich von dem Umfang dieses Vorhabens überwältigt fühlen, ist das normal. Fühlen Sie sich frei, uns zu kontaktieren — wir haben mehrere Teams durch genau diese Art von Sitecore-Migration geleitet und können Ihnen helfen, den richtigen Weg zu finden.
FAQ
Was ist genau das Sitecore JSS End-of-Life-Datum?
Sitecore JSS gebunden an Sitecore XP/XM On-Premise-Plattformen tritt zusammen mit diesen Plattformen in das End of Life ein, mit Juni 2026 als dem kritischen Meilenstein. Nach diesem Datum endet die aktive Unterstützung und Security-Patches für das Legacy-JSS-SDK. Sitecore's Nachfolger-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 weiterhin ausführen?
Technisch ja. Ihre Site wird nicht aufhören zu funktionieren. Aber Sie erhalten keine Security-Updates, keine Bug-Fixes und keinen Support von Sitecore. Wenn eine kritische Sicherheitslücke im JSS Rendering Host oder Layout Service entdeckt wird, müssen Sie diese selbst patchen. Für jede Organisation, die sensible Benutzerdaten verarbeitet, 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 laufen zwischen $200.000 und $500.000+ je nach Komplexität, Anzahl der Sites, Content-Volumen und Integrationserfordernisse. Dies umfasst Discovery, Architektur, Development, Content-Migration, QA und Training. Die jährliche XM Cloud-Lizenzierung kostet normalerweise zusätzlich zu Migrations-Kosten $100.000-$250.000+.
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. Allerdings ist der Migrations-Aufwand ähnlich oder leicht höher, weil Sie zu einer völlig anderen Content-Plattform wechseln, anstatt im Sitecore-Ökosystem zu bleiben. Die totale Ownership-Kosten über 3-5 Jahre begünstigen in der Regel Non-Sitecore-Optionen für die meisten Organisationen.
Was passiert mit meinen Sitecore-Personalisierungsregeln, wenn ich migriere?
Wenn Sie zu XM Cloud wechseln, benötigen Sie Sitecore CDP und Sitecore Personalize (separate Produkte mit separaten Lizenzen), um Personalisierungsfähigkeiten zu replizieren. Wenn Sie zu einem anderen CMS wechseln, benötigen Sie eine Drittanbieter-Personalisierungsplattform wie Uniform, Ninetailed oder eine benutzerdefinierte Implementierung. Wie dem auch sei, erwarten Sie, Ihre Personalisierungsregeln von Grund auf neu zu erstellen.
Welches Frontend-Framework sollte ich für meine Sitecore-Migration verwenden?
Next.js ist die häufigste Wahl und die einzige Option, wenn Sie zu XM Cloud wechseln. Für inhaltsreiche Sites mit minimaler Interaktivität bietet Astro überlegene Leistung. Remix ist stark für formularintensive Anwendungen. Wenn Ihre aktuelle JSS-Implementierung React-basiert ist (die meisten sind), bietet Next.js den reibungslosesten Übergang für Ihr Entwicklungsteam.
Wie lange dauert eine typische Sitecore JSS-Migration?
Planen Sie von Kickoff bis Launch für eine Enterprise-Scale-Migration 8-12 Monate ein. Einfache Single-Site-Implementierungen könnten in 4-6 Monaten abgeschlossen werden. 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 Development beginnt.
Sollte ich warten, bis Sitecore eine Extended Support ankündigt, bevor ich migriere?
Verlassen Sie sich nicht darauf. Sitecore's strategische Ausrichtung geht klar in Richtung XM Cloud, und sie haben starke finanzielle Anreize, Kunden von Legacy-Plattformen abzuwandern. Selbst wenn irgendeine Form von Extended Support angeboten wird, wird sie wahrscheinlich mit Premium-Preisen kommen und wird keine neuen Features oder proaktiven Security-Patches beinhalten. Die Planung Ihrer Migration jetzt zu beginnen gibt Ihnen Optionen; Abwarten nimmt Optionen weg.