Migration guide

Can you migrate Sitecore to Sitecore XM Cloud?

Last updated: · By the Replatform Radar team — specialists in pre-migration CMS content audits

Yes — moving from Sitecore XP/XM to Sitecore XM Cloud is an in-family upgrade, so it is the most natural path Sitecore offers, but it is not a simple version bump. XM Cloud is SaaS and headless-first, so your content items and templates can be brought across with Sitecore's own serialization and migration tooling, while the presentation layer must be rebuilt as headless components (JSS/Next.js) instead of MVC or Sitecore renderings. Server-side code, custom pipelines, and on-prem infrastructure do not move to the managed SaaS environment. Plan for content and template continuity but a front-end and integration rebuild.

Sitecore XP/XM organizes everything as items in a content tree governed by templates, with layouts and renderings driving presentation, typically delivered through MVC or classic Sitecore rendering on infrastructure you host. Sitecore XM Cloud (rebranded SitecoreAI in late 2025) is the same content-item and template model delivered as a fully managed SaaS CMS that is headless-first: pages are composed from components and rendered by a decoupled front end, usually JSS with Next.js, and deployed through Sitecore's cloud pipeline.

Because both sides share Sitecore's item tree and template system, content and data templates transfer with in-family tooling — content serialization (Sitecore Content Serialization / items-as-resources) and migration utilities — rather than a from-scratch remodel. The concentrated effort is in the presentation and code layers: SXA or MVC renderings become JSS/React components, personalization moves to XM Cloud's embedded engine, and any custom server-side logic, scheduled agents, or pipeline processors must be re-implemented as external services or headless-compatible extensions because XM Cloud does not run arbitrary server code.

In your report — not a generic checklist

The Sitecore → Sitecore XM Cloud detail, catered to your site

A pre-migration scan produces a report tailored to this exact transfer, covering the parts that decide whether the project goes smoothly:

  • How Sitecore and Sitecore XM Cloud compare across the dimensions that matter for a migration
  • The field-mapping table — what each Sitecore construct becomes in Sitecore XM Cloud
  • The Sitecore to Sitecore XM Cloud-specific gotchas that silently cause data loss, broken links, and ranking drops
  • Realistic timeline and cost drivers for this migration
  • Your own site’s findings scored against all of it
Scan my site for this migration →

In depth

What a Sitecore to Sitecore XM Cloud project actually looks like

A realistic shape for this specific transfer. Phases, the work inside each, and the failures that recur on this exact platform pair. Spans assume a mid-size estate; large or multi-site estates run longer.

  1. Readiness assessmentWeeks 1-4
    • Establish which Sitecore version you are on and whether the path runs straight to XM Cloud or through an interim upgrade - this single fact reshapes the project.
    • Audit customisations that assume server-side control: pipelines, event handlers, custom caching and anything writing to disk have no home in a SaaS runtime.
    • Decide the front-end direction now. XM Cloud expects a head, typically Next.js, so an MVC-rendered estate is a rebuild rather than a lift.
    • Inventory integrations that ran in-process on XP; each becomes an external service call or a job scheduled elsewhere.
  2. Content and component modellingWeeks 4-10
    • Rationalise templates before serialisation - carrying an unreviewed template tree into XM Cloud imports the old estate's problems into the new one.
    • Rebuild renderings as components with the Sitecore JSS or Component SDK, mapping placeholders onto component slots.
    • Move authored content with Sitecore serialisation and the CLI, which is the well-trodden path; the transfer is reliable, the modelling decisions are not.
  3. Build and integrateWeeks 10-20
    • Stand up the deployment pipeline against XM Cloud environments; publishing behaviour and edge delivery differ materially from on-premise publishing targets.
    • Rebuild personalization on XM Cloud's embedded capabilities or Sitecore Personalize, depending on what the estate actually used.
    • Replace in-process scheduled jobs with external schedulers, since long-running server processes are no longer yours to run.
  4. CutoverWeeks 20-26
    • Verify edge caching and publishing behaviour under real editorial load before DNS moves - this is where SaaS migrations most often surprise teams.
    • Deploy redirects at the edge layer and confirm they survive a publish, a common regression on this platform.
    • Monitor rendering-level errors after launch; component-level failures in a headless build degrade differently from a monolithic page error.

Pre-launch verification checklist

The checks worth running before DNS moves. Each one maps to a failure we see repeatedly on Sitecore to Sitecore XM Cloud projects.

  • Every custom pipeline and event handler from XP has an explicit disposition: replaced, externalised, or retired with sign-off.
  • Editorial publishing round-trips end to end - author, preview, publish, edge visibility - at realistic content volumes.
  • Redirect rules survive a full publish cycle and are verified after publishing, not before.
  • The head renders structured data at least as well as the old templates; headless rebuilds routinely ship without schema.
  • Preview and personalization work for authenticated editors, not merely for anonymous visitors.
  • Asset and media URLs resolve through the new delivery path with no residual on-premise hostnames.
  • Search and sitemap generation are re-implemented for the headless front end rather than assumed to carry over.

Risk register

RiskLikelihoodMitigation
On-premise customisations with no SaaS equivalent discovered mid-buildHighComplete the customisation audit in phase one and price the replacements before committing to a date.
Front-end rebuild scoped as a port rather than a buildHighEstimate the head as a new build in its own right; MVC views do not translate into components.
Publishing and caching behaviour differs from on-premise expectationsMediumRehearse editorial publishing under load in a non-production environment before cutover.
Structured data and SEO metadata dropped in the headless rebuildMediumMake schema parity an explicit acceptance criterion for every component template.

Case studies: Sitecore to Sitecore XM Cloud migrations

Anonymized, real-world lessons from moves like this one. What breaks, what works, and how to protect your traffic.

FAQ

Sitecore to Sitecore XM Cloud: frequently asked questions

Is Sitecore XM Cloud an upgrade or a migration?

Both — it is an in-family move, so content items and templates carry over with Sitecore's serialization tooling, but because XM Cloud is SaaS and headless-first, the presentation layer and custom code are rebuilt rather than upgraded.

Does xDB and analytics data move to XM Cloud?

No. XM Cloud does not include xDB/xConnect; historical analytics and contact data stay behind, and marketing capabilities are re-platformed onto Sitecore CDP and Personalize.

Can I keep my Sitecore templates in XM Cloud?

Yes — data templates and the content tree transfer largely 1:1 using Sitecore Content Serialization and migration tooling, since XM Cloud shares Sitecore's item and template model.

Why do I have to rebuild the front end for XM Cloud?

Because XM Cloud is headless-first: pages are delivered through JSS and Next.js components instead of MVC or Sitecore renderings, so existing view markup and server-rendered layouts do not port.

Further reading

Before you migrate Sitecore to Sitecore XM Cloud, know exactly what breaks.

Scan your site →