Sitecore Content SDK 1.5: Why It's Time to Leave JSS Behind

Sitecore Content SDK 1.5: Why It's Time to Leave JSS Behind

If you've been following the evolution of the Sitecore headless SDK, you've probably noticed that the Content SDK has been moving fast since its stable 1.0 release back in July 2025. They've been releasing quite often, from 1.0 to 1.5 in just over six months, and each release has added something meaningful.

With version 1.5 now out, I think it's worth stepping back and putting the whole picture together: what the Content SDK actually is, why it's a genuine improvement over JSS, how the migration looks in practice, and what 1.5 specifically unlocks.

If you haven't read my previous posts on this topic, I'd recommend starting there:
SitecoreAI Content SDK v1.3.1: App Router is now GA! - Time to Make the Move where I covered the App Router GA milestone and why it matters for your architecture.

Let's dive in.

What the Content SDK Actually Is

The Content SDK is Sitecore's modern, purpose-built SDK for building headless applications on SitecoreAI. It replaces the JSS SDK for SitecoreAI (XM Cloud) implementations.

The key word here is purpose-built. JSS had to cover a lot of ground, such as XM, XP, headless, Experience Editor, multi-site, and it carried all of that weight in every project. The Content SDK strips it down to exactly what you need for SitecoreAI. Nothing more.

In practical terms, that means:

• One client to rule them all: The `SitecoreClient` class is the single entry point for everything such as layout data, dictionary, personalization, editing context. In JSS, this was spread across page-props-factory plugins, separate resolvers, middleware plugins, and scattered GraphQL utilities. Now it's one thing.
• One config, one CLI config: `sitecore.config.ts` handles runtime, `sitecore.cli.config.ts` handles build-time. The JSS `scripts/` folder with its `bootstrap.ts`, `generate-component-builder.ts`, `generate-plugins.ts` is gone entirely.
• Explicit component registration: Components are registered in `component-map.ts`. No more magic auto-discovery. You decide what gets exposed to SitecoreAI Pages.
• Composable middleware: `defineMiddleware` replaces the old plugin-chain approach. What runs, in what order, is now readable at a glance.
• No Experience Editor: Visual editing is done entirely through the SitecoreAI Page Builder using metadata-based integration. If you've been using EE, that needs a conversation before you migrate.

Why It's Better Than JSS for XM Cloud

Let's be honest, JSS is still solid, but there's something important you need to know before deciding how long to wait. JSS 22.x is officially in maintenance mode and will be deprecated in June 2026. That's confirmed in the official Sitecore documentation. From that date, it receives no new features, no enhancements, only critical bug fixes, dependency updates, and security patches until it goes dark. If you're running JSS on SitecoreAI, the migration is no longer a "when I'm ready" conversation. It's a timeline. With that context, here's why the Content SDK is genuinely better for XM Cloud.

• The project is smaller and cleaner: After migrating, the first thing you notice is that a big chunk of your project just disappears. The `scripts/` folder is gone. The plugin chains are gone. The config object is gone. What you're left with is a codebase that's much easier to onboard people to.
• The data layer makes sense: `SitecoreClient` gives you a coherent API surface. `scClient.getLayoutData()`, `scClient.resolveSite()`, `scClient.getDictionaryData()` it reads like what it does. In JSS, tracing where data came from was always an exercise.
• Middleware is explicit: If you've ever had to debug a middleware issue in JSS and wonder which plugin was interfering with which, `defineMiddleware` fixes that. The order is declared. The dependencies are visible.
• It's aligned with where Next.js is going: App Router is the default in Content SDK. That means you're building with React Server Components, server-first data fetching, and proper separation between client and server from day one. JSS was built around Pages Router. It works, but you're already rowing against the current.

The Migration: What You're Actually Changing

The official migration guides cover the path from JSS 22.8 through 22.10 to Content SDK. Here's what it actually involves from a hands-on perspective.

Note: Before starting, upgrade to JSS 22.8 minimum. That's the baseline the migration guides assume.

1. Packages: Replace `@sitecore-jss/sitecore-jss-nextjs` with `@sitecore-content-sdk/nextjs`. Remove the old CLI packages. Add `@sitecore/content-sdk-cli`.
2. Configuration consolidation: Move runtime values from the JSS `config` object into `sitecore.config.ts`. Move build-time scripts into `sitecore.cli.config.ts`. Then delete the `scripts/` folder, it's genuinely satisfying.
3. Environment variables: Several were renamed. The one that catches teams off guard: `DISABLE_SSG_FETCH=true` becomes `GENERATE_STATIC_PATHS=false`. The logic is inverted. Check your CI pipelines early.
4. Data fetching: The `page-props-factory` plugins go away. Their logic is replaced by `SitecoreClient` methods. Components using `getStaticProps` or `getServerSideProps` migrate to `getComponentServerProps`. If you need to branch on render mode, the `isServerSidePropsContext` helper is available.
5. Interface updates: `SitecoreContext` becomes `SitecoreProvider`. The `pageState`, `pageEditing`, `renderingType` properties are replaced by `page.mode` — a `PageMode` enum covering editing, preview, Design Studio, and normal delivery. Any conditional rendering logic that checks these needs to be updated.
6. Component map: Every component needs to be registered in `component-map.ts`. Treat this as an audit opportunity — you'll likely find components that haven't been used in production in over a year.
7. Experience Editor removal: If you're using EE, edit frames, chrome rendering, EE-specific scripts, those stop working. The SitecoreAI Page Builder replaces it using metadata-based integration. For most XM Cloud projects I've worked on, EE was already being deprecated. But if your editorial team still depends on it, align on that before you start the migration.

Watch Out For These

A few things the official guides don't flag loudly enough:

• SXA dependencies: If your JSS app uses SXA components or styling conventions, the migration surface area increases. Validate your SXA usage before you start and check the package structure changes carefully.
• Custom middleware: If you built custom JSS middleware plugins, you'll need to rewrite them as `defineMiddleware` compatible handlers. It's cleaner on the other side, but it's not a copy-paste job.
• Test suites: Any tests that mocked JSS-specific APIs or the old `page-props-factory` will need to be rewritten. If you're migrating to App Router at the same time, expect to rewrite a significant portion of your component tests.
• App Router as a separate concern: The SDK migration and the App Router migration are two different scopes. You can do them sequentially on the same branch, but scope them separately. Trying to do both at once on a large codebase is a recipe for pain.

What 1.5 Brings

Version 1.5 shipped on February 25, 2026, and the headline is App Router support for Design Studio.

If you've been reading my previous posts, you know App Router moved from beta to GA in v1.3.1. But there was still a gap: AI-generated variants from Design Studio couldn't be rendered correctly when your app was on App Router with server components. That gap is closed in 1.5.

The fix is a secure preview mechanism for server components in Design Studio. This means AI-generated variants now render correctly in App Router-based applications. If you were holding off on moving to App Router specifically because of Design Studio compatibility, that blocker is gone.

This matters more than it might sound. The whole point of Design Studio is AI-assisted component innovation. If your architecture didn't support it, you were leaving capability on the table. Now you don't have to choose between modern architecture and Design Studio.

On top of that, 1.5 also includes:

• A Next.js security vulnerability patch
• Removal of the beta label from App Router template files and paths, App Router is now just the default, no asterisk

The Content SDK GitHub repository is, as always, the most reliable source for the full changelog between versions.

Should You Migrate?

New project? Yes, without hesitation. Sitecore themselves have made this explicit: all new projects must use the Content SDK. JSS is not an option for new SitecoreAI implementations.

Existing JSS project, in "maintenance mode"? This framing is now misleading. JSS 22.x is the one in maintenance mode, not your project. It gets deprecated in June 2026. If you're on JSS today, you're not stable, you're on a countdown. The question isn't whether to migrate, it's when and how.

Existing JSS project with active feature work? Move now. Every sprint you spend on JSS is investment in something that's going away. And the longer you wait, the further behind you fall on Design Studio, the Agent API, and whatever Sitecore ships next all of which lands in Content SDK only.

The project structure you end up with after migrating is really simpler. That alone is worth something.

Resources

* Sitecore Content SDK Documentation
* JSS for SitecoreAI — Maintenance Mode & Deprecation Notice
* Upgrade JSS 22.8 to Content SDK 1.0
* Getting started with App Router using Content SDK
* Content SDK GitHub Repository
* My previous post: SitecoreAI Content SDK v1.3.1: App Router is now GA!