Sitecore Experience Manager Cloud, or Sitecore XM Cloud, is a SaaS headless CMS that is a foundation for a composable digital experience platform (DXP) centered around content.
XM Cloud moved Sitecore's content-management offering toward a SaaS, headless architecture. It changes where code runs and how content reaches the public website; it is not simply an XP installation with the servers managed by somebody else.
Product terminology has also moved on. Sitecore's current documentation uses SitecoreAI, while existing projects and contracts may still refer to XM Cloud. This article explains the architectural background; confirm the product and enabled capabilities in your proposed environment.
For current migration scope, use Sitecore's migration documentation. It explicitly excludes several XP-related items from the automated migration path, including xDB data and personalization. A content transfer is not a complete application migration.
Distinguish managed hosting of an existing XM or XP application from a move to the SaaS CMS. The first may preserve much of the application; the second can require new presentation, integration, search, and personalization designs.
The portal gives teams access to their projects and environments. Check the available environments, deployment paths, and permissions against the subscription rather than assuming that every project has the same configuration.
- First and foremost, you get your own tenant within the Sitecore Cloud Portal.
- Within that tenant, you’ll have access to the Deployment Center, as well as all instances of Sitecore you are running and any other Sitecore products you may be signed up for.
Meet Sitecore Deployment Center
The deployment tooling manages CMS projects, builds, environments, and logs. Establish which repository and branch supply each environment, where configuration is stored, and who can deploy. Keep the website frontend's deployment path visible too; deploying the CMS does not necessarily deploy the public site.
Review the current repository integration's requested permissions with your administrator. Do not grant broad organization access simply because an old setup guide recommends it. If using a supported CLI-based pipeline instead, document credential scope, rotation, and the approval step for production.
Use separate environments for changes that need independent validation, subject to the agreement's limits. Test content models, serialized configuration, preview, and deployment using representative content. Provisioning time and environment costs depend on the current service and contract; neither is a universal fixed number.
Improved Sitecore XM Cloud
Inventory the XP capabilities the business actually uses before migrating. Customer interaction data, marketing automation, forms, personalization, and authentication may need a different implementation. A vendor-operated CMS reduces platform administration; it does not preserve every XP feature or customization.
Use the supported tooling for the target product and version. Headless components, content serialization, and the editing integration have to work together. Treat an example starter repository as a starting point, not evidence that your existing components will run unchanged.
With SXA, you get features like configurable error pages, redirects that can be managed through Sitecore, and tools to work with page layouts without needing to create separate templates. All of this significantly reduces the effort required to get sites up and running and gives content authors more control over the look and feel of their content.
Have an editor assemble a real page, change a shared component, preview a language variant, and publish the result. Check that custom components behave in the editor as well as on the public site. A responsive editor does not correct a poorly modeled component.
Another new app that comes with XM Cloud is called Explorer. It’s a lightweight replacement for the Content Editor, allowing for content modifications that can’t be done through the Pages app. While it doesn’t have full feature parity with the Content Editor, it provides the necessary tools to make it, in combination with Pages, a complete content editing suite.
The Headless Services module is perhaps the biggest and most important module that enables the SaaS aspect of XM Cloud. With this module, you are no longer tied to ASP.NET’s MVC engine to render your content. Instead, Sitecore can now serve your content in JSON through a set of GraphQL endpoints, allowing you to connect any frontend and making Sitecore a truly headless CMS.
Separating content delivery from rendering changes the team's interfaces. Agree on content fields, API contracts, preview behavior, caching, and release coordination before dividing the work between CMS and frontend developers.
The teams can work on different parts of the implementation, but they still share responsibility for the delivered page. A renamed field, missing language version, or cache-key mistake can break the frontend without any change to its layout code.
Architecture
Experience Edge provides managed content delivery for headless applications. The public frontend retrieves published content through supported APIs rather than relying on the traditional content-delivery server topology. Do not assume that code formerly hosted in a delivery server can run inside that managed service.
Assess the application's behavior at this boundary. Which APIs are custom? Which indexes supply search? How does a shared navigation change reach every affected page? The following areas need explicit migration decisions:
- Custom Search Indexes: You can no longer rely on Sitecore’s built-in indexes to query data in the code. While it’s possible to use search queries through the GraphQL API, you are limited to your context’s index and have no control over how and when the index is updated. The solution is to either build custom search functionality or leverage existing solutions, such as Coveo or Sitecore Search (marketed as a separate product).
- Custom APIs: It is common to have one or a few custom APIs built into your Sitecore project, but with Edge, this is no longer possible since Edge cannot be extended by custom code. This requires some (and sometimes considerable) effort in rearchitecting your APIs by extracting them into separate apps.
- Shared components: test publication and cache invalidation for navigation, global settings, and reused content. Verify the target version's dependency behavior before choosing between build-time and request-time retrieval. The acceptance test is that every affected page shows the approved change—not an assumption that one caching pattern fits all implementations.
Conclusion
Evaluate the move with one representative site section, an actual editor, and a real integration. Confirm preview, publishing, redirects, access controls, cache invalidation, and recovery. Then estimate the rest of the migration using what the trial revealed. SaM Solutions can review the existing architecture and identify which work a SaaS transition will—and will not—remove.
Vadim Gusev
Sitecore evangelist, Sitecore and .NET Architect at SaM Solutions. Full-stack developer with almost a decade of experience in the traditional and headless CMS world.
