Key takeaways

  • Sitecore JSS's end of life landed in June 2026. Legacy JSS on XP/XM no longer gets security patches or support.
  • Staying inside the Sitecore ecosystem means migrating to XM Cloud. That means a new SDK, a new pricing model, and separate CDP/Personalize products for analytics and marketing automation.
  • Leaving Sitecore opens up Contentful, Sanity, Storyblok, and Strapi as headless alternatives. Each has different pricing, content modeling, and visual-editing tradeoffs.
  • A realistic migration, from discovery through launch, typically runs several months to a year. It depends on site complexity. Delaying now means running unpatched in production.
  • Next.js is the default frontend for XM Cloud migrations. Astro suits content-heavy sites that don't need heavy interactivity.

Updated 15 August 2026: sources added, experience claims checked against our project record, summary added.

Sitecore JSS End of Life 2026: Migration Options Before June

What's Actually Happening with Sitecore JSS

Sitecore has spent the past few years pushing its composable DXP strategy. The on-premise and self-hosted Sitecore XP/XM platforms that JSS was built on are being retired. Sitecore XM Cloud, Sitecore's SaaS offering, takes their place.

Here's the timeline that matters:

What "end of life" means in practical terms: no new features, no proactive security patches, and eventually no support tickets answered. Your site didn't stop working on June 30, 2026. But if something breaks, a security vulnerability, a compatibility issue with a new browser, a Node.js version conflict, you're on your own.

Organizations that try to ride out EOL platforms often manage for a while. Then something breaks, and there's no vendor left to call.

Why This Matters More Than a Typical EOL

This isn't like upgrading from React 17 to React 18, where you bump some dependencies and fix a few breaking changes over a weekend. Sitecore JSS is deeply coupled to the Sitecore backend. The layout service, the content resolver, and the rendering host architecture are all specific to how Sitecore serves content to your JavaScript frontend.

When JSS goes EOL, you're not just losing a frontend SDK. You're losing the entire bridge between your content and your presentation layer. Any migration path requires rethinking both sides of that equation.

The other factor that makes this urgent: Sitecore's licensing model has changed. If you're currently paying for Sitecore XP/XM on-prem licenses, your renewal terms will likely push you toward XM Cloud. You may not get much say in the timing. The pricing pressure alone makes staying put increasingly expensive.

The Sitecore XM Cloud Path

Let's start with the obvious option: follow Sitecore's recommended upgrade path to XM Cloud.

What You Get

XM Cloud is Sitecore's SaaS headless CMS. It comes with:

  • A new SDK (Sitecore JavaScript Rendering SDK, the successor to JSS)
  • Built-in support for Next.js as the primary rendering framework
  • Sitecore Pages, a visual page builder for content authors
  • Managed hosting and infrastructure
  • Integration points with other Sitecore composable products (CDP, Personalize, Search, and so on)

What You Lose

Here's what people don't talk about enough:

  • xDB and experience analytics. XM Cloud doesn't include the analytics platform from XP. You'll need Sitecore CDP (a separate product with a separate license) or a third-party analytics solution.
  • Marketing automation. EXM (Email Experience Manager) doesn't exist in XM Cloud. You're looking at Sitecore Send or another ESP.
  • Custom pipeline processors and event handlers. All that custom C# code running in your Sitecore backend needs to be rearchitected or replaced, because XM Cloud is SaaS and doesn't run your custom server-side code.
  • Pricing control. You're moving from a perpetual license model to SaaS subscription pricing. For some organizations, this becomes a budget restructuring exercise that takes months to get approved.

Realistic XM Cloud Migration Costs

Migration budgets vary widely by scope. Precise dollar figures rarely hold up across different projects. Here's a relative view of where the investment concentrates:

Component Relative Investment Timeline
Discovery & Architecture Low-Medium 4-8 weeks
Content Modeling & Migration Medium 6-12 weeks
Frontend Rebuild (Next.js SDK) Medium-High 8-16 weeks
Integration Rework Medium 4-8 weeks
QA & UAT Low-Medium 4-6 weeks
XM Cloud License (annual) High (custom enterprise pricing) Ongoing

Sitecore prices XM Cloud individually per contract. Get a current quote directly from Sitecore rather than relying on published averages.

Actual spend varies based on site complexity, the number of content items, and how much custom Sitecore code you've accumulated over the years. A simple marketing site sits at the low end of every row above. A multi-site, multi-language enterprise setup with heavy personalization sits at the high end, plus contingency.

When XM Cloud Makes Sense

Stay on Sitecore if:

  • Your content team is deeply trained on the Sitecore authoring experience
  • You're using Sitecore's personalization features heavily and plan to adopt Sitecore CDP
  • You have a large Sitecore partner relationship and want to maintain that investment
  • Your organization's procurement process makes it easier to expand an existing vendor than onboard a new one

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

Going Headless with a Different CMS

