Important: JSS SDK Users

If you’re currently running Sitecore JSS SDK, end of support is June 2026, you cannot migrate directly to Content SDK 2.0. The two frameworks have fundamentally different architectures and are not compatible. A migration from JSS to Content SDK requires significant refactoring and architectural changes.

If you’re on JSS SDK and considering an upgrade path, reach out to me I’m happy to discuss migration strategies and timelines specific to your implementation.

Introduction

Sitecore Content SDK 2.0, announced in March 2026, represents a major rethinking of how developers build SitecoreAI applications. This isn’t an incremental update—it’s a shift toward a more modern, composable, and AI-aware development model that aligns with where digital experience platforms are heading.

If you’re currently running Content SDK 1.x, this release deserves careful evaluation. The changes are meaningful enough that upgrading should be treated as an architectural decision—not a routine version bump.

What’s Content SDK 2.0?

Content SDK 2.0 is a Next.js/React framework purpose-built for building SitecoreAI applications. It goes beyond simple content delivery and introduces a more opinionated structure for composing experiences that are:

  • AI-assisted
  • Editor-driven
  • API-first
  • Edge-aware

Rather than acting as a thin abstraction over content APIs, the SDK brings multiple concerns—content, analytics, personalization, and search—into a more unified developer experience.

A key shift in 2.0 is the move toward a more decoupled and modular architecture, enabling teams to adopt only the capabilities they need while aligning with modern frontend and edge delivery patterns.

Major New Features

Agent Support and AI Skills

One of the most notable directions in Content SDK 2.0 is the introduction of AI-assisted development patterns, including early support for defining agent-like capabilities within your project.

This includes conventions such as:

  • Project-level configuration for AI-assisted workflows (e.g., AGENTS.md)
  • Structured directories for reusable capabilities (e.g., .agents/skills/)
  • CLI-assisted scaffolding for components and features
  • Guardrails for controlling when and how AI-assisted generation is used

These capabilities are designed to standardize how teams introduce AI into the development lifecycle—not just at runtime, but during implementation as well.

Consolidated Analytics, Events, and Personalization

Content SDK 2.0 moves toward a more unified model by consolidating functionality previously spread across multiple SDKs into focused packages:

  • @sitecore-content-sdk/analytics-core: Instrumentation and analytics foundations
  • @sitecore-content-sdk/events: Event tracking and subscription patterns
  • @sitecore-content-sdk/personalize: Personalization integration

This reduces the need for separate integrations and simplifies initialization through a more streamlined setup pattern (e.g., initContentSdk), significantly lowering boilerplate.

Integrated Search Capabilities

A new @sitecore-content-sdk/search package introduces a more structured approach to search:

  • SearchService for executing queries with pagination and sorting
  • Support for managing long-running requests (e.g., cancellation patterns)
  • React hooks like useSearch and useInfiniteSearch

This brings search closer to a first-class concern within the SDK, rather than something implemented separately per project.

Cached Components

One of the most impactful additions in Content SDK 2.0 is native support for component-level caching.

Instead of treating caching as a page-level concern, developers can now define caching strategies at the component level—unlocking much more granular performance control.

Why Cached Components Matter:

  • Performance: Reduce rendering time by caching expensive components
  • Scalability: Better handle traffic spikes without linear infrastructure scaling
  • Cost efficiency: Fewer renders mean lower compute usage
  • Editor experience: Changes invalidate only affected components, not entire pages

Cache Strategies Available:

  • Request-level caching: Scoped to a single request lifecycle
  • Time-based invalidation: TTL-based expiration
  • Tag-based invalidation: Selective cache busting based on data dependencies
  • ISR-style revalidation: Background refresh without blocking responses

Real-world impact: It’s not uncommon to see substantial performance improvements when caching is applied selectively—for example, reducing render times on component-heavy pages by more than 50%, depending on composition and data dependencies.

This becomes especially valuable in multi-tenant and high-traffic environments where predictable performance is critical.

Modern Framework Stack

Content SDK 2.0 aligns with modern frontend and runtime ecosystems, including:

  • Support for newer Next.js App Router patterns
  • Compatibility with recent Node.js runtimes
  • Improved support for edge-based deployments
  • Configuration options such as SITECORE_EDGE_PLATFORM_HOSTNAME
  • Enhancements like rewriteMediaUrls for flexible media delivery

Rather than focusing on specific version numbers, the emphasis is on staying aligned with the evolving React and Next.js ecosystem.

Breaking Changes (You Must Handle These)

Decoupled Package Architecture

One of the most significant changes is the move to a fully decoupled package model.

For example:

  • @sitecore-content-sdk/content is no longer tightly coupled to @sitecore-content-sdk/core

This introduces:

  • Modular usage: Import only what your application needs
  • Independent versioning: Packages evolve separately
  • Refactoring requirements: Existing projects using monolithic imports will need updates

If your implementation relies on wildcard imports or deep package internals, expect breaking changes.

Next.js File Structure Changes

As the SDK aligns more closely with modern Next.js patterns, some structural updates may be required:

  • Updates to middleware and routing patterns based on newer Next.js conventions
  • Migration from legacy image configuration (images.domains) to newer approaches like remotePatterns
  • Validation of tsconfig.json / jsconfig.json path mappings

These changes are largely driven by the underlying framework rather than the SDK itself.

React 19 Refactor

Content SDK 2.0 adopts newer React patterns, resulting in internal architectural changes:

  • Movement toward hook-based APIs over higher-order components
  • Updates to provider patterns (e.g., SitecoreProvider)
  • Greater alignment with modern React features like streaming and concurrent rendering

If your implementation relies heavily on older abstractions (e.g., HOCs), expect some refactoring.

Redirect and Locale Logic

Default redirect behavior has been simplified, which may impact multilingual implementations:

  • Redirects may default to a base locale rather than preserving context
  • Custom redirect logic may need to explicitly handle language scenarios

For multi-site or multi-language setups, this should be reviewed carefully—especially from an SEO perspective.

What Stayed the Same

Despite the changes, several core concepts remain stable:

  • Content querying patterns are largely consistent
  • Layout-driven rendering still underpins the experience model
  • Headless architecture remains fully decoupled from the CMS

This continuity helps reduce the learning curve, even as the framework evolves.

When to Upgrade

Upgrade to 2.0 if:

  • You’re starting a new SitecoreAI project and want a modern foundation
  • You plan to incorporate AI-assisted development workflows
  • You want a more unified approach to analytics, events, and personalization
  • You’re already aligning with newer Next.js and React patterns

Hold off if:

  • You have a stable 1.x implementation with no immediate need to evolve
  • Your solution is tightly coupled to older package structures
  • You lack the bandwidth for moderate-to-high migration effort