Verified October 19, 2026. Checked against Sitecore's documentation and announcements.
Rebuild the head, move the content, rebuild personalization
SitecoreAI (formerly XM Cloud) is a SaaS, headless platform, so an XP or XM site does not lift across as is.1 The migration has three tracks. You rebuild the front end as a headless app, usually Next.js on Sitecore's Content SDK. You move content, with Sitecore's Pathway app doing much of the mapping.2 And you rebuild personalization and analytics on SitecoreAI's own capabilities, because XP rules and xDB data do not carry over.3
What SitecoreAI is
The evolution of XM Cloud
Sitecore announced SitecoreAI on 4 November 2025 as the evolution of XM Cloud, running on Microsoft Azure and unifying content management, customer data, personalization and search.4 Existing XM Cloud customers moved over without a migration.4 For XP and XM customers, it is a new platform, not a new version.
SaaS and hybrid headless
Sitecore's developer docs describe SitecoreAI as cloud-native, SaaS and hybrid headless.1 Sitecore hosts, maintains and updates it, which removes the installs and complex upgrades you run today. Content and presentation are separate: developers build the front end with the Content SDK and modern frameworks, while authors use visual tools such as Page builder.1
Where XP and XM customers stand
Sitecore's SitecoreAI FAQ says XP and XM customers continue to be fully supported, with active roadmaps, and that paths to SaaS will be available at each customer's own pace. Migration is a choice, not a deadline Sitecore has set. Your real deadline is your version's support dates.
Delivery through Experience Edge
Published content is delivered through Experience Edge's GraphQL endpoints.1 There is no Content Delivery role, web database or web index in SitecoreAI.5 Your front end, not a Sitecore CD server, renders the pages. That single change explains most of the migration work.
What you give up from XP
Features that are not in SitecoreAI
Sitecore's limitations list is explicit.5 Not in SitecoreAI:
- XP, xConnect and xDB functionality, including existing personalization rules
- Experience Analytics, Experience Profile, Experience Optimization, List Manager, Path Analyzer, Marketing Automation, Campaign Creator and the Marketing Control Panel
- EXM, FXM and Universal Tracker
- MVC, SXA with MVC, and SXA Search components
- Sitecore Forms (SitecoreAI Forms replaces it), custom search indexes, Publishing Service, Identity Server, device detection, IP Geolocation and Data Exchange Framework
The documented replacements
Sitecore's migration recipe maps XP features to two SitecoreAI capabilities: Conversion Optimization and Audience & Insights.3
| XP feature | SitecoreAI equivalent |
|---|---|
| Personalization rules | Page and component variants, headless and triggered personalization |
| Experience Optimization tests | A/B/n tests, 2 to 6 variants |
| Experience Analytics | Performance dashboards |
| Experience Profile | Profiles in Audience & Insights |
| Segments and List Manager | Audiences (not email recipient lists) |
| xDB contacts | Identity resolution, off by default |
| Marketing Automation, EXM, Path Analyzer, FXM | No equivalent |
Check availability first
Sitecore says both capabilities are rolling out in phases, so your environment may not have them yet, and you should confirm availability before planning around them.3 Existing rules must be rebuilt, not converted. In our view, that rebuild belongs inside the migration project plan, which matches Sitecore's own advice.3
The rebuild order Sitecore suggests
Sitecore's recipe lays out the sequence.3 Inventory the XP rules, goals, segments, profile cards, tests and reports still in use, and retire the rest. Recreate the segments that matter as audiences, which re-evaluate every 6 hours by default. Set up affinities, decide on identity resolution, then send events from the head app using the Cloud SDK. Only then rebuild variants, tests and reporting.
Capture events from day one
Sitecore's SaaS guidance recommends sending visitor events from the head application from the first release, so profiles and audiences already hold data when you switch personalization on. In our view this is the cheapest decision in the whole project.
Historical visitor data
Pathway does not move xDB history.3 If you need profiles, Sitecore documents a profile import from JSONL files, where each record needs an identifier that matches a configured identity rule.3 Decide early whether old contact data is worth carrying. In our experience, a clean start with new event capture is often simpler.
Readiness checks
Your front end: MVC, SXA or JSS
An MVC site is a full front-end rebuild, because MVC is not in SitecoreAI.5 Sitecore's recipe says SitecoreAI requires Headless SXA, and suggests reusing the existing CSS and HTML when porting to Next.js.3 SXA on MVC counts as MVC here. A site already on JSS is closer, but Sitecore's JSS docs set end of life for JSS 22.x after June 2026 and point all new work to the Content SDK.
Going headless first rarely saves effort
It is tempting to move XM or XP to headless before the move to SitecoreAI. Sitecore's recipe calls this useful only in uncommon cases: in most cases the effort is moved, not saved, and more is added at the final step.3 It also says upgrading XP to the latest version first is not always required.3
Customizations
List every pipeline processor, event handler, editing UI change and custom content resolver. Sitecore calls several of these deprecated architectural patterns that slow future migration work.3 Custom search indexes are not available in SitecoreAI.5 Each customization needs a decision: rebuild in the head, replace with a SaaS capability, or retire.
Your authors
Authoring changes too. SitecoreAI authors build pages in visual tools such as Page builder.1 Sitecore's SaaS guidance recommends that business users learn the new authoring basics and test an end-to-end authoring workflow before launch. Budget time for training, not just for code.
Integrations
Anything built on Data Exchange Framework, Publishing Service, Identity Server or xConnect needs a new design.5 Content search on Solr is the classic blocker. For tight timelines, Sitecore describes a phased route: headless SXA on the existing Solr first, composable search next, SitecoreAI last.3
Content model
Pathway expects the source site to follow Helix principles with a default layout structure, and you need to know which templates, renderings and page designs the site uses.2 Before migrating, you set up the target in SitecoreAI: layout, templates, components, page designs and partial designs.2 A messy content tree shows up here first.
Serialization
Sitecore's modules compatibility table lists Sitecore CLI 5.1.25, 5.2.113 and 6.0.18 as compatible with XP 10.1 to 10.4 and with SitecoreAI. In our experience, teams already on Sitecore Content Serialization have a familiar route for templates and settings items. Treat serialized items as code, and plan the content move separately.
The migration shape
Content with Pathway
SitecoreAI Pathway is Sitecore's AI-assisted migration app. For a Sitecore source, it extracts layout, renderings, components and data from the XM or XP site and maps them to your SitecoreAI project before moving content.2 It handles one site at a time, supports multiple languages, and needs admin access to the source XM or XP instance plus .NET 10 installed.2
What Pathway leaves out
Pathway does not migrate page designs, partial designs, xDB data, email marketing content or personalization.2 For media, Sitecore says to use the XM to XM Cloud migration tool. Its download page says version 2 moves content, media and users from XM 9.1 and later, and does not migrate front-end layouts or renderings.
The front-end rebuild
Sitecore's Content SDK docs describe a Next.js starter template, integration with the Pages visual editor, and personalization and component A/B/n testing support out of the box. That is the documented starting point for new SitecoreAI front ends. Plan hosting for the head app as well; it is yours to run.
Cut-over: big bang or hybrid
Sitecore describes two approaches.3 Big bang suits most sites: rebuild, then switch in one move. Hybrid suits large estates: build the shell in SitecoreAI, migrate sections one by one, and route traffic between old and new with something like Azure Front Door. Hybrid means search must index both systems, logins must work across both, and visitor identity must be shared.3
Effort
We will not quote a number without seeing your site. In our experience, the front-end rebuild and the personalization rebuild set the timeline, not the content move. Sites with little XP marketing use and a clean content model move fastest. Our SitecoreAI migration readiness check helps you see which side of that line you are on.
When upgrading in place is better
Sitecore's own recipe says that if you want to move XP to the cloud as it is, the right move is Managed Cloud, not SitecoreAI.3 If you depend on Marketing Automation or EXM, there is no SitecoreAI equivalent.3 Sitecore's SaaS guidance adds that SitecoreAI may not suit on-premises hosting requirements or teams not ready for headless. In those cases, upgrade to 10.4 or 10.5 instead.
Check your support dates first
Your current version's support dates decide how much time you have to choose. Our support dates guide lists them for 9.3 to 10.5. If you want a second opinion on your site, talk to a senior Sitecore consultant.
References
Footnotes
-
Sitecore Documentation. "Migrate a site to SitecoreAI" ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Sitecore Developer Portal. "Transition from XM/XP to SitecoreAI" ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16
-
Sitecore. "Sitecore Unveils SitecoreAI, Ushering in the AI-First Era of Digital Experience" ↩ ↩2
-
Sitecore Documentation. "Limitations and restrictions" ↩ ↩2 ↩3 ↩4 ↩5