Sitecore JSS to Content SDK Migration
Your Sitecore front end still runs on JSS. Support has ended, no newer JSS version will support the platform, and every month you stay puts more distance between your build and the features you are paying for. We move you across — in sequenced phases, with the build green at every step, and without a content freeze.
What does not change
Worth establishing early, because it removes most of the perceived risk - and it is usually far more than stakeholders expect.
- No content freeze.
This is a front-end SDK migration. Authors keep working throughout.
- Sitecore itself is untouched.
Templates, renderings, placeholder settings and datasources stay exactly as they are.
- Serialization is unchanged.
Your sitecore.json, module files, YAML on disk and Sitecore CLI workflow all carry over.
- Your content model survives.
Field types, GraphQL queries and datasource shapes move across.
- Editors see no difference
in Sitecore Pages.
- Your rendering hosts and editing endpoints
keep the same shape.
How we run it
Ordered phases with a green build after each one. Not because the individual changes are hard, but because when something subtle breaks - and on this migration something subtle usually does - the commit history needs to tell you where.
Assessment
Codebase triage against the three paths, SDK surface inventory, middleware audit, risk register and a sequenced plan with a defensible estimate.
Packages and imports
The largest volume of change and the lowest risk. Isolated in its own commit so every later diff stays readable.
Middleware becomes proxy
Renamed, re-exported and reordered against Next.js 16 - plus porting whatever custom routing logic you have accumulated.
Analytics and personalization
Cloud SDK packages replaced by the Content SDK plugin model, carrying across cookie-domain and editing-mode behaviour that the guides do not mention. Verified against real event data.
Experience Editor removal
Chromes support is gone. This code deletes rather than migrates.
Next.js 16 and React 19 fallout
Static-to-dynamic routes, caching model decisions, client boundaries and the hook changes across your component library.
Tooling and regression
The sitecore-tools CLI, component and import maps, then full regression in Pages across every site and a representative set of locales.
Handover
Documentation, a short enablement session, and an optional support period while your team settles in.
Why AHD Solutions
- We run Content SDK in production.
Not a lab exercise - a live multi-site XM Cloud platform across 21 locales, four applications behind one domain.
- We have done the hard version of this.
Custom edge middleware, a legacy-platform proxy, path-based multisite routing and headless personalization. The parts no migration guide covers.
- Sitecore Silver Partner,
with 18+ years in software delivery and 9+ across CMS and DXP platforms.
- We publish our engineering.
Our write-ups on Content SDK setup, headless personalization and the migration itself are public - you can judge the depth before you call us.
- We tell you when not to hire us.
If your app is small and conventional, we will say so, hand you the plan, and let your team run it.
Questions we get asked
01.Is JSS really end of life?| For SitecoreAI and XM Cloud, yes - support ended mid-2026 and no newer JSS version will support the platform. JSS continues to exist for other Sitecore products on their own timelines.
| For SitecoreAI and XM Cloud, yes - support ended mid-2026 and no newer JSS version will support the platform. JSS continues to exist for other Sitecore products on their own timelines.
02.Do we need a content freeze?No. Nothing on the Sitecore side changes. Authors keep publishing throughout the migration.
No. Nothing on the Sitecore side changes. Authors keep publishing throughout the migration.
03.Will our serialization and templates break?No. sitecore.json, your module files, the YAML on disk and the Sitecore CLI workflow are untouched. This is a front-end SDK migration.
No. sitecore.json, your module files, the YAML on disk and the Sitecore CLI workflow are untouched. This is a front-end SDK migration.
04.How long does it take?A conventional single-site app on recent JSS is a sprint, which matches Sitecore's own guidance. A multi-site application with substantial custom middleware is weeks, and most of that goes on your own code rather than SDK renames. The assessment gives you a real number.
A conventional single-site app on recent JSS is a sprint, which matches Sitecore's own guidance. A multi-site application with substantial custom middleware is weeks, and most of that goes on your own code rather than SDK renames. The assessment gives you a real number.
05.Can we stay on Content SDK 1.x for now?Yes, and many production sites do - it is supported and stable. You are deferring the Next.js 16 jump rather than avoiding it, which is a legitimate choice if this quarter is already full.
Yes, and many production sites do - it is supported and stable. You are deferring the Next.js 16 jump rather than avoiding it, which is a legitimate choice if this quarter is already full.
06.Should we migrate or rebuild?On JSS 22, migrate. On JSS 21 or older, Sitecore recommends starting fresh and bringing components across - and if your application has accumulated years of workarounds, that is often the faster route regardless of version.
On JSS 22, migrate. On JSS 21 or older, Sitecore recommends starting fresh and bringing components across - and if your application has accumulated years of workarounds, that is often the faster route regardless of version.
07.Can our own team do this?Often, yes. That is partly why the assessment is a standalone engagement: you get the plan whether or not we deliver it. Teams usually bring us in for the parts with no documentation - custom middleware, analytics wiring and multi-site routing.
Often, yes. That is partly why the assessment is a standalone engagement: you get the plan whether or not we deliver it. Teams usually bring us in for the parts with no documentation - custom middleware, analytics wiring and multi-site routing.
08.What tends to go wrong?Two things, repeatedly. Whatever logic lives in your own middleware, because nobody else has your version of it. And anything analytics-related, because it fails silently - the site renders perfectly and the events simply stop.
Two things, repeatedly. Whatever logic lives in your own middleware, because nobody else has your version of it. And anything analytics-related, because it fails silently - the site renders perfectly and the events simply stop.
Start a conversation
Tell us which JSS version you are on and roughly how many components you have, and we will tell you which of the three migrations you are facing - usually within a day, and before any money changes hands.