Here's the thing Sitecore's migration docs won't tell you: this EOL is an opportunity. Maybe your team has been frustrated with Sitecore's complexity, licensing costs, or developer experience. This is the chance to evaluate alternatives without anyone asking "why are we switching?"

The answer is simple: because you have to migrate anyway.

Top Headless CMS Alternatives

Contentful has been a default enterprise headless CMS choice for years. It offers strong content modeling, mature APIs, and a large ecosystem. Its published pricing starts with a free tier and scales through paid team and enterprise tiers priced individually. Its Compose product adds page-building capabilities that content authors may miss from Sitecore Pages.

Sanity stands out for developer experience: a structured content approach, the GROQ query language, and real-time collaboration. Its pricing model is based on API usage rather than seats, which makes costs more predictable at scale. Plans range from a free tier to custom enterprise pricing.

Storyblok is worth a serious look if the content team needs visual editing. Its visual editor is the closest match to what Sitecore Pages offers. That can ease the transition for non-technical users. Storyblok's plans start on a paid tier and scale to custom enterprise pricing.

Strapi is the open-source option: self-hosted, fully customizable, with no per-seat licensing. If your team has strong backend developers and wants full control, Strapi v5 is capable enough for most enterprise content models. The trade-off is that you own hosting, scaling, and security.

Hygraph (formerly GraphCMS) is strong if your team thinks in GraphQL. Native federation support makes it interesting for organizations with distributed content ownership.

Our headless CMS development services cover Contentful, Sanity, Storyblok, and Strapi work. The right choice depends entirely on your content model, team capabilities, and budget.

CMS Comparison for Sitecore Migrations

Feature Sitecore XM Cloud Contentful Sanity Storyblok Strapi
Visual Page Editing Yes (Pages) Limited (Compose) Yes (Presentation) Yes (Visual Editor) No (plugin needed)
Content Modeling Flexibility Medium High Very High Medium High
Developer Experience Medium Good Excellent Good Good
Content Author Experience Good Medium Medium Excellent Medium
Personalization Built-in Via CDP add-on No No No No
Multi-site Support Yes Yes (spaces) Yes (datasets) Yes (spaces) Yes (multi-tenant)
Estimated Annual Cost (Enterprise) High, custom Custom tier, pricing Usage-based, pricing Custom tier, pricing Self-hosted infrastructure only
Migration Complexity from Sitecore High Medium Medium Medium Medium-High

Frontend Framework Considerations

Here's where the migration gets interesting from an engineering perspective. Sitecore JSS originally supported React, Angular, Vue, and even React Native. Most production JSS implementations use React, since Sitecore's official samples and starter kits default to it.

So when you're migrating, you need to pick your frontend stack too.

Next.js

If you're moving to XM Cloud, you'll use Next.js. It's the only officially supported rendering framework. Even if you're leaving Sitecore entirely, Next.js remains a strong default choice.

Next.js 15 shipped with the App Router, server components, and streaming built in. The ecosystem is large. Finding Next.js developers is generally easier than finding Sitecore developers.

We build migrations like this as part of our Next.js development work. On our own SleepDr.com project, moving a legacy WordPress site to Next.js 15 and Payload CMS took the Lighthouse score from 35 to 94 (case study). Sitecore JSS sites carrying similar rendering overhead tend to see comparable gains once that layer is replaced.

Astro

Say your Sitecore site is mostly content-driven, such as marketing pages, documentation, or blogs, without heavy interactive features. Then Astro deserves serious consideration. It ships zero JavaScript by default and lets you bring in React, Vue, or Svelte components only where you need interactivity.

On our bdManagedIT project, moving a WordPress site to Astro, Sanity, and Netlify produced 95+ PageSpeed scores on zero-JS static pages (case study). Content-heavy Sitecore JSS pages carrying similar amounts of unnecessary client-side JavaScript can see a similar jump. Check out our Astro development capabilities if this path interests you.

Remix / React Router v7

Remix (now merged with React Router) is a solid choice if you want server-side rendering with strong progressive enhancement. It works particularly well for form-heavy applications and sites where you want a good experience even when JavaScript fails.

Planning Your Migration Timeline

June 2026 has already passed. If you haven't started migrating, you're now running JSS without vendor patches. That raises the stakes on every week of delay. The phases below apply whether you're mid-project or just getting started.

Phase 1: Discovery & Decision (Weeks 1-8)

  • Audit your current Sitecore implementation
  • Catalog all content types, templates, and components
  • Identify integrations (CRM, ERP, analytics, marketing tools)
  • Evaluate 2-3 CMS options with proof-of-concept implementations
  • Get budget approval (this always takes longer than you think)

Phase 2: Architecture & Content Modeling (Weeks 8-14)

  • Design your new content model
  • Map Sitecore templates to new CMS content types
  • Plan your component architecture
  • Set up CI/CD pipelines
  • Build your content migration scripts

Phase 3: Build (Weeks 14-30)

  • Implement your frontend components
  • Build API integrations
  • Run content migration iteratively; don't try to do it all at once
  • Implement personalization and analytics
  • Set up preview and authoring workflows

Phase 4: QA, Training & Launch (Weeks 30-40)

  • Full regression testing
  • Performance testing and optimization
  • Content author training
  • Staged rollout, by site section or by geography if multi-site
  • DNS cutover and monitoring

That's roughly 10 months end to end. If you're only starting now, compressing this timeline is possible but increases risk. Treat every extra week on unpatched JSS as added exposure. Prioritize security-sensitive integrations and public-facing forms first.

The Hidden Costs Nobody Talks About

Most migration estimates underestimate a few things.

Content Migration Is Never Clean

Your Sitecore content has years of accumulated cruft: orphaned items, duplicate templates, and fields that were added "temporarily" years ago. Migrating content isn't a lift-and-shift. It's a cleanup operation. Budget meaningfully more time than you think for content migration.

Personalization Debt

If you're using Sitecore's personalization rules, you need to figure out where those go. Most headless CMS platforms don't have built-in personalization. You'll need a separate tool, whether that's Sitecore CDP, Uniform, Ninetailed, or a custom solution. Recreating your personalization logic takes time because it's rarely well documented.

SEO Risk

Any migration carries SEO risk. URL structures change, meta tags get missed, and redirect maps have gaps. Poorly planned migrations can cause substantial organic traffic loss when these details slip. Build a complete URL mapping early and implement 301 redirects before you launch. Monitor Search Console closely for the first 90 days post-migration.

Team Retraining

Your content authors know Sitecore. They have muscle memory for the Experience Editor. Moving to a new CMS means retraining, and that means reduced productivity for weeks. Don't underestimate this: it's not just a cost, it's a change management challenge.

If the scope of this feels like a lot, that's normal. Feel free to reach out to us. We can help you scope the right migration path for your specific Sitecore setup.

FAQ

What exactly is the Sitecore JSS end of life date?

Sitecore JSS tied to Sitecore XP/XM on-premise platforms reached end of life in June 2026, alongside those platforms. Since then, active support and security patches for the legacy JSS SDK have stopped. Sitecore's successor SDK, built for XM Cloud, is a separate product requiring its own subscription.

Can I keep running Sitecore JSS after the end of life date?

Yes, technically. Your site keeps working, but you receive no security updates, no bug fixes, and no support from Sitecore. Any critical vulnerability in the JSS rendering host or layout service becomes your responsibility to patch immediately, without vendor help. For any organization handling sensitive user data, that's a compliance risk that's hard to justify.

How much does it cost to migrate from Sitecore JSS to XM Cloud?

Most enterprise migrations run into six figures overall, with total cost depending on complexity, number of sites, content volume, and integration requirements. This covers discovery, architecture, development, content migration, QA, and training, and annual XM Cloud licensing is priced separately and individually by Sitecore. Request a current quote directly from Sitecore rather than relying on published averages.

Is it cheaper to switch to a different headless CMS than to upgrade to XM Cloud?

Often, yes, especially on ongoing costs. Platforms like Sanity, Contentful, and Storyblok typically have lower annual licensing costs than XM Cloud. Migration effort is similar or slightly higher, though, since you're moving to a completely different content platform rather than staying inside the Sitecore ecosystem. The total cost of ownership over three to five years tends to favor non-Sitecore options for most organizations.

What happens to my Sitecore personalization rules when I migrate?

If you move to XM Cloud, you'll need Sitecore CDP and Sitecore Personalize (separate products with separate licenses) to replicate personalization capabilities. If you move to a different CMS, you'll need a third-party personalization platform like Uniform, Ninetailed, or a custom implementation. Either way, expect to rebuild your personalization rules from scratch.

Which frontend framework should I use for my Sitecore migration?

Next.js is the most common choice, and it's the only supported option if you're moving to XM Cloud. For content-heavy sites with minimal interactivity, Astro offers superior performance, while Remix suits form-heavy applications well. Your team's existing React experience often tips the decision between them. If your current JSS implementation is React-based, which most are, Next.js provides the smoothest transition for your development team.

How long does a typical Sitecore JSS migration take?

Plan for 8-12 months from kickoff to launch for an enterprise-scale migration. Simple single-site implementations might complete in 4-6 months, while multi-site, multi-language setups with complex integrations can take 12-18 months. The discovery and decision phase alone typically takes six to eight weeks, before development even starts.

Should I wait for Sitecore to announce extended support before migrating?

Don't count on it. Sitecore's strategic direction is clearly toward XM Cloud, and they have strong financial incentives to move customers off legacy platforms. Even if some form of extended support appears, it will likely carry premium pricing and skip new features or proactive security patches. Starting migration planning now keeps options open. Waiting takes options away.

Key takeaway:

Migrate now. JSS end of life landed in June 2026, and running unpatched means no security patches or vendor support.