Content SDK 2.0 is Here — Should You Move Your JSS App Now?
If you maintain a Sitecore front-end, the March 2026 Content SDK 2.0 release is one you should not ignore.
Sitecore shipped Content SDK 2.0 on March 19 as part of the SitecoreAI developer story. It requires Next.js 16 as a minimum. By the time you read this, most teams are at least talking about it.
The official line is that Content SDK is the recommended path forward for new SitecoreAI projects. That’s a polite way of saying: plan the move, or live with a stack Sitecore is no longer investing in to the same degree.
Here’s what’s actually changed, what to watch for, and what to check if you’re upgrading.
Why JSS Hit Its Ceiling
JSS has been around for years. It worked. Most teams shipped with it without thinking too hard about why their Next.js apps never quite felt like Next.js apps.
The reason is that JSS was built for XP and XM — server-rendered, on-prem, tied to the Sitecore request pipeline. When XM Cloud arrived, JSS got asked to bridge two completely different editing models: Experience Editor (server-coupled) and Page Builder (decoupled). One SDK, two editing contracts, and a Next.js app underneath.
Sitecore’s own developer portal acknowledges this — JSS apps tend to feel like a framework wrapped around Next.js rather than native Next.js apps. Content SDK is the fix.
The Real Changes in Content SDK 2.0
Looking at the March 19 release, four things stand out:
- Next.js 16 is the floor. No more 15.x. The upgrade work alone is non-trivial — Next.js 16 changed the caching model and shifted App Router behavior.
- App Router is the default story. Pages Router still works. But the design center has moved, and that’s where new docs and examples will live.
- Agent skills and
AGENTS.mdare now scaffolded in.create-content-sdk-appships.agents/skills/andSkills.mdpatterns with hard limits and stop conditions for AI coding tools. - Events, tracking, and personalization are integrated into the SDK instead of bolted on.
None of these are catastrophic on paper. But “supported” can still mean “behaves differently from what your JSS app assumed.”
Where Things Tend to Fail Silently
If you’re trying to validate a migration before rollout, these are the patterns I’d check first.
Custom components that relied on Experience Editor chrome injection or withSitecoreContext patterns won't always break loudly. They may just stop letting editors edit. Test the authoring side, not just the published one.
Custom field types and bespoke Layout Service extensions are the soft spot. The standard contracts carry forward. Anything you wrote yourself needs a closer look.
Anything that touches personalization is worth a second look. The SDK-level integration is new, and new integrations are where assumptions hide.
Get Priyanka Gulia’s stories in your inbox
Join Medium for free to get updates from this writer.
Next.js 16’s caching model will surface old habits around build-time data fetching. If your team last touched the data layer two years ago, expect surprises.
A Practical Pre-Flight Check
If your environment isn’t ready yet, here’s a sequence that catches most issues:
- Get to the latest JSS minor version and Next.js 15 first. Don’t migrate from a broken baseline.
- Inventory your Sitecore-specific integration points — Layout Service calls, GraphQL queries, personalization rules, Experience Editor customizations, custom field types.
- Scaffold a parallel Content SDK 2.0 app with
create-content-sdk-app. Don't migrate in place. - Run both apps against the same SitecoreAI tenant. Migrate one page at a time.
- Watch for changes in authoring behavior first, rendering second. The harder bug is usually in Page Builder, not the front-end.
- Set up
AGENTS.mdand.agents/skills/early if your team uses AI coding tools at all. Cheaper than auditing agent output later.
What I’d Actually Do This Week
If you’ve been busy with other work, the realistic plan is:
- List every component in your current JSS app.
- Sort by how much custom Experience Editor logic it has, not by how complex the UI looks.
- Scaffold a Content SDK 2.0 app and migrate the simplest three components first.
- Run them against a SitecoreAI sandbox.
- Document anything that changes, even if it doesn’t error.
You don’t need a full migration project this quarter. You need confidence that the five components your team actually depends on still do the right thing.
The Bigger Picture
Content SDK 2.0 is a small story with a larger lesson.
In the SaaS model, your dependencies upgrade on Sitecore’s schedule, not yours. The era of pinning a specific SDK version for three years is over. Apps that have run untouched since 2023 are now part of your active maintenance surface — whether you knew it or not.
The teams that handle this well treat custom front-end code the same way they treat any other code. Source control. Validation in lower environments. A short test suite for the critical ones.
That sounds heavy. In practice it’s a couple of hours of setup that saves a panicked Saturday.
Final Thoughts
Content SDK 2.0 is not a dramatic release. The changelog is short. The headline features are quiet.
But the shift in how it gets delivered — automatic, scheduled, non-optional — is exactly the kind of change that surprises teams who weren’t watching the docs.
If your app passes after the migration, great. You lose nothing by checking.
If it doesn’t, you’d much rather find out on a Tuesday afternoon in non-prod than from an editor who can’t publish.
