Sitecore Content SDK 2.0 is out! Should you upgrade?

What's changed, what matters, and whether it's worth upgrading right now

Sitecore Content SDK 2.0 is here, and this is not just a routine minor version bump. It changes the shape of the SDK, raises the runtime baseline, and makes Sitecore's direction a lot clearer. If you are building new headless projects on this platform, this release matters.

But the real question is whether it matters right now for your project.

Here's the short version:

• If you are starting on a new project, start on Content SDK 2.0
• If you are on 1.x and everything is stable, you probably do not need to rush
• If you want the cleaner package model and you are already planning a runtime upgrade, 2.0 is worth moving on to

What's new in Sitecore content SDK 2.0?

The biggest changes in this release aren't some new flashy AI features, rather it's the overall shape of the SDK. Compared with 1.5.x the SDK has been reorganized into something that feels much more intentional.

1. The Package Model is More Modular

In the 1.x line, the core package carried a lot of surface data.

By 2.0, the ecosystem is split more clearly into focused packages like:

• @sitecore-content-sdk/core
• @sitecore-content-sdk/content
• @sitecore-content-sdk/react
• @sitecore-content-sdk/nextjs
• @sitecore-content-sdk/events
• @sitecore-content-sdk/analytics-core
• @sitecore-content-sdk/personalize
• @sitecore-content-sdk/cli
• @sitecore-content-sdk/search

This matters because the old core package exposed a broad grab bag of concerns such as layout, media, i18n, site services, and personalization helpers.

In 2.0, that broad surface is no longer packed into core the same way. The result looks more like a modern SDK and less like a kitchen sink runtime.

1.x carried more in core. 2.0 splits responsibilities into more focused packages.

2. The Next.js integration has shifted toward proxy and route-handler patterns

The @sitecore-content-sdk/nextjs package also changes shape in a noticeable way.

In 1.5.x, a lot of the framework integration lived under middleware-oriented exports such as:

• Locale middleware
• Multisite middleware
• Redirects middleware
• Personalize middleware

In 2.0, there is a stronger emphasis on:

• Proxy
• Route-handler
• More focused middleware helpers

There are also explicit exports for things like:

• Proxy helpers
• Route handlers for editing, robots, and sitemap concerns
• Server actions
• Monitoring helpers
• Config helpers

That suggests a more deliberate fit with newer Next.js application patterns instead of leaning so heavily on one big middleware story.

3. The Platform baseline moved up

This is one of the biggest practical upgrade considerations. From the published package metadata:

• Content SDK 1.5.x targets Node ≥22
• Content SDK 2.0.x targets Node ≥24
• @sitecore-content-sdk/nextjs 1.5.x peers on Next ^15.5.9
• @sitecore-content-sdk/nextjs 2.0.x peers on Next ^16.0.0

If your app is not ready for Node 24 and Next 16, you are not really just upgrading the SDK, you are moving your runtime baseline too.

4. Analytics and personalization dependencies were cleaned up

In 1.5.x the ecosystem still leaned on @sitecore-cloudsdk/* peer dependencies for events and personalization.

In 2.0, those references have shifted to the Content SDK family itself:

• @sitecore-content-sdk/analytics-core
• @sitecore-content-sdk/events
• @sitecore-content-sdk/personalize

That is a quieter change, but an important one. It makes the SDK story feel more unified and less like multiple overlapping product lines bolted together.

5. There is now a clearer bootstrap and tooling story

The published packages now include:

• create-content-sdk-app
• @sitecore-content-sdk/cli

That is exactly what you want in a modern developer platform. If Sitecore wants Content SDK to be the front door for new builds, this is the right direction.

6. Improved Agent support, AI skills and other improvements

While the meat and potatoes of this upgrade revolves around upgrading dependencies and restructuring the architecture, there are some new features you may be excited about.

• Improved agent support with prepackaged AGENTS.md, Skills.md and .agents/skills folder
• Introduced a new integrated search package which provides a new SearchService with pagination, sorting and cancellation support
• Support for custom Edge hostnames
• Introduced the rewriteMediaUrls option to transform layout media URLs dynamically

Why you should consider upgrading

The best reason to upgrade is not fear, it's trajectory. If you're looking to bring your dependencies up to date, or start to truly leverage the power of AI tools this is a worthwhile upgrade.

Version 2.0 looks like the version Sitecore actually wants people to build on going forward.

Better alignment with where the platform is heading

The modular package split, the proxy and route-handler approach, and the updated dependency story all point in the same direction: a cleaner and more maintainable SDK.

If you keep building on 1.x forever, you are probably building on the branch that eventually gets left behind. While Sitecore has not officially stated when active support or maintenance ends for Content SDK 1.0, they have previously stated it would be between June 2026 and 12 months after the next major release. That leaves us with this:

Source: support.sitecore.com

A more coherent package ecosystem

The 1.x SDK still carried some transitional weight from the old days of JSS SDK. Whereas 2.0 feels more opinionated about its responsibilities.

• Core stays smaller
• Content concerns are separated
• Framework bindings are separated
• Analytics and personalization are aligned under the same family

That usually makes upgrades, maintenance, and onboarding less messy over time.

Better fit for newer next.js applications

If your team already wants to move to newer Next.js patterns anyways, or is already upgrading from JSS SDK to Content SDK, doing the Content 2.0 SDK upgrade as part of that work makes sense as you avoid doing two migration six months apart.

Is it essential to upgrade right now?

No, for most existing teams this does not look like an emergency update. If your current 1.x implementation is stable, shipping, and not blocked by missing functionality, there is no obvious reason to stop everything and rush to 2.0. This is especially true if:

• You are standardized on Node 22 today
• You are not ready for Next 16 yet
• Your current middleware setup works fine
• You have custom integrations built around the 1.x package layout

In other words, while 2.0 looks important, it does not necessarily look urgent. If 1.x is doing the job, there is nothing wrong with planning this upgrade properly instead of treating it like a fire drill.

How much effort is this upgrade?

This depends heavily on how deep your current implementation goes. But for most teams, I would put this somewhere between a moderate upgrade and a significant one.

Low Effort: relatively simple consumers

If your app:

• Uses the SDK in a fairly standard way
• Has limited customization
• Is already close to the required Node and Next.js versions
• Does not heavily depend on old middleware patterns

Then the work is pretty manageable.

In this case the upgrade mostly requires:

• Bumping up runtime versions
• Updating package names and dependencies
• Adjusting imports
• Fixing any breaking API changes
• Regression testing editing, routing, redirects and personalization

Medium Effort: typical production implementations

This is probably where most teams will land.

If you have a real production app with custom middleware behaviour, multisite logic, redirects, personalization, or editing integration, expect some refactoring. Because the exported surface has changed in meaningful ways.

A 1.5.x codebase likely references patterns and modules that either moved, shrank, or were replaced by newer proxy and route-handler oriented APIs.

That means you are not just changing versions, you are revisiting how the app is wired together.

Higher Effort: heavily customized or older codebases

If your implementation has accumulated custom wrappers, special routing logic, edge cases around Experience Editor integration, or a lot of platform-specific assumptions, the upgrade could be substantial.

A practical way to think about the migration

If you are evaluating the move from 1.x to 2.0, I would frame it like this.

Upgrade soon if:

• You are starting a new implementation
• You already want Node 24 and Next 16
• You want to align with Sitecore's forward-looking SDK model
• Your current app is still early enough that refactoring is cheap

Wait a bit if:

• Your production app is stable and busy doing actual business work
• Your team is not ready to move the runtime baseline yet
• You need more migration guidance or examples from Sitecore first
• Your current 1.x implementation is deeply customized

A simple way to decide whether to upgrade now, later, or as part of a larger platform refresh.

Final take

Sitecore Content SDK 2.0 looks like a meaningful release. It modernizes the package structure, tightens up the platform story, and makes the framework integration feel more intentional.

For new builds it's the clear starting point. But if you already have a working 1.x production implementation, do not treat this as a drop-everything upgrade. Treat it as a roadmap item, and take the time to plan it out properly and align it with broader platform or dependency updates, not necessarily as a standalone initiative.