Reading time: 7 min read
Sitecore Content SDK 2.0 is out! Should you upgrade?
The key changes, what they mean for you, and whether it's time to 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:
| SDK Version | Release | Release Date | Active Support Ends | Maintenance Ends (EOL) |
|---|---|---|---|---|
| JSS SDK 21.X | Deprecated | October 2022 | April 2024 | March 2025 |
| JSS SDK 22.X | Maintenance | April 2024 | July 2025 | June 2026 |
| Content SDK 1.X | Active | July 2025 | March 2026 | Min: June 2026 Max: March 2027 |
| Content SDK 2.X | Active | March 2026 | N/A | N/A |
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.