This is an illustrative composite scenario. It does not describe any single real organization; it generalizes patterns we see repeatedly across Sitecore upgrade projects. Figures are typical ranges, not one company’s exact numbers.
Context
Picture an enterprise running Sitecore XP on infrastructure they manage — a mature implementation with SXA components, MVC renderings, a stack of custom pipelines and scheduled agents, and years of marketing analytics in xDB. The maintenance burden and infrastructure cost had become the story at every budget review, and leadership wanted the managed, cloud-first path Sitecore itself was steering customers toward: XM Cloud, delivered headless through JSS and Next.js.
Because both sides share Sitecore’s item tree and template model, teams often expect an upgrade. It is better understood as an in-family replatform: content and templates come across with Sitecore’s own tooling, but the presentation layer and anything that ran server-side are rebuilt, because XM Cloud is SaaS and does not run arbitrary server code.
What broke
The surprises were consistent across the project.
The front end is a rebuild
MVC and SXA renderings do not port. Every rendering became a JSS/React component, and the front end was re-implemented in Next.js. Teams that scoped this as a “lift” of the presentation layer blew their estimates — the front-end rebuild is usually the single largest line item, not a migration afterthought.
xDB and analytics history stay behind
XM Cloud does not include xDB or xConnect. Historical contact, interaction, and analytics data did not migrate, and marketing automation built on xDB had to be re-platformed onto Sitecore CDP and Personalize. The organization had to accept a clean break in analytics continuity and plan the personalization rebuild as new work.
Custom server code has nowhere to run
Pipeline processors, event handlers, scheduled agents, and computed fields all assumed a server the team controlled. In a SaaS environment none of that runs, so each piece was rebuilt as an external service or a headless-compatible extension — a re-architecture, not a copy.
Routing and SEO parity
Headless Next.js delivery changes URL and routing behavior. Without deliberate route parity and a complete 301 map, the cutover risked dropping rankings and breaking inbound links across a large, well-established site.
What worked
The parts that went smoothly were the in-family parts. Data templates and the content tree transferred largely one-to-one using Sitecore Content Serialization and items-as-resources tooling, so the content model did not have to be rebuilt from scratch. The team sequenced the work sensibly: serialize and validate content early, rebuild the component library in JSS in parallel, and stand up edge delivery and preview before cutover. Treating the front-end rebuild as the primary workstream — and the content transfer as the reliable, tooled part — kept the estimate honest.
Lessons
- It is an upgrade for content, a rebuild for presentation. Templates and items serialize across; MVC/SXA renderings are re-implemented in JSS/Next.js.
- Accept the analytics break. xDB history does not move; plan the CDP/Personalize re-platform and the personalization rebuild as new work.
- Re-architect server-side code. Pipelines, agents, and processors become external services — inventory them early.
- Protect routes and SEO. Design route parity and a full 301 map before headless delivery goes live.
- Scope the front end honestly. The JSS rebuild is the biggest cost; treat it as the main project, not a port.
Before you make this move
The checklist that would have de-risked this upgrade:
- Inventory every rendering and component, and plan the JSS/Next.js rebuild as the primary workstream.
- List all custom server-side code — pipelines, agents, processors, computed fields — and design external replacements.
- Decide what happens to xDB analytics and marketing automation, and scope the CDP/Personalize move.
- Validate content and template serialization on a real slice before committing to the approach.
- Design route parity and the 301 map for headless delivery ahead of cutover.
A pre-migration scan makes the split concrete: the Sitecore-to-XM-Cloud path is where the front-end rebuild, server-side code, and routing changes hide. Replatform Radar maps that surface for your own site before you lock a plan and a budget.