Before you get attached: nobody in this story is real. It’s a composite, stitched together from the same handful of patterns we watch play out on Sitecore upgrade projects over and over (you will recognize your own project in here somewhere, and that’s the point). The numbers are typical ranges, not one company’s actual figures. No org was harmed in the making of this case study.
Somewhere in a quarterly budget review, someone reads the Sitecore infrastructure line item out loud, and the room does that thing where everyone suddenly finds the ceiling very interesting. The servers, the patching, the on-call rotation, the invoice that grows a little every year. And then someone says the sentence that starts this whole thing: "Sitecore has a cloud version now, right? Let's just move to that."
Here's why I wanted to pull this one apart. Because both XM Cloud and the old XP share the same item tree and the same template model, almost everybody I talk to files this move under upgrade. Same family, same content, click a button, land in the cloud. And I get the instinct, I really do. But the projects that scoped it that way are the ones that blew their estimates in ways nobody enjoyed explaining at the next budget review. So I went looking for what actually crosses over and what quietly gets rebuilt from nothing, because the gap between those two things is the whole story.
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.
So what do I actually think? This is a rebuild wearing an upgrade's name badge. The content half is genuinely lovely: templates and the item tree serialize across with Sitecore's own tooling, and that part behaves exactly like the friendly in-family move everyone pictured. But the presentation layer, the xDB history, and every pipeline and agent you ever wrote server-side are new work, full stop. If you only take one thing from me, make it this: scope the JSS and Next.js front-end rebuild as the main project and let the content transfer be the reliable, boring workstream underneath it. Teams that flip that order are the ones who get surprised.
And I'd rather you got surprised now, on paper, than in the meeting where the number gets read aloud. Run a scan before you commit and the split stops being a guess. The Sitecore-to-XM-Cloud path is where the front-end rebuild, the server-side code and the routing changes have all been sitting quietly, waiting for that budget review. Replatform Radar maps that surface for your own site first, so the line item you read out loud is the real one.