For years, I’ve been navigating the ever-evolving landscape of Sitecore, and I’ve seen my fair share of game-changing updates. But let me tell you, the recent release of Sitecore Content SDK v1.2 feels different. This isn’t just another incremental update; it’s a fundamental shift in how we build for XM Cloud, and it’s bringing the power of the Next.js App Router to the forefront of Sitecore development. I’ve had the chance to dive deep into this release, and I’m thrilled to share my findings with you.

src/
├── app/
│   ├── [site]/
│   │   ├── [locale]/
│   │   │   └── [[...path]]/
│   │   │       └── page.tsx
│   │   └── layout.tsx
│   ├── api/
│   ├── layout.tsx
│   ├── not-found.tsx
│   └── global-error.tsx
├── components/
├── lib/
└── middleware.ts

// src/app/[site]/[locale]/[[...path]]/page.tsx

import { notFound } from 'next/navigation';
import { draftMode } from 'next/headers';
import client from 'src/lib/sitecore-client';
import Layout from 'src/Layout';

export default async function Page({ params, searchParams }: PageProps) {
  const { site, locale, path } = await params;
  const draft = await draftMode();

  let page;
  if (draft.isEnabled) {
    const editingParams = await searchParams;
    // ... handle preview and design library data
  } else {
    page = await client.getPage(path ?? [], { site, locale });
  }

  if (!page) {
    notFound();
  }

  return <Layout page={page} />;
}

// src/app/[site]/layout.tsx

import { draftMode } from 'next/headers';
import Bootstrap from 'src/Bootstrap';

export default async function SiteLayout({
  children,
  params,
}: {
  children: React.ReactNode;
  params: Promise<{ site: string }>;
}) {
  const { site } = await params;
  const { isEnabled } = await draftMode();

  return (
    <>
      <Bootstrap siteName={site} isPreviewMode={isEnabled} />
      {children}
    </>
  );
}

A guide on how to resolve the media problem with the default vanilla StarterKit (foundation head) when images do not show on a site when accessed by a hostname.

Reproducing the problem

1. Pull the latest starter kit, run init.ps1 , and up.ps1 as normal. Everything is fresh and clean; nothing else than that.
2. When CM spins up, create a site collection followed by a site with the default name (nextjs-starter) matching the name of the JSS app.
3. Open the home page in Experience Editor and drop an Image component to that page, upload and choose the image, save, and confirm it looks fine in EE.
4. Open the home page again on the site: https://nextjs.xmc-starter-js.localhost and see the error

The error

Invalid src prop (https://cm/-/jssmedia/Project/Tenant/Habitat/LA.jpg?h=408&iar=0&w=612&ttc=63890432287&tt=4BBE52A4592C2DBCAE59361096C0E4D3&hash=0CA75E384F533EE5539236785DCF0E22) on `next/image`, hostname "cm" is not configured under images in your `next.config.js`

IMG

What happens?

The hostname of a local CM container is applied to the generated media URL (https://cm). That is not right, as CM hostname is not accessible outside of containers, and only works within the internal Docker network at the HTTP protocol, not HTTPS. After playing with the image URL, it was clear it works by a relative path, trimming the hostname from the start. Both URLs below are valid and show the image:

• https://xmcloudcm.localhost/-/jssmedia/Project/Tenant/Habitat/LA.jpg?h=408&iar=0&w=612&ttc=63890432287&tt=4BBE52A4592C2DBCAE59361096C0E4D3&hash=0CA75E384F533EE5539236785DCF0E22
• https://nextjs.xmc-starter-js.localhost/-/jssmedia/Project/Tenant/Habitat/LA.jpg?h=408&iar=0&w=612&ttc=63890432287&tt=4BBE52A4592C2DBCAE59361096C0E4D3&hash=0CA75E384F533EE5539236785DCF0E22

Testing an assumption

I thought if there was a problem on the datasource resolver of the Image component, but the resolver wasn't set. Just for the sake of experiment, decided to explicitly set image component to use `/sitecore/system/Modules/Layout Service/Rendering Contents Resolvers/Datasource Resolver`, since it has the same effect as when not set, along with unchecking Include Server URL in Media URLs settings for that resolver.

IMG 2
IMG3

That effectively resolved the issue. My guess was valid, so let's now seek a permanent solution.

The working solution

Once the assumption of removing a hostname is proven, let's take it out at the CM level so that it universally applies to your environments and you don't need to precisely set resolvers on each individual component. The below config patch does exactly what we need.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
  <sitecore>
    <layoutService>
      <configurations>
        <config name="sxa-jss">
          <rendering>
            <renderingContentsResolver>
              <!-- Set the desired values for the JSS configuration -->
              <IncludeServerUrlInMediaUrls>false</IncludeServerUrlInMediaUrls>
            </renderingContentsResolver>
          </rendering>
        </config>
      </configurations>
    </layoutService>
  </sitecore>
</configuration>

That resolved my problem:

IMG4

Hope this helps you as well! 

Historically, changing the ID of an item in Sitecore was widely believed to be impossible, particularly within the constraints of XM Cloud.

In the XP era, I experimented with a custom package nearly a decade ago that did successfully change item IDs. However, achieving this required considerable effort: decompiling out-of-the-box DLLs, reverse engineering the code, and then rebuilding DLLs to match various Sitecore versions and dependencies. The process was complex and not ideal, dependent on runtime specifics. I managed to make it function, but lots have changed since then.

With XM Cloud, many of those challenges have been eliminated. Notably, the platform now includes Sitecore PowerShell Extensions (SPE) out of the box. This makes it feasible to develop a universal script that can change the ID of any item in the content tree, invoked directly from the context menu without the need for server-level modifications. All it takes is a simple package containing a single Sitecore item.

Why change ID?

1. Database Merges and Migrations

• Resolving ID Conflicts During Database Merges: When combining multiple Sitecore databases (e.g., from separate instances or acquisitions), duplicate IDs can occur if items were created independently. Changing the ID of conflicting items in one database allows seamless integration without data loss.
• Content Migration from Legacy Systems: During upgrades or migrations from older Sitecore versions or other CMS platforms, imported items might have IDs that clash with existing ones. Changing IDs ensures uniqueness while preserving content structure.
• Multi-Environment Synchronization: If dev, staging, and production environments diverge (e.g., due to unsynced TDS/Unicorn serializations), changing IDs in one environment can align them without recreating everything.
• Cross-Database Item Transfers: When moving items between master, core, or web databases, ID collisions might arise; changing the ID facilitates clean transfers.

2. Integration with External Systems

• Aligning with External Data Feeds or APIs: If an external system (e.g., a CRM like Salesforce or a data warehouse) references Sitecore items by GUIDs but uses its own fixed IDs, changing Sitecore's item ID to match the external one ensures synchronization without modifying the external system.
• Third-Party Tool Compatibility: Some integrations (e.g., e-commerce plugins or analytics tools) might require specific ID formats or mappings; changing IDs bridges mismatches.
• Bi-Directional Sync with Other Platforms: In setups with real-time syncing (e.g., via Sitecore Data Exchange Framework), ID changes might be needed to resolve sync errors caused by GUID mismatches.
• Federated Identity Management: For systems integrating Sitecore with identity providers, where user-generated content items need ID alignment for security or tracking.

3. Item Recovery and Error Correction

• Recovering from Accidental Deletions: If a critical item is deleted (and not sent to the Recycle Bin) but referenced extensively, recreating it with a new ID and updating links/indexes can restore functionality faster than manual fixes, especially if the original ID causes reference breakage.
• Fixing Overwritten or Forgotten Items in Version Control: In team environments using TDS or Unicorn, if an item is overwritten or omitted during serialization, changing its ID can resolve conflicts and reintegrate it without rebuilding the entire project.
• Correcting Database Corruption or Duplicates: Rare DB errors (e.g., from failed restores) might create duplicate IDs; changing one item's ID eliminates the duplication.
• Repairing Broken References After Errors: If an item's ID leads to index or link database issues (e.g., due to partial publishes), changing it and triggering a reference update can fix widespread breakage.

4. Development and Testing Scenarios

• Simulating ID Conflicts in Testing: Developers might change IDs to test merge scripts, index rebuilds, or reference update pipelines in controlled environments.
• Refactoring Large Content Trees: During site redesigns, changing IDs of template items or folders can help reorganize without disrupting live content, especially if combined with link repairs.
• Debugging Custom Modules: To isolate issues in custom code that relies on specific IDs (e.g., caching or workflows), temporarily changing an ID can aid troubleshooting.
• Performance Optimization Testing: Changing IDs to force index refreshes or cache invalidations in load testing, helping identify bottlenecks.

4. Other creative scenarios

• Proof of authoring: In certain cases, you may want to intentionally leave a trace or proof of authoring in the item's ID so that you can prove the fact that you've done this job at some stage later. Once working on a questionable project, I used this trick to encode my phonу number as the last digits of the site definition item. This does not affect any functionality, but at the same time cannot be just a random coincidence.
• Easter eggs: In some mostly non-production cases, you may want to have some fun with issuing creative naming IDs. HEX-based codes allow plenty of creativity there. All these are valid HEX numbers: 
  • Four chars long: BEEF, CAFE, BABE, FACE, CODE, FEED
  • Eight chars long: DEADFACE, C0FFEEED, C0DEC0DE, BEEFC0DE
  • Twelve char long: DEADC0FFEEED, DEADFADEBEEF, AD1DA5AD1DA5

Key Features of the PowerShell Module

The PowerShell module provided below delivers the following capabilities:

• Assigns a new ID to any item: Accepts user input for the new ID, supporting not only standard content items but also templates, media, system items, and more.

• Processes hierarchical structures: Handles items with children, fields, and sections, while maintaining the integrity of Standard Values for templates.

• Updates derived content items: Sets the correct TemplateID on all derived items, preventing "object reference not set" errors.

• Moves and patches descendants: Migrates and updates all child sections and fields under the new template as needed.

• Refreshes all references: Updates any base templates, field sources, or XML fields that reference the old template.

• Cache management: Flushes Sitecore caches and, optionally, rebuilds the Link Database and triggers a publish.

• Efficient querying: Utilizes fast queries to ensure every relevant content item is included.

• Comprehensive edge case handling: Covers all major scenarios and exceptions.

How It Works

Since Sitecore does not provide an API for changing item IDs directly, the script implements a robust workaround:

1. Duplicate the source item (with all fields) under a new ID using the SPE API, which supports custom ID assignment.

2. Move all children from the old item to the newly created item.

3. Update all references in the database to point from the old ID to the new one.

4. Delete the original item once all dependencies have been switched.

Note: Due to the deletion step, this script cannot be used on items that originate from resource files; only items stored in a database are eligible.

Usage

IMG

Download

[Download package: ChangeItemID-1.0.zip]

I developed an AI-powered migration framework that streamlines the migration of Sitecore XP websites to XM Cloud, automating and eliminating 70% to 90% of the manual effort typically required. This solution accurately preserves each page’s presentation structure, including the full hierarchy of components and placeholders the entire set of migrated content, and the rendered HTML output. All Sitecore assets retain their original structure, hierarchy, item IDs, and paths after migration.

The framework requires only two inputs: 1) a backup of the master database and 2) access to any operable site environment, may it be UAT, Production, or even Local. Since direct database operations in the cloud are not possible, the actual migration always runs locally. Having the original source code is optional, but providing it greatly enhances the accuracy of component markup conversion.

At a high level, he migration framework performs the following steps:

• conducts pre-execution sanity checks and flags potential issues, such as media items exceeding 50Mb or broken layout/references at the origin
• copies the actual content from XP to XM Cloud
• converts rendering definitions to ensure XM Cloud compatibility
• converts ASP.NET MVC Razor Views (*.cshtml files) into Next.js components with TypeScript (*.tsx files)
• migrates site presentation from the XP format to the XM Cloud format, processing each page individually
• rebinds datasources as needed for XM Cloud compatibility

For demonstration purposes, I used the well-known Habitat site running on Sitecore 9.2, which I was able to recover from some of my archived VM snapshots. Having a running instance of the site is essential, regardless of the environment. In this example, I configured the VM's hostname rssbplatform.dev.local via my hosts file so it would be accessible from my host machine.

It’s important to note that Sitecore XP and XM Cloud handle presentation differently in defining the page's presentation and dealing with the dynamic placeholders. Unlike XM Cloud, which has a rendered page layout JSON per each of the pages, MVC-powered XP websites did not keep the hierarchy: resolving and preserving the correct hierarchy during migration requires access to a working runtime instance of the source site..

Disclaimer: the demonstration video shows the entire migration of a Habitat website in just 12 minutes, starting with the content migration and ending up recreating the site on XM Cloud, including all the converted pages with the entire layout/structure converted to each of them.

I am not a front-end developer in the first place; thus, I decided to skip this part of conversion for now. When it comes to static files, there are two ways:

• If you don't have an original source code, just place compiled JS/CSS files under /public folder in Next.js app and adjust the references; no changes are possible.
• With the source original code, you can compile and deploy static files under /publiс folder; that includes any changes you may have down the way.

Please take into account that not all styles are picking up: that task falls into a remaining 10%-25% of things to do manually. 

When converting styles, they fall into three main categories:

• Fixed styles: These are automatically picked up during conversion.
• Parametrized styles: Since the migration framework processes rendering parameters, many of these at least default values are also migrated automatically.
• Dynamic styles: Styles generated at runtime or claculatev via scripts require custom build logic to be reimplemented on the Next.js side.

With further stages of development, the goal is to entirely convert parametrized and as much of dynamic classes, as it is possible.

What previously took months of manual labor for a decent team can now get done in minutes. Isn't that incredible?

I wish to hear youк thoughts, drop me a message!

Do you use hotkeys? 

I am pretty sure most of you intuitively press Ctrl + S in order to save the changes in Content Editor. Highly likely, you also do any of these below:

• Del -for deleting an item, and all of its children
• F2 - rename an item

However, there are plenty of other meaningful shortcuts for you to use:

• F9 - publish site dialog
• Ctrl + D - duplicates an item, one of my favorite ever.
• Ctrl + Win - opens a Sitecore "Start" menu (however, that does not work in 100% of cases)
• F7 - Validation Results
• Left / Right keyboard arrows allow expanding and collapsing items' nodes

View togglers:

• Ctrl + Shift + Alt + R: Toggle raw values. This is one of my best savers when I need to grab an ID for a lookup from a reference field.
• Ctrl + Shift + Alt + T: Toggle the display of standard fields, which helps improve Content Editor performance when off
• Ctrl + Shift + Alt + L: Toggle the protection for a selected item.

Content Editor Tabs:

IMG

They typically work as Alt + <first_letter_of_a_tab>:

• Alt + H: Home
• Alt + N: Navigate
• Alt + R: Review
• Alt + P: Publish
• Alt + V: Versions
• Alt + C: Configure
• Alt + S: Security

 ... but since several tabs start from the same character, less straightforward hotkeys are used:

• Alt + I: View

Predictive search

In Content Editor, hit Ctrl + / and you'll see the bottom right search area activate, waiting for your input. Type in at least two characters for it to progressively show the results, as you keep typing.

IMG Progressive

Mouse Gestures

Dragging and item with Ctrl button held creates a copy of that item right at the location where you release the button.

How do I know these shortcuts?

There is a master shortcut Alt + F1 that brings up helpful labels exposing the hotkeys for the specific functions on a Ribbon:

IMG Alt-F!

Hope this helps you to stay more productive!

Could you ever guess that you can still access databases in XM Cloud directly at SQL level? Yes, you can, and below I am showing how exactly.

Disclaimer
The step‑by‑step SQL‑level techniques described in this post are provided strictly for educational purposes. Directly querying or modifying the underlying database of Sitecore XM Cloud is strongly discouraged, as it bypasses critical application‑level safeguards, voids support agreements, and may lead to data corruption, security vulnerabilities, or service outages. Always interact with your XM Cloud instance through the officially supported APIs, Sitecore CLI, or designated administration tools. Proceeding with direct database access is done entirely at your own risk, and the author and any affiliated parties disclaim all liability for any loss, damage, or disruption resulting from such actions.

The key trick here goes from Sitecore PowerShell extension, if you have them enabled at your instance, you're good to go! This applies to both cloud and locally containerized databases. PowerShell has a useful commandlet Invoke-SqlCommand that allows making SQL-level connections and accepts two parameters: connection and query:

Invoke-SqlCommand -Connection $connection -Query $query 

But how do we get a connection? Luckily, since we operate from within ASP.NET application, we can use its own API to get it, no even needing to look up the connection strings config:

$connection = [Sitecore.Configuration.Settings]::GetConnectionString("master")

The other thing is that we must know the physical name of the database to operate against. Once again, we can calculate that without even a lookup:

$builder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder $connection
$dbName = $builder.InitialCatalog

Please note that on a local, your database name is always Sitecore.Master, while on a cloud instance, it is very long, combined from the org, project, and environment names, thus always varies from environment to environment, so you have to calculate it like that.

Next, let's build a query. To start with we can do a basic select for the fields of an item. Having a physical database name, we can pass it into a query as below:

$sql = @"
USE [{0}]
SELECT ID, [Name], [TemplateID], Created from  [dbo].[Items]
"@

With that in mind, let's combine everything together into a single script:

$sql = @"
USE [{0}]
SELECT ID, [Name], [TemplateID], Created from  [dbo].[Items]
"@

Import-Function Invoke-SqlCommand

Write-Verbose "Cleaning up the History, EventQueue, and PublishQueue tables in the $($db.Name) database."
$connection = [Sitecore.Configuration.Settings]::GetConnectionString("master")
$builder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder $connection
$dbName = $builder.InitialCatalog
$query = [string]::Format($sql, $dbName)

Invoke-SqlCommand -Connection $connection -Query $query 

Testing it brings the desired result:

IMG

But what is especially amazing is that you also have write access to master database! With that in mind, I create a query that creates a new item under a specific location and also populates some of its fields. It looks slightly more complicated, but again, nothing extraordinary:

$sql = @"
USE [Sitecore.Master];

-- Variables
DECLARE @NewItemId UNIQUEIDENTIFIER = NEWID();
DECLARE @ParentId UNIQUEIDENTIFIER = '{110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9}';
DECLARE @TemplateId UNIQUEIDENTIFIER = '{76036F5E-CBCE-46D1-AF0A-4143F9B557AA}'; -- Sample Item template
DECLARE @TextFieldId UNIQUEIDENTIFIER = '{A60ACD61-A6DB-4182-8329-C957982CEC74}'; -- Text field ID
DECLARE @Now DATETIME = GETUTCDATE();
DECLARE @ItemName NVARCHAR(255) = 'SQL-inserted item';
DECLARE @Language NVARCHAR(10) = 'en';
DECLARE @Version INT = 1;
DECLARE @TextValue NVARCHAR(MAX) = 'This item was created entirely with SQL INSERT script';

-- 1. Insert into Items
INSERT INTO [dbo].[Items] 
    ([ID], [Name], [TemplateID], [ParentID], [MasterID], [Created], [Updated])
VALUES 
    (@NewItemId, @ItemName, @TemplateId, @ParentId, '00000000-0000-0000-0000-000000000000', @Now, @Now);

-- 2. Insert into VersionedFields (CORRECT field ID now)
INSERT INTO [dbo].[VersionedFields]
    ([ItemId], [FieldId], [Language], [Version], [Value], [Created], [Updated])
VALUES
    (@NewItemId, @TextFieldId, @Language, @Version, @TextValue, @Now, @Now);
"@

Import-Function Invoke-SqlCommand

Write-Verbose "Cleaning up the History, EventQueue, and PublishQueue tables in the $($db.Name) database."
$connection = [Sitecore.Configuration.Settings]::GetConnectionString("master")
$builder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder $connection
$dbName = $builder.InitialCatalog
#$query = [string]::Format($sql, $dbName)
$query = $sql

Invoke-SqlCommand -Connection $connection -Query $query 

Upon the execution, we see no changes in Content Tree, which is likely due to some CM caches in place. For the sake of clarity, I restarted CM and got this newly created item with all the fields, as executed:

IMG

That approach is really awesome, despite feeling so hacky! Imagine combining it with the SPE Remoting and/or combining that with AI - it brings unlimited potential. But once again, it all goes for educational purposes exclusively.

Experience Edge brought us that much-desired Content-Delivery-as-a-Service approach and happened to be revolutionary in its vision. However, that flexibility of service comes at some expense, and the limitations each of us must be aware of. Understanding these is critical when building cloud-hosted Sitecore solutions. The key technical limits include API rate throttling, data payload/query size caps, content/media size limits, caching rules, and XM Cloud platform constraints. In this post, I will cover them all, so that it can help you plan better.

API Rate Limits

• 80 requests/sec. The Experience Edge GraphQL endpoint is rate-limited. Each tenant’s delivery API allows at most 80 requests per second (visible as X-Rate-Limit-Limit: 80). Exceeding this returns HTTP 429 (Too Many Requests) until the 1-second window resets. In practice, Sitecore notes this is a "fair use" cap on uncached requests, so designing with CDN caching via SSG/ISR is essential to stay below the limit.

• Rate-limit headers. Every Edge response includes headers like X-Rate-Limit-Remaining calls this second, and X-Rate-Limit-Reset essentially - the time until reset, to help clients throttle their calls. For example, if 5 requests are made in one second, the next response will show 75 remaining.

GraphQL Query & Payload Constraints

• Max query results: A single GraphQL query returns at most 1,000 items/entities. To fetch more items, you must use cursor-based pagination. For example, any search or multi-item query is capped at 1000 results per call.

• Query complexity limit: Edge enforces a complexity budget on GraphQL queries. Very large or deeply nested queries can fail if they exceed the complexity threshold (around 250 in older Sitecore docs). Developers should test complex queries and consider splitting them or trimming fields.

• No persisted or mixed queries: Experience Edge does not support persisted queries. Also, due to a known schema issue, you cannot mix literal values and GraphQL variables in one query; you must use all variables if any are used. Not knowing this rule cost me once a decent amount of time for troubleshooting.

• Payload request size: Very large GraphQL request payloads can be problematic. By default, Next.js APIs have a 2 MB body size limit, which can cause 413 Payload Too Large errors when submitting huge queries. Sitecore suggests raising this (say, to ~5 MB) if necessary. In practice, keep queries reasonably small to avoid frontend limits.

• Include/Exclude paths: When querying site routes (siteInfo.routes), the combined number of paths in includedPaths + excludedPaths is limited to 100. This caps how many different route filters you can specify in one request.

Content & Delivery Constraints

• Static snapshot only: Experience Edge provides a static snapshot of published content. It does not apply personalization, AB testing, or any dynamic/contextual logic at request time. Any logic based on user, session, or query string must be handled client-side. If you change a layout service extension or rendering configuration, you must republish the affected items for Edge to pick up the changes.

• Security model: Edge does not enforce Sitecore item-level security. All published content on Edge is effectively public, so use publishing restrictions in the CMS to prevent sensitive items from being published.

• Single content scope: An Edge tenant covers the entire XM Cloud tenant with a single content scope. You cannot scope queries, cache clears, or webhooks to a specific site. For example, when a cache clear or webhook trigger runs, it applies to the whole tenant’s content, not per site.

• Sites per tenant: Edge supports up to 1,000 sites per tenant. A "site" in this context is a logical group defined by includedPaths/excludedPaths in siteInfo. You cannot define more than 1000 sites in one Edge environment. In practice, the maximum site I met was 300 per tenant and all those were served by a multisite add-on on a Next.Js front-end.

• Multi-site rules: You cannot have two different site definitions pointing to the same start item on Edge. Also, virtual folders and item aliases are not supported on Edge. Content must be published in standard items, and all routes are resolved case-sensitively.

• Locales and device layers: Culture locale codes in queries are case-sensitive (e.g. it-IT ≠ it-it). In the layout data delivered by Edge, only the Default device layer is supported in Presentation data, so multi-device renderings beyond “Default” aren’t included.

Media Limits

• Max media item size: Each media item file size published to Edge is limited to 50MB. Larger media will not be published to Edge; such large assets should be handled via other services like Sitecore Content Hub, or you can self-host them at any preferred blob storage of choice.

• Media URL parameters: The built-in Media CDN on Edge supports only the parameters w, h, mw, and mh for image resizing. No other image transformations, like quality or format changes, are yet available out-of-the-box.

• Case-sensitive URLs: Media item URLs on Edge are case-sensitive. For example, if the item path is Images/Banners/promo-banner.jpg, using lowercase images/banners/promo-banner.jpg will end up with 404. This quirk has caused issues in practice, so be careful with link manager settings that change casing.

• Delivery: Media is delivered via the same CDN cache as content. There is no per-request payload aggregation for media; each media URL is fetched independently (subject to the CDN and TTL rules below).

Caching Rules & TTL

• Default TTL: By default Edge caches content and media for 4 hours each (see contentCacheTtl: "04:00:00" and mediaCacheTtl: "04:00:00"). This means cached responses may be served up to 4 hours old unless cleared.

• Auto-clear: Content and media caches are auto-cleared by default (the contentCacheAutoClear and mediaCacheAutoClear settings are true). In practice, this means a publish or explicit clear will purge the CDN cache so users see new content.

• Custom TTL: You can adjust the cache TTLs via the Edge Admin API. TTL values are strings in D.HH:MM:SS format. For example, setting contentCacheTtl to "720.00:00:00" yields a 720-day TTL, or "00:15:00" for 15 minutes. The default 4h can thus be increased or decreased per project needs.

• Cache clearing: In addition to auto-clear on publish, Edge offers Admin API endpoints to clear the cache or delete content. For instance, you can clear all content or specific items via the API. To use these features, administrators must obtain appropriate Edge API credentials in XM Cloud Deploy.

XM Cloud Platform Limits (Impacting Edge)

• Environment mapping: In XM Cloud, the best practice is a 1:1 mapping of XM environments to Edge tenants. In other words, each XM Cloud environment typically has its own Experience Edge deployment. This means content and API keys are not shared across environments by default.

• Search index: XM Cloud uses Solr, and there is no option to plug in different search technologies for Edge indexing. The connector will only work with Solr indices configured in XM Cloud.

• Admin credentials: XM Cloud Deploy limits the number of Experience Edge Admin API credentials per project to 10. Attempts to create more will fail with an error. Project administrators should plan credential usage accordingly, for example, one per dev/CD pipeline.

• Snapshot publishing: To enable incremental updates, XM Cloud provides snapshot publishing. This ensures that as soon as an item is published, Edge content is updated without a full site rebuild. If snapshot publishing is not enabled, any content changes on Edge require full republishing of affected sites. Developers must enable the Snapshot Publishing feature in XM Cloud to avoid hitting the rate limit on builds.

Baseв on all the above, let's also think about some deployment & publishing considerations that may affect your project:

• Static build (SSG) preferred: Since every uncached request to Edge counts toward the rate limit, Microsoft recommends using Static Site Generation (SSG) and Incremental Static Regeneration (ISR) on the frontend. With SSG, pages are built at deploy-time and served from the host cache, minimizing live queries to Edge.

• Build-time pagination: Very large sites can take a long time to generate. The default sitemap plugin fetches all pages across all sites; projects should use included/excluded paths to limit build-time queries. Otherwise, large volumes of pages hitting Edge during a build can approach the rate limit.

• Publish-time republishing: Because Edge content is static, certain backend changes require republishing. In particular, changes to clones, standard values, or rendering/template configurations won’t reflect on Edge until the dependent items are republished. Plan your release process to include republishes after such changes.

Hope knowing the above helps you plan better!

It may be that you're as annoyed as I am by the way certain things are implemented. Imagine you spin up local XM Cloud in containers, type Up.ps1, hit enter, and go away to make some coffee. It typically takes some time while Docker gets updated images and performs the rest of its business, but right in the middle, it gets interrupted by this:

IMG

The only purpose of this screen is for you to confirm, simply clicking the "CONFIRM" button, and then keep waiting for approximately the same amount of time you already spent. It won't progress until you actually press this button.

That isn't nice, what a time waster, I thought, and started thinking about the ways of automating clicking the confirmation button, so that the entire Docker start process goes uninterrupted. Created a Chrome extension that appeared to be the easiest one, so there I went.

Then I thought it would be a good idea also to automate submissions to the other screens when you process to the portal, namely this one:

IMG

The question comes next question is how to safely keep the email identifier separately from the extension. Browser local storage seems to be a good compromise, so let's go that way. Once users come to the portal for the first time, they enter their email ID as normal. At the time of submission, the extension intercepts the button click and stores the value encrypted. On the next visit to this screen, the value is decrypted and gets automatically submitted into the field by the extension.

I use basic base64 encryption, but with an additional step of character rotation (also known as the Caesar Cipher). This prevents a stranger from a straightforward decipherment of the value taken directly from the local storage. Email ID isn't a very sensitive piece of information, so I am not going wild with protecting its value.

Finally, when the user deliberately logs out by using a drop-down menu from the top right corner, the extension removes the value from the browser's storage. This is done purposely, for example, if one logs out, they usually do that in order to log in as the other user, or maybe they just want out of the system - in any case, we must ensure no further automatic logins persist, and that is exactly what happens.

Currently, it is under moderation in the Chrome store, so you may load this archive and progress with the "Load unpacked" extension, as shown below:

IMG

Hope you like that one. If you have any comments or thoughts, reach out to me!

In the Sitecore world 2025, organizations face a pivotal choice between the Sitecore Experience Platform (XP) – the traditional all-in-one digital experience platform – and Sitecore XM Cloud, Sitecore's modern cloud-native SaaS CMS. This guide provides an expert breakdown of how these options compare across cost, maintenance, architecture, and capabilities, helping CTOs, architects, marketers, and senior developers make an informed decision. I aim to explain the total cost of ownership, hosting models, upgrade implications, development considerations, and special scenarios (such as greenfield vs. existing implementations, compliance needs, performance tuning, etc.) to cut through marketing fluff and fully evaluate trade-offs.

1. XP vs. XM Cloud at a Glance

• High-Level Comparison Table

• Summary of Differences Across Key Dimensions

2. Total Cost of Ownership and Maintenance

• Licensing & Subscription Costs

• Infrastructure & Operations

• Upgrades & Lifecycle Costs

• Personnel and Skills

• Summary: Predictable Cost vs. Control

3. Upgrade and Lifecycle Management

• XP Upgrade Timeline and Support Horizon

• Evergreen SaaS Updates in XM Cloud

• Content and Template Migration Compatibility

• Compliance and DORA Lifecycle Implications

• Planning Upgrade vs. Migration

4. Architecture and Hosting Models

• Hosting Flexibility: XP vs XM Cloud

• Headless Architecture in XM Cloud

• Cloud-Native and CDN-First Approach

• DevOps, Deployments, and Environment Management

• Customization and Extensibility Limits

• Hybrid Use Cases and Parallel Strategies

5. Greenfield Projects vs. Existing Implementations

• 5.1 Greenfield: When to Choose XP or XM Cloud

  • Setup Speed and Development Stack

  • Features, Team Skills, and Cloud Strategy

• 5.2 Existing XP Implementations: Upgrade or Migrate?

  • Feature Usage and xDB Analysis

  • Rebuilding vs. Migrating

  • Front-End, Forms, and Custom Integrations

  • Gradual Migration Options

  • Business Case and ROI Evaluation

6. Compliance and Geographic Hosting Considerations

• GDPR and Data Residency

• HIPAA, PCI DSS, and Regulated Data Use

• Financial Sector: DORA and ICT Risk

• China and Other Geo-Restricted Markets

• Summary: When XP Wins on Localization and Data Control

7. Performance and Optimization Strategies

• Out-of-the-Box Performance

• Caching and CDN Integration

• Scalability Approaches and Overheads

• Personalization Performance Impacts

• Deployment Reliability and Zero-Downtime Releases

• Monitoring, Logging, and Site Resilience

• Optimization Techniques and Real-World Examples

• Total Cost of Optimization

8. Conclusion and Recommendations

• XP: When It Still Makes Sense

• XM Cloud: Future-Ready by Design

• Choosing with Confidence: A Strategic Lens

• Phased Adoption and Preparing for Change

1. XP vs. XM Cloud differences at a glance

Let's start with the table below that summarizes key differences between Sitecore XP and Sitecore XM Cloud:

Table: High-level comparison of Sitecore XP vs. Sitecore XM Cloud in 2025.

As the table suggests, XM Cloud represents a shift to a cloud-native, headless, and service-based paradigm. Meanwhile, XP offers a do-it-yourself, all-in-one environment with maximal control and integrated features (at the cost of complexity). The following sections dive deeper into specific considerations: cost of ownership, greenfield vs. migration scenarios, compliance constraints, and optimization strategies for performance and deployment.

2. Total cost of ownership and maintenance

Licensing & Subscription Costs: One of the first factors to evaluate is cost. Sitecore XP traditionally involves a sizeable license fee, often perpetual or long-term, plus annual maintenance fees. If you already own an XP license, you might only be paying maintenance annually. In contrast, Sitecore XM Cloud is sold as a subscription SaaS product - you essentially pay for a recurring subscription that includes the software and its managed hosting. The XM Cloud subscription cost is generally usage-based, simplified to factor in traffic, number of Content Management environments, etc., which can be a double-edged sword: if your sites see very high traffic, the SaaS fees might scale up, but for moderate usage, you pay only for what you need. XP’s costs, on the other hand, are more fixed in terms of licensing, but infrastructure costs are on you - cloud VMs, SQL licenses, content delivery servers, etc., all that adds to the TCO.

Infrastructure & Operations: With XP, you bear the cost of infrastructure and IT operations. This means provisioning servers (or Azure App Services), managing SQL databases, search servers (Solr), CD servers behind load balancers, plus the manpower to monitor and support them. You might need skilled infrastructure/DevOps personnel or a managed cloud contract. By contrast, XM Cloud shifts most of that burden to Sitecore. The subscription includes the managed Sitecore Cloud portal and hosting of the core CMs and Experience Edge. You don’t pay separately for SQL or Solr – those are hidden behind the actual SaaS product. Operational tasks like OS patches, security updates, scaling infrastructure, and performance tuning at the server level are handled by Sitecore. This can dramatically reduce the maintenance labor on your side and thus lower the operational cost by eliminating the need to manage and maintain your own infrastructure.

However, note that XM Cloud doesn’t include the front-end delivery environment – you still need to host the actual website application (the “head”) on a platform of your choice. For example, if you build a Next.js site, you might host it on Vercel, Netlify, etc. That hosting cost is separate and must be added to your TCO calculations. In an XP scenario, your "front-end" and content delivery are part of the same hosting cost for your CD servers. In XM Cloud, the CMS is hosted by Sitecore within an included subscription, but the rendering host is not. The upside is that front-end hosting, especially static/JAMstack (SSG) apps, can be very cheap and scales with usage. Many find the cost of Vercel to be relatively low compared to keeping multiple high-spec Sitecore CD servers running 24/7.

Upgrades & Lifecycle Costs: Perhaps the biggest cost saver for XM Cloud is the elimination of version upgrade effort. With XP, every few years you face a significant upgrade effort – planning, regression testing, updating custom code, and sometimes content migrations – just to stay on a supported version. These projects incur not only services cost but also opportunity costs - time that could be spent building new features. As an example, a typical enterprise XP upgrade (say from 9.x to 10.x) could take months of work. XM Cloud goes away with this - Sitecore handles all upgrades in the background, delivering improvements continuously. For the customer, this simply means "no more Sitecore upgrades", which brings huge savings in money and time. You’ll always say on the latest version without dedicating effort and budget to get there.

From a lifecycle perspective, Sitecore has committed to supporting XP for several more years - XP 10.4 mainstream support until the end of 2027, and extended to 2030. So you won’t be forced off XP immediately. However, continuing to use XP means you likely will need to upgrade to 10.4 if you haven’t yet, to enjoy that support window, which itself is a near-term cost if you are on an older version. In contrast, XM Cloud’s evergreen nature means the concept of end-of-life is moot – you’re always current. The cost implication is that while you save on periodic upgrade projects, you do need to invest continuously in keeping your solution compatible by testing your integration and front-end when Sitecore updates the backend. Fortunately, backward compatibility in XM Cloud is maintained carefully, and changes are incremental.

Personnel and Skills: Cost of ownership also ties to the team required. Running XP often demands Sitecore-specialized developers, DevOps, server admins, and possibly managed services contracts, which can be costly. XM Cloud shifts the required skill profile: you’ll need front-end developers and perhaps cloud architects familiar with modern deployment, but you might reduce the need for full-time Sitecore ops experts. As noted earlier, the pool of JavaScript/Next.js developers is way larger and often less expensive than the niche pool of Sitecore backend developers. This can lower staffing costs or allow your existing team to focus on front-end innovation rather than low-level CMS tweaks.

In summary, XM Cloud tends to have a lower operational cost and a more predictable subscription model, whereas XP might have a lower software cost if you already own licenses but will incur higher maintenance effort. When calculating TCO, consider a multi-year horizon: XM Cloud’s subscription plus front-end hosting vs. XP’s license and maintenance plus the cumulative cost of VMs, support contracts, and an eventual upgrade. Many organizations find that when factoring in the soft costs (downtime, upgrade labor, performance tuning), XM Cloud delivers savings. But every case is unique – if your XP environment is stable, paid for, and lightly maintained, and your organization isn’t in a position to invest in re-development, the pure dollar savings of XM Cloud might not be realized until further down the road.

3. Upgrade and Lifecycle Management

Upgrades have been the pain for many Sitecore teams historically. With XP, you control if and when to upgrade, but you must upgrade eventually to stay supported, and those projects can be major undertakings. Sitecore XP/XM platforms 10.4 are the "last" of on-prem releases as of today, and Sitecore has pledged continued support, up to 2030, with extended support, which means orgs can comfortably stay on XP 10.4 for the next few years with regular support. If you’re on an earlier version (e.g., 9.3 or 10.1), you will have to upgrade to at least 10.4 to stay within that window, which means a near-term effort anyway. Some companies are choosing to do that upgrade, then evaluate moving to XM Cloud later, while others are considering leaping straight to XM Cloud instead of executing another on-prem upgrade.

XM Cloud’s model is a huge change - you avoid the cycle of "wait for new version -> plan upgrade -> execute -> troubleshoot". From a lifecycle management standpoint, this is a relief: your platform is always current and fully supported. Sitecore delivers updates in a backward-compatible way and typically provides notice of any breaking changes. As a customer, you’ll want to have a process to validate your solution against new releases, but you won’t need to allocate large budgets for these updates.

One thing to consider is data and content migration in the context of moving to XM Cloud. If you are currently on XP and decide to replatform to XM Cloud, that migration project essentially stands in place of an upgrade project. Content can be serialized and migrated, and most customers can bring over all their content, media, and templates into XM Cloud relatively intact, meaning Sitecore has ensured backward compatibility in the content schema. But as we’ll discuss below, your custom code and front-end are not portable as-is. This is less about the platform upgrade and more about rebuilding on a new architecture.

Another lifecycle aspect is vendor support and roadmap. Sitecore’s roadmap for on-prem XP beyond version 10.4 is expected to be mostly maintenance and minor improvements, whereas XM Cloud and the composable SaaS products will get the bulk of innovation - AI-driven authoring assistance, new integrations, etc. If having the latest and greatest features is important, XM Cloud aligns with that path. If your priority is a stable, unchanging platform, XP can offer that at the cost of eventually aging technology.

Finally, consider how compliance regulations like DORA impact the lifecycle. For financial services in the EU, DORA requires that ICT providers (like Sitecore, if you use XM Cloud) adhere to strong resilience and incident reporting. Sitecore is not directly under DORA as a non-financial entity, but they have updated agreements to help customers comply. For an XP on-prem installation, you, as the operator, would bear the burden of meeting operational resilience standards. That includes doing regular disaster recovery drills, ensuring you can recover from incidents, etc. In a sense, letting Sitecore handle that via XM Cloud could simplify compliance - they state they offer "robust security measures to ensure resilience and availability" and will support customers’ DORA obligations. However, some organizations may prefer the control of managing their environment to meet specific internal policies. It’s a trade-off between trusting the vendor’s managed service vs. doing it yourself under your own compliance regime.

Bottom line on upgrades: If you are tired of the upgrade treadmill, XM Cloud is extremely attractive – it ends the cycle of expensive upgrades and ensures you’re always up-to-date. If, on the other hand, you like having full control of when to change your system (like some enterprises freeze tech changes for long periods), XP allows you to stay static despite being unsupported after a point. Many see the writing on the wall that by 2025 and beyond, continuously updated SaaS is the norm, and planning for that model (with proper testing processes) is wiser than clinging to a static version. Sitecore has given XP a generous support timeline, so there’s no immediate panic to switch, but the advantages of not having to plan another upgrade are compelling to most.

4. Architecture and Hosting Models

The architectural differences between XP and XM Cloud are fundamental. Sitecore XP is a monolithic application in the sense that all its services - content management, content delivery, processing, tracking - work together as a single product suite running in a single environment. They can certainly be scaled out individually (multiple CD servers, separate roles), but it remains one big platform under your control. Sitecore XM Cloud is a cloud-native SaaS that embraces a decoupled architecture: the content backend and the presentation frontend are completely separate by design.

Hosting Flexibility (XP): With XP, you have numerous hosting options. You can deploy on-premises on your own hardware, in a private cloud, or on public cloud IaaS. Some run XP on Azure PaaS with Sitecore Managed Cloud platform-as-a-service hosting of XP, or even containerize it on Kubernetes. Single-tenant is the norm – your Sitecore installation is dedicated to you, even if managed by a third party. This flexibility is a double-edged sword: you can satisfy unique requirements (custom networking, specific region, or even specific servers for compliance, integration with legacy systems, etc.), but you also have to manage all the complexity that comes with it. If you need to, for example, deploy a content delivery instance in China or in a DMZ environment, XP lets you do that.

Hosting Model (XM Cloud): XM Cloud is only offered as SaaS by Sitecore – you cannot host XM Cloud yourself. It runs in the Sitecore cloud environment, leveraging Azure and AWS under the hood. It’s a multi-tenant (many customers on the same SaaS platform, logically separated). You get an organization and project space in the Sitecore Cloud Portal where you can create environments, typically production, staging, and development. Sitecore handles provisioning those, and you simply deploy your code and content. There is no concept of installing Sitecore on your server - instead, you deploy your serialization packages and front-end builds to their service. The front-end rendering host, however, is your responsibility to host. The typical pattern is to use a JAMstack approach: for example, host the Next.js app on a platform like Vercel. In fact, Sitecore specifically encourages using Vercel or Netlify for XM Cloud front-ends, noting that these platforms are specifically designed for high-performance websites and integrate very well. Some companies choose to host the front-end themselves, for example, on an internal Kubernetes cluster or Azure App Service, but Sitecore guidance is to leverage modern cloud hosting for that purpose, achieving the best results.

Implications for Cloud-Native Services: Because XM Cloud decouples the roles, you gain the ability to use cloud-native edge networks out of the box. With XP, if you wanted to use an edge CDN or a service like Vercel’s edge functions, you had to configure that on top of Sitecore, often in a limited way. In XM Cloud, the Sitecore Experience Edge service gives globally replicated content APIs, and your front-end can be deployed globally as well. This means things like SSR (Server-Side Rendering) can happen at edge nodes close to users, and static content can be cached on CDNs easily. In XP’s traditional model, the content delivery server itself often lived in one region, or a couple of regional data centers you set up, so global users might have higher latency unless you implemented your own CDN caching layer. XM Cloud largely solves global delivery by design.

Content Delivery Differences: In XP, content delivery is handled by Sitecore’s own ASP.NET application at the CD server running the site. In XM Cloud, content delivery is headless - the CMS does not directly serve end-user pages. Instead, it exposes content via GraphQL APIs, and a separate rendering host application generates the pages. This means if you choose XM Cloud, you are committing to a headless architecture for your sites. The benefit here is flexibility and performance. The trade-off is that assembly effort is required - you have to build a front-end application to consume the content. In XP, if you used something like Sitecore SXA or MVC, a lot of the presentation came out of the box. In XM Cloud, Sitecore provides starter kits for Next.js and other systems, but you will be building the presentation layer with a front-end framework, not with Sitecore’s layout engine. This is a key consideration: organizations comfortable with modern front-end development will see this as liberating; organizations that liked Sitecore’s all-in-one approach to layout and rendering will have to adapt.

DevOps and Environment Management: In XP, you might have multiple environments (dev, QA, prod), each as separate Sitecore instances you manage. With XM Cloud, Sitecore provides environment slots for you. For example, a typical XM Cloud subscription might include 3 environments (production, and two non-prod like UAT and integration). These are easily spun up via the portal. The deployment process is built-in: you connect a source repository (GitHub or Azure DevOps) to the Sitecore Deploy App, and it can automatically build and deploy your code to the XM Cloud environments. This is a more streamlined DevOps experience compared to manually deploying items and code to an XP server. It even de facto supports blue-green deployments for zero-downtime releases when the platform can keep the previous instance running while swapping in the new one.

For a technical team, this means less time setting up build/release pipelines from scratch - Sitecore provides a lot of that out of the box in XM Cloud. For XP, you typically need to create CI/CD scripts or use tools like Octopus Deploy to deploy Sitecore packages, and coordinate things like content serialization, etc., which is more effort.

Extensibility and Customization: In a traditional XP solution, developers can deeply customize the system – pipeline processors, custom Sitecore jobs, and low-level tweaks to how the CMS behaves. With XM Cloud, because it’s a managed SaaS, you should not modify core pipeline code on the server. Customization is achieved either through high-level configuration or by writing code in the front-end or external services. For example, if you had a complex content cleansing pipeline on item save in XP, in XM Cloud, you might implement that via a webhook or by a scheduled external function that uses the GraphQL content API to enforce rules. You also currently cannot use some XP modules or custom Solr indexes in XM Cloud. This means heavy customizations might need re-architecture. The advantage is that you are constrained to more upgrade-safe approaches, but the disadvantage is less freedom to bend the platform to unique needs. This is an architectural philosophy shift: XM Cloud aims for configuration over customization to maintain stability in a multi-tenant cloud.

Hybrid Possibilities: It’s worth noting that some organizations consider a hybrid approach - keeping an on-prem XP for certain sites or functions while starting to progressively build new experiences on XM Cloud. Sitecore's composable lineup is designed to allow mixing: for instance, you could continue using XP for its xDB-driven personalization on an existing site, but launch a new microsite on XM Cloud + Sitecore Personalize and perhaps have both share the same Sitecore CDP for customer data. This is complex, but it highlights that choosing XM Cloud doesn’t necessarily mean abandoning everything at once. That said, running two parallel CMS platforms has its own cost and is usually a temporary state.

In summary, architecturally, XM Cloud is aligned with modern cloud architecture principles - multi-tenant SaaS, globally distributed delivery, microservices, content as a service, personalization as a separate service, etc., whereas XP is a single-tenant application architecture that you tailor to your environment. If your organization values complete control over the hosting environment and data flow, XP offers that, you can even access the database directly, etc., which you absolutely cannot do with XM Cloud. If instead you value simplicity, scalability, and cloud-first design, XM Cloud clearly leads. One key question: Do you require on-premises or specific-region hosting that Sitecore doesn’t support? If yes, that’s a strong case for XP, or at least XM on Managed Cloud, which still gives region control. For example, if you need to host in mainland China for a China site (due to ICP license rules), XM Cloud hosted on Western infrastructure will face significant performance challenges in China and potentially legal barriers, whereas XP could be stood up in China for example on Azure China or Alibaba, to comply. I will talk you through compliance and geographic requirements below.

Choose XM Cloud when you want to offload ops, speed launches, and lock in predictable costs and continuous updates. Stay on XP or self-hosted XM if you need full control over data residency due to the specific compliance/regulations requirements for your organization, have heavy legacy code, or require advanced multi-session personalization today. Either way, your path should match your team’s skills, your compliance needs, and your growth plans.

5. Greenfield Projects vs. Existing Implementations

The decision process can differ significantly if you’re starting a brand-new project (aka greenfield) versus if you have an existing Sitecore XP solution. Let’s address both scenarios:

5.1 Greenfield Projects – When to Choose XM Cloud or XP?

For new digital experience initiatives, the general industry momentum and Sitecore’s own strategy favor XM Cloud. If you are not weighed down by legacy, XM Cloud often makes sense because you can architect from scratch with modern best practices and won’t have to redo things later to keep up with Sitecore’s cloud direction. Key considerations:

• Time to Market & Initial Setup: XM Cloud can be provisioned quickly due to no need to install Sitecore or set up servers. For a new project, this means you get a working CMS environment in days, not weeks. You can also leverage starter templates, such as Sitecore’s Next.js starter kit, to jumpstart development. If speed is critical, this agility is valuable. XP, by contrast, would require setting up at least a CMS and CD server, installing the software, configuring scaling, etc. - a slower ramp-up.

• Future-Proofing: A new project built on XP in 2025 might risk becoming technical debt sooner. Sitecore’s major innovations (e.g., new AI content features, deeper integration of Content Hub, etc.) will likely be cloud-first. Adopting XM Cloud means you’ll automatically get those enhancements. With XP, you might find in a couple of years that the capabilities lag behind unless you integrate additional SaaS components anyway. Starting on XM Cloud sets you on the vendor’s forward-looking path from day one.

• Team Skill Set: Starting a greenfield on XM Cloud is ideal if your development team (or your implementation partner) has strong React/Next.js skills and is comfortable with headless CMS concepts. Many agencies and new developers prefer working with the JAMstack approach as it aligns with modern development practices. If, hypothetically, your team were mostly back-end .NET developers with no modern front-end experience, they might have a learning curve. However, given industry trends, most teams have adapted or can pick up Next.js fairly quickly. Sitecore XP development with MVC and Razor might actually be harder to ramp up for new developers who lack a Sitecore background, whereas XM Cloud development can be more approachable since it uses familiar web tech and just calls an API for content. So, for new projects, assessing your technology comfort is important. In almost all cases, though, I would advocate building new experiences with headless architecture to avoid being stuck in older paradigms.

• Organization Strategy: If your organization has a cloud-first mandate or is embracing SaaS for other systems (CRM, commerce, etc.), starting on XM Cloud fits well. If, instead, there is still a preference for on-prem control (some government or defense projects, for example, might not be ready to put content in a SaaS), then XP could be chosen to satisfy that policy. But in 2025, even regulated industries are increasingly allowing SaaS for CMS after due diligence, because CMS content is often not highly sensitive data (with exceptions). It’s more common to see resistance to cloud for things like customer data, but note, XP itself stores customer data (xDB), whereas XM Cloud (without CDP) does not store much personal data by default. In a way, XM Cloud can be easier to get through security review than XP because it’s mostly content-focused (pages, text, media) rather than PII.

In summary, for new projects, XM Cloud is usually the recommended choice unless you have a very unique reason to deploy and manage everything yourself. It offers faster setup, easier scaling as you grow, and avoids locking you into legacy architecture. One might still choose XP for greenfield if, for example, the project is an internal application that must run on an internal network with no external cloud dependencies, or if the feature set of XP aligns perfectly without needing any of Sitecore’s composable add-ons, and you want to avoid a multi-system solution. But those cases are increasingly rare. Most new digital experience builds want a modern, performant, and low-maintenance foundation, which XM Cloud provides.

5.2 Existing Sitecore Implementations – Stay on XP or Move to XM Cloud?

If you already have a Sitecore XP or XM solution running, the question becomes when or whether to migrate to XM Cloud. This is a complex decision with technical and business angles:

Assess Feature Usage: A critical first step is to determine how much of the XP platform you are actually using. Many Sitecore XP customers purchased the platform for its potential (personalization, xDB analytics, etc.), but over time, ended up using it mostly as a robust CMS, with minimal use of the fancy marketing features. It’s noted that very few organizations have the operational capacity to make full use of XP’s personalization capabilities, not to mention marketing automation. If you find that you are not leveraging xConnect/xDB (no custom profiles, no multi-session personalization rules, no marketing automation campaigns running), effectively, you might be using the XM subset of features already. In that case, moving to XM Cloud will not strip your solution of capabilities you actually use - it will likely be a smoother transition functionally. On the other hand, if you heavily depend on, say, Sitecore Marketing Automation for personalized email campaigns, or you have dozens of personas with tailored experiences on the site based on past behavior, you need to plan how those will be re-implemented. XM Cloud alone won’t provide those; you’d need to bring in Sitecore CDP & Personalize, Sitecore Send (for email), etc., as part of the migration. That introduces additional cost for separate subscriptions and effort to integrate. The upside is that those composable tools are more advanced in their domains, for instance, Sitecore Personalize can do real-time, AI-driven personalization across channels, which could outperform what you built on XP, but it takes work to configure.

Migration Effort – Front-end Rebuild: It must be stated plainly: moving from XP to XM Cloud is not an in-place upgrade; it is essentially a re-implementation: a whole new frontend must be established on a new technology. This is crucial to set expectations with stakeholders. If your existing site was built with MVC and Razor views in Sitecore, those renderings will not run on XM Cloud’s Next.js front-end. You will need to rewrite the presentation layer. Content can be migrated, and your content and templates are intact on the new side, which is a relief, but all the code that rendered that content in XP (layouts, rendering, controllers, etc.) must be redone in the new stack. If you have a large, complex site, this is a non-trivial effort.

On the bright side, you can reuse assets: HTML markup and CSS can largely be carried over into the new front-end, also any client-side JS logic can often be reused. It’s the server-side C# logic that must be translated into the React/Next.js world. Many find that this is an opportunity to clean up and modernize. Maybe your site’s UI could benefit from a refresh - some clients time the migration with a minor redesign so that rewriting the front-end yields a better UX as well. If you recently did a heavy investment in a new XP-based site (e.g., a big redesign last year on XP), the thought of rebuilding it so soon may be unwelcome. In that case, sticking with XP a bit longer to get the value out of that investment is understandable. If your site is due for a redesign or technology refresh anyway, that’s an ideal time to combine it with a move to XM Cloud.

What if you already built your XP site in a headless/hybrid way? For example, some XP projects in recent years used Sitecore JSS with React, essentially treating XP as a headless content source. Such a project is much easier to migrate - in fact, your front-end code (React app) could probably connect to XM Cloud with minimal changes. Just point to the new GraphQL endpoint and adjust API keys. If you’re in that fortunate situation, the migration becomes more about moving content and testing rather than rewriting everything. Essentially, you’d be swapping the content backend from XP to XM Cloud and perhaps replacing XP-specific services (like if you used xDB data, you’d swap to CDP).

Integration and Customization Migration: Look at any integrations your XP solution has - say, CRM integration, eCommerce integration, search providers, etc. If those were done via direct access to XP databases or internal APIs, they’ll all need to be redone to use XM Cloud’s APIs. If you used something like Sitecore xConnect to push data to CRM, in XM Cloud, you might instead use a combination of Sitecore Connect or direct API calls to CDP. Also, any custom modules (perhaps you built custom workflow actions, or you extended the Experience Editor with custom buttons) must be evaluated. Some may not be possible in XM Cloud yet. For instance, Sitecore Forms were not initially supported in XM Cloud - a workaround was required for forms in headless apps. These gaps are closing as Sitecore invests in XM Cloud, for example, forms support was added later, but it underscores that a migration requires a thorough gap analysis.

Cost-Benefit Analysis: From a business perspective, you must weigh the cost of staying on XP vs. migrating to XM Cloud. Staying on XP is not "free" - you will likely need to upgrade to keep support (cost), you continue to run servers (cost), and you may be missing out on performance or productivity gains (opportunity cost). Migrating has an upfront cost of rebuilding and retraining, but promises savings and improvements after. One recommended approach is to build a business case enumerating these factors. For example, if moving to XM Cloud will eliminate $X of hosting costs annually and $Y of upgrade costs every few years, and perhaps increase conversion by Z% due to better performance, can those justify the migration project expense in ROI terms? Often, after a few years, the migration pays for itself just in savings. It’s not always purely financial; agility and future readiness are part of the value.

Organizational Readiness: Change management is also important. Your content authors will have a new interface (though not drastically different, and likely more user-friendly). Your IT team’s responsibilities shift - some roles (server admin) might be less needed, while others (front-end DevOps) become key. You may need to train developers on Next.js and familiarize them with XM Cloud tooling (CLI, serialization via Git, etc.). If your team is not ready, consider investing in training or engaging with a Sitecore partner who has done XM Cloud projects. Some organizations pilot XM Cloud on a smaller project first (migrate a microsite or lesser-trafficked site) to build experience, then tackle the main site. This can de-risk the process.

Gradual Migration vs. Big Bang: You do have the option to move in phases. You could start by downgrading XP to XM, turning off xConnect on your existing instance, and essentially running XP as if it were XM with only in-session personalization. This could simplify your current environment (no xDB) and get authors used to less personalization. Then you could move that to XM Cloud. Or, you could migrate one site at a time if your XP instance hosts multiple sites. In some cases, organizations keep XP running for a period for certain functions (like serving personalization to known users) while launching a new site on XM Cloud for anonymous or new audiences, and then gradually phase out XP. These approaches add complexity but reduce risk by avoiding an all-or-nothing switch on day one.

When does it make sense to stay on XP? After all this, there are valid reasons some will stay on XP in 2025:

• Regulatory Constraints: If you absolutely cannot use a SaaS for CMS due to data control requirements, say for some government agencies or in highly sensitive content scenarios, then XP or perhaps XM in a self-managed mode is the way to go. You maintain full control and can deploy in hardened environments as needed.

• Full Use of XP Features: If you are one of the few that deeply use XP’s marketing suite and it’s running well, you might not want to break what's working. For example, if you have a mature personalization program leveraging historical profiles and automated campaigns that drive real ROI, you might decide to stick with XP until Sitecore’s composable equivalents prove they can meet or exceed that functionality with acceptable cost. In parallel, you might start testing Personalize or CDP to see if a switch is feasible later.

• Short-term Horizon or Alternative Plans: If your organization is, say, 1-2 years away from a broader digital transformation or considering alternate platforms, you might not undertake a migration to XM Cloud now. For instance, some companies on XP are evaluating not just XM Cloud but also competitors or more lightweight CMS options. If you haven’t decided on the long-term platform, you may prefer to keep XP running "as-is" (with maybe a minimal upgrade) as a stop-gap until a larger replatform decision is made. XM Cloud is one path, but some XP customers could even decide to move to a completely different CMS, though that also is a rebuild. It’s outside our scope, but it’s worth acknowledging that XP customers should evaluate all options – in other words, moving off XP doesn’t only mean XM Cloud; it could mean a competitor’s SaaS. Of course, as a Sitecore guide, we focus on XM Cloud as the intended upgrade path.

• Budget Constraints in the Near Term: If the migration cost cannot be justified or funded this year, you might delay until budget allows. In the meantime, ensuring you’re on a supported XP version and maybe optimizing that environment is reasonable.

When does it make sense to move to XM Cloud from XP? Generally:

• When you realize your team is spending more time "keeping the lights on" with XP (patches, Azure costs, troubleshooting scaling issues, etc.) than on building new digital value. XM Cloud frees you from a lot of that maintenance toil.

• When site performance or deployment pain is holding back your digital efforts, and you see that a headless, cloud-native architecture will alleviate those, which it often does, as we’ll cover in optimization.

• When the cost of Sitecore XP (license + infra) compared to the value you get is being questioned, and moving to XM Cloud either reduces cost or increases value (for example, giving marketers a faster way to launch pages, which can translate to business revenue gains).

• If your organization has adopted a composable stack approach – for instance, you already use a separate commerce engine, a separate DAM (Content Hub or others), maybe a separate analytics tool – then XP’s all-in-one value is less important, and XM Cloud will integrate better with a composable ecosystem.

• If you’re looking to modernize the solution, maybe your XP implementation is 5-6 years old, design is stale, and technical debt is high; it might be easier to start fresh on XM Cloud than to upgrade and refactor an aging XP codebase.

One more angle: XM Cloud vs. XP "as XM". Some customers on XP have the option to downgrade their license to XM (content-only) and possibly stick with self-managed XM, which is XP without xDB. This can save license costs while still running the instance yourself. However, that approach gives up the tracking features but keeps the hosting burden. It’s a half-measure that some use if they want to stop running xDB but aren’t ready to go SaaS. In deciding XM Cloud vs staying on XP, consider if running XP just as a CMS is worth it compared to XM Cloud – likely not, because all the maintenance remains, but you’re not leveraging XP’s unique features. In such a scenario, XM Cloud is a better target to eliminate the maintenance as well.

Conclusion for existing implementations: Evaluate what you use, what you gain, and what you’ll spend in a migration. If your XP implementation is underused (typical case: using it as an expensive CMS), the argument to migrate is strong – you can likely cut costs and improve performance by shedding the xDB weight and moving to XM Cloud. If your XP implementation is delivering on its promise and deeply embedded in your marketing operations, plan a migration more cautiously - perhaps wait until Sitecore’s composable tools mature further or do a pilot. But keep an eye on the support timeline; even the best XP 10.4 implementation will face end of mainstream support by 2027. For many, the question is not if to move to XM Cloud or a similar SaaS model, but when - doing it proactively, on your terms, is better than being forced later under time pressure.

6. Compliance and Geographic Hosting Considerations

Every organization must consider regulatory requirements, and the CMS platform choice can be influenced by how well XP or XM Cloud meets those needs. I have discussed several common compliance and localization factors in a separate blog post.

7. Performance and Optimization Strategies on XP vs. XM Cloud

One of the most tangible differences teams experience is in site performance, scalability, and the effort needed to optimize each platform. Both XP and XM Cloud can deliver high-performance experiences, but the approaches differ.

Out-of-the-Box Performance

Sitecore XP: In its traditional mode, XP generates pages server-side for each request unless heavily cached. The performance of your site is tied to the power of your content delivery servers and how well the code and caching are implemented. XP sites can be optimized to be fast, but it requires tuning: item caching, output caching for components, preloading data, etc. Even then, achieving near-instant page loads globally is challenging because the content has to be fetched from the server, which might be far from the user. Many XP implementations struggled to achieve top-tier Google Lighthouse or Core Web Vitals scores due to the inherent overhead of server-side assembly and the weight of the Sitecore rendering pipeline. Getting legacy architectures to match the performance of static sites is extremely difficult.

Sitecore XM Cloud: Performance is a strong point here because of the headless JAMstack approach. Websites built on XM Cloud are typically either static, pre-generated, or server-side rendered at Edge, both of which can drastically reduce latency to users. For example, with Next.js, you can pre-build pages (Static Site Generation) so that they are just HTML files served via CDN, yielding extremely fast first-byte times. Or you use Incremental Static Regeneration (ISR) to update content periodically while still serving cached pages. Even for dynamic content, SSR on a platform like Vercel runs on a global edge network. The result is that an XM Cloud-based site can be as snappy as a static website for most users. It’s common to see improved performance and scalability immediately by moving to a headless architecture - many teams report that after moving to a Next.js + XM Cloud setup, page load times and Lighthouse scores improve dramatically.

Caching and Content Delivery Networks (CDN)

XP Caching: XP supports output caching at the Sitecore rendering level where you can cache renderings by varying criteria, and has a robust object caching for items, media, etc. Using a CDN like Cloudflare/Akamai in front of XP can offload static assets (images, CSS, JS), but caching full HTML pages on the CDN is harder if personalization or login-specific content is involved since pages aren’t one-size-fits-all). Some XP deployments did set up whole-page CDN caching for public pages and used cache-busting or short TTLs to balance freshness. But doing so requires careful configuration to avoid serving the wrong personalized content to users.

XM Cloud + CDN: Here, the CDN (or edge) is integral. When you deploy your front-end on, say, Vercel, it automatically serves content via their CDN nodes around the world. If you pre-render pages, they are essentially static and cached indefinitely until revalidated. Out-of-the-box personalization in XM Cloud is largely in-session, meaning a cached page can be the same for all users, and then personalized bits can be swapped in after load (for instance, via client-side rendering of a personalized component). This strategy means you don’t forego caching for personalization – you just handle it differently with either edge logic or client logic. Additionally, XM Cloud’s Experience Edge caches content data globally, so the API calls themselves are fast. The result: high cache hit ratios and use of edge computing are standard with XM Cloud solutions. You might still fine-tune cache headers and revalidation logic (Next.js provides good controls for ISR and stale-while-revalidate patterns), but overall, achieving global low-latency delivery is simpler.

Scalability

XP Scalability: XP typically scales vertically or horizontally by adding more CD instances behind load balancers. It can handle a high load if properly scaled out, but it requires you to provision enough servers for peak load or use auto-scaling on cloud VMs. There’s also the scaling of the xConnect collection role to consider if you track many interactions – the xDB processing can become a bottleneck under heavy traffic with personalization. Many XP users have experienced that to handle spike traffic for a big one-off event or campaign, they need to spin up additional CD servers and ensure the caching is warmed, etc. That incurs cost for those peak times. Also, session state management and such need to be configured (sticky sessions or a distributed session state server) if using personalization per session.

XM Cloud Scalability: The content management and Edge APIs of XM Cloud are scaled by Sitecore automatically – they run in a cloud that can scale out to meet API demand, and Sitecore handles this as part of the service. Your front-end on Vercel or Netlify scales virtually infinitely - these services deploy your site across countless edge nodes. The result is that handling a spike in traffic is usually seamless: the CDN serves most content without hitting the origin; if many users hit uncached pages, the edge functions scale out. You don’t wake up at 2 am to add servers – it’s handled. There are limits (like API rate limits), but they are quite high, and you can engage Sitecore if you expect an extraordinary load, as they can provision accordingly. In short, scalability is a solved problem in the XM Cloud model: you pay for what you use, but you rarely worry about collapsing under load. Anecdotally, if a marketing team does a huge product launch, an XP setup might require careful load testing and pre-scaling; an XM Cloud setup, if built right, just flows that traffic through global CDNs.

One consideration: in XM Cloud, if you have heavy server-side compute logic in the rendering (like complex data mashups in getServerSideProps in Next), you’ll want to ensure your hosting platform can handle it. But generally, those computations are lightweight compared to what XP’s server did, generating full pages with personalization rules.

Personalization and Performance Trade-offs

XP Personalization: In XP, the more you personalize, the more cache fragmentation you get - every unique combination of personalization rules can cause a cache miss and trigger fresh page generation. This often forced teams to limit personalization to small regions or use "don’t vary by user" on most components. Also, tracking every visitor interaction had a performance cost on the xConnect/shard databases. Many XP sites for performance reasons ended up turning off or limiting xDB tracking on high-traffic pages, or doing personalization only on a subset of pages.

XM Cloud Personalization: With XM Cloud’s embedded in-session personalization, which, under the hood, leverages a lightweight CDP edge instance, personalization is applied at request time but for that session only. For example, you can have a component that shows one variant for visitors coming from Google Ads vs another variant for others - this check can be done on the server (Next middleware or Sitecore’s Edge returns the variant), but the result can still be edge-cached for that session. If using Static Generation, personalization might be applied client-side. Sitecore provides a Personalize JS SDK for XM Cloud that can swap components after page load based on session rules. This means you don’t bust the CDN cache for every user scenario - you might serve the general page and then immediately personalize it in the browser. The result is you keep the fast delivery for everyone, with a slight delay for personalized content loading asynchronously.

If you integrate the full Sitecore Personalize (the SaaS), personalization runs via client-side or edge decision-making, separate from page generation. That tool is built for scale, it can handle high volumes of events and decisions at the cost of some complexity. The user experience can still be very performant because Personalize can respond in tens of milliseconds with a decision, which can be done at Edge or client. Plus, Personalize allows experimenting with different performance vs. personalization trade-offs like using web experiments that load after initial page vs. pre-personalizing content.

In short, XM Cloud allows high performance and personalization, but requires a different implementation approach (client/edge dynamic behavior vs. server-side rendering per user). XP allowed convenient server-side conditional rendering, but beyond simple rules, it could slow things down or reduce caching.

It’s telling that many XP customers never fully used the multi-session personalization because of the operational overhead; they effectively treated XP like XM. Now with XM Cloud plus Sitecore Personalize, those who truly need advanced personalization can have it without burdening the content delivery pipeline for every request – it’s offloaded to a specialized service optimized for that, leaving the main site free to be cached.

One must plan this carefully, though: initial implementations of XM Cloud might just use in-session rules and feel less powerful than XP’s historical personalization. To exceed XP, you’d include Sitecore Personalize, which opens up things like AI-driven segments, but you have to wire it up (the tracker snippet, etc.). From a performance standpoint, the best practice is to keep personalized content lean and use asynchronous loading for heavy personalization where possible so that the baseline site performance remains great.

Deployment, CI/CD, and Reliability

XP Deployments: In XP, deploying code or items could be stressful. Typically, you’d have maintenance windows for deploying new code, especially if it involved database changes. Content freezes often occurred during deployments to avoid conflicts. Some organizations achieved continuous deployment with XP via techniques like slot swaps if on Azure PaaS or by spinning up parallel environments, but it’s not trivial. Often, deployments incurred some downtime or at least required cache warming after, causing a slow response for a period. Also, a failed deployment could require rollback scripts, adding to the risk. DevOps for XP is doable, especially with containers and scripted pipelines introduced in later versions, but it’s a heavy application to deploy - a full XM/XP instance has many services (IDs, reporting DB, etc.) that all have to be in the correct state.

XM Cloud Deployments: XM Cloud was built with modern DevOps in mind. As mentioned, it supports Blue/Green deployment – you can deploy your new code to a staging slot while production keeps running, then switch traffic over when ready. This achieves zero downtime releases, a big win for marketing teams that demand high uptime. The deployment of content changes (like template changes or new items) is done via Sitecore Content Serialization and source control, which can be automated. Many XM Cloud users set up continuous integration such that any commit triggers a build and deploy to a test environment, etc. Sitecore’s built-in pipeline means you don’t have to script the entire release yourself - it will handle packaging the content and code. Additionally, since the front-end is separate, you often deploy that even more frequently, and those deploys are typically instantaneous to end-users because static files get versioned and are atomically published on CDNs.

Reliability: Outages can happen on any platform, but XM Cloud’s architecture and Sitecore’s SLA are geared to high availability. Your content authors work on an Editing host, which is separate from Edge delivery. If Edge were to have an issue, worst case, your site’s content API is down, Sitecore would work to restore it quickly under their SLA, but your editing might still be okay, or vice versa. In XP, if your server goes down, both editing and delivery could be offline unless you built redundancy. With XM Cloud, redundancy is built into the service (multiple instances, failovers, etc.). Also, backups are handled by Sitecore with geo-redundancy as mentioned. On XP, you have to ensure your backup/restore strategy is solid. Many XP incidents have been due to things like a deploy glitch or a missed config causing a site outage – those are less likely on XM Cloud, where infrastructure is consistent and deploys are tested via automation.

One factor is content delivery of XM Cloud is read-only from the perspective of content: authors publish to Edge, but end-users don’t change content on Edge. This separation of concerns increases reliability - the delivery endpoints aren’t doing heavy transactions or content writes, they are mostly serving cached data. XP content delivery sometimes had to handle things like writing personalization data or form submits into xDB, which could impact performance and reliability if xDB had issues. In XM Cloud, if you collect user data, it likely goes to an external system like a separate API or CDP, isolating any issues.

Monitoring and Debugging: With XP, you’d monitor via tools like Application Insights, custom logs, etc., in your own environment. With XM Cloud, Sitecore provides in-app logging and monitoring tools accessible from the portal. You can see logs of your CM instance easily. And for front-end, services like Vercel give real-time logs and metrics. So you get a good view of system health across the stack. Sitecore’s Ops team is also watching the infrastructure. This means you potentially catch issues faster, or Sitecore might alert you to anomalies. To contrast: on XP, if a search indexing service stopped, your team had to notice and fix it; on XM Cloud, if something in the managed service fails, Sitecore will be working to fix it often before you even notice, as part of their service reliability obligations.

Specific Optimization Techniques

To give concrete examples, here are some optimization strategies side-by-side:

• Use of CDN: XP - use a CDN for media and set caching headers for static files; consider HTML caching for anonymous pages with short TTL. XM Cloud - CDN is inherent. Make sure to enable HTTP/2 or HTTP/3, and utilize image optimization on the front-end. Next.js has Image Optimization, which works great with Vercel’s CDN and leverages global edge caching for all content.

• Caching strategy: XP – tune Sitecore’s output cache on renderings (e.g., cache renderings that don’t need to vary per user, use Sitecore’s cache clearing events on publish), increase item cache sizes for heavy traffic, maybe use a cache aside for expensive data (like results of a complex search query). Possibly pre-render some pages to static files if extreme performance is needed, as some have scripted Sitecore to output flat HTML for certain pages. XM Cloud - use Next.js incremental static regeneration for pages that can be cached, which automatically handles revalidating content after publish. Use Next’s API routes or middleware to handle any dynamic segments at Edge. If personalization rules are simple (by geolocation, login status), consider using edge middleware to modify responses on the fly without hitting the origin.

• Scaling for peak: XP - pre-scale by adding CDs and enabling autoscale rules, warm up caches, maybe shorten cache expiration so content updates propagate, but be careful not to overload DB. XM Cloud - mostly auto. If expecting a viral spike, you could increase concurrency limits via Sitecore support or ensure the Edge is primed (perhaps pre-fetch or run a script to hit important pages so they’re cached globally). And ensure your front-end hosting plan supports concurrency. Enterprise tiers of Vercel handle massive concurrency, for example.

• Database performance: XP - ensure SQL is on high-performance tier, maintain indexes, clean up analytics db to keep it slim if you don’t use historical data. Possibly offload analytics to xConnect Cloud or a data warehouse if needed. XM Cloud - the database is managed by Sitecore (in fact, Azure SQL). Not much you do directly, but since XM Cloud doesn’t accumulate interaction data by default, the DB load is mainly content reads/writes, which scale well. You still should organize content well (very large content trees can slow queries in either platform).

• Personalization & Testing: XP - limit number of personalized components per page for performance, batch changes to profile scores to reduce overhead, use content profiling sparingly. Maybe run personalization rules on the CD server that has more resources, not on the edge, if you had multiple regions (with XP, if you deployed separate instances per region, each runs personalization independently). XM Cloud – take advantage of Sitecore Personalize’s ability to do heavy lifting outside the page request. For example, run segmentation nightly in CDP rather than computing on the fly. Use client-side experiment scripts for A/B tests, which utilize CDN edge networks to distribute variants quickly. Essentially, shift intensive personalization computations to pre-compute or client side, keeping the initial page load path as light as possible.

In terms of real-world outcomes, expect that an XM Cloud solution can achieve sub-second time-to-first-byte globally, very high throughput because most hits don’t touch the origin CMS, and handle usage spikes without breaking a sweat. In contrast, an XP solution might handle typical loads fine but needs careful babysitting to ensure similar metrics under duress, and often falls back to degraded mode (e.g., turning off personalization during high load, or relying on CDN cached pages that might not reflect the latest content if publishing frequently).

Cost of Optimization

It’s worth noting the cost implications of these performance strategies:

• With XP, scaling up for performance means more servers or higher Azure bills. Idle capacity can cost you in slow periods. Also, high performance might demand a CDN subscription and possibly third-party monitoring tools, extra costs.

• With XM Cloud, performance is largely built-in. You might pay a higher tier on Vercel for more edge function memory or a larger CDN usage, but you’re paying for actual usage (which corresponds with benefiting from that usage). The cost scales more directly with traffic. And you typically won’t need to invest in as much custom optimization labor. Development on Next.js is impressively fast compared to pure .NET development in terms of delivering features. That agility includes performance improvements - implementing a lazy-loading image or code-splitting in Next.js is straightforward and yields immediate performance gains, whereas optimizing an MVC site might involve more custom work.

Reliability and uptime are also part of performance. XM Cloud’s reliable deployment and infrastructure reduce the chance of outages from deployments. In XP, some teams schedule deployments at midnight Sunday and hope nothing goes wrong to avoid impacting users, as that is a performance consideration too. If you have to deploy during off-hours only, your ability to fix issues or update content quickly is hampered. XM Cloud’s zero-downtime deploys mean you can push improvements any time, which can be critical if there’s a high-priority content or code change.

8. Conclusion and Recommendations

Choosing between Sitecore XP and Sitecore XM Cloud in 2025 ultimately comes down to aligning the platform with your business priorities, technical requirements, and long-term digital strategy. Both options can deliver world-class digital experiences, but they do so in very different ways:

• Sitecore XP offers full control, a rich integrated feature set, and proven capabilities as an all-in-one DXP – at the cost of higher maintenance, heavier infrastructure, and a more monolithic approach. It shines in scenarios where you need to retain data/control on-premises, or where you are leveraging all of its built-in marketing features under one roof. If you have an established XP solution that meets your needs and you can manage the upkeep and upcoming upgrades, XP remains a viable choice in the near term, especially given continued support until 2027+. Certain regulatory or localization needs may necessitate XP, for example, in China deployment or an isolated network. Just keep in mind that sticking with XP means accepting periodic upgrades and that new Sitecore innovations will be slower to reach you.

• Sitecore XM Cloud represents the modern, cloud-first direction – reducing total cost of ownership through managed services, boosting agility with continuous updates, and enabling top-notch performance via headless architecture. It is best for organizations that want to focus on delivering content and customer experiences rather than managing servers. If you are starting fresh, XM Cloud is likely the better investment for the future. If you are on XP and finding that infrastructure and upgrades are eating into your budget or slowing you down, moving to XM Cloud can refocus your efforts on actual customer-facing improvements. For businesses that prioritize speed, scalability, and the ability to integrate best-of-breed services, XM Cloud is an excellent fit. It does require accepting a SaaS model and building up modern development skills, but the payoff is a more nimble digital platform.

When to choose XP:

• You require a self-hosted environment for compliance or policy reasons that XM Cloud cannot meet, like specific in-country hosting or no external cloud allowed.

• You extensively use XP’s multi-session personalization, marketing automation, and other xConnect-driven features, and transitioning those to composable alternatives is not feasible in the short term.

• Your team and infrastructure are already optimized for XP, and the system is stable, with an upgrade to 10.4 planned and no major growth challenges – essentially, "if it isn’t broken" and you don’t urgently need what XM Cloud offers, you may continue with XP while planning for the longer-term future.

• You need unlimited customization of the CMS core - for example, you have deep custom integrations that hook into Sitecore pipelines or data layers that would be hard to re-implement with XM Cloud’s constraints.

When to choose XM Cloud:

• You want to minimize infrastructure and upgrade overhead – say you have a small IT team or want to reallocate your developers from maintenance to innovation. The automatic upgrades and managed hosting will benefit you greatly.

• Site performance, global reach, and rapid deployment are top priorities – for instance, if your marketing team is pushing daily updates or campaign launches across regions, XM Cloud’s architecture will support that with fewer hiccups.

• You are undertaking a major redesign or replatform anyway – an ideal time to switch to XM Cloud and build with the latest tech rather than refactoring an older XP solution.

• Your digital strategy is “composable” – you might already be using or plan to use products like Sitecore Content Hub, Sitecore Personalize, or even non-Sitecore services. XM Cloud will integrate smoothly via APIs, whereas XP might feel comparatively siloed or require connectors.

• You have a greenfield project and want to start on the right footing for the next 5-10 years. Adopting XM Cloud ensures the platform itself won’t become outdated in that period, and you’ll get continuous improvements.

A balanced, experience-driven perspective: Many seasoned Sitecore architects or Sitecore MVPs like myself advise evaluating how much "platform" you really need. In the past, some chose XP for safety since it had everything out of the box, but ended up not using half of it. With budgets tighter and digital experience needs evolving faster, it often makes sense to choose a leaner, more flexible setup, which is XM Cloud plus only the additional services you truly need. As one real-world consideration, if you can count the number of XP features you actively use on one hand, it’s a strong signal that XM Cloud or even XM on-prem would be more cost-effective. Sitecore itself notes that without xConnect, XM has a smaller footprint and TCO than XP. That logic extends to XM Cloud, which is essentially XM plus the SaaS benefits.

On the other hand, if your organization has squeezed substantial value from XP’s integrated suite – say you have marketing teams running automated campaigns and personalization that directly drive revenue – then you shouldn’t jump off XP until you’re confident you can reproduce or enhance that capability in the new model. It might mean a phase where you introduce Sitecore CDP/Personalize alongside XP (that is possible) to gradually transition without losing functionality.

Prepare for change: If you do decide to move to XM Cloud, approach it methodically. Plan the migration or build with a clear scope, engage experienced Sitecore partners or experts who have done it, and consider doing a pilot or proof-of-concept first. This will surface any challenges early (like missing features or integration points) and allow your team to learn XM Cloud’s nuances. Also, budget for the learning curve – maybe get training for your developers on Next.js and Sitecore Headless. The good news is that many have done this before, and the community has produced guidance and tools such as scripts to migrate content or patterns to implement common XP features in XM Cloud. Leverage those resources to avoid reinventing the wheel.

Final thought: The direction of the market is clear - cloud-native, composable DXP is the future, and Sitecore XM Cloud is a centerpiece of that strategy. However, Sitecore acknowledges that each customer’s journey is unique. They are supporting XP for years to come precisely because they know a forced march to the cloud is not feasible for everyone overnight. So, evaluate your own readiness and needs. You might choose to run XP and XM Cloud in parallel for a time, or move fully to XM Cloud now, or stay on XP a bit longer, but with a roadmap to evolve. What’s important is to make an informed, conscious choice rather than simply defaulting to one or the other. Hopefully, this guide has illuminated the concrete differences in costs, effort, capabilities, and optimizations so you can make that choice with clarity.

No matter which path you choose, success will hinge on execution: an optimally tuned XP can still deliver excellent experiences, and a poorly implemented XM Cloud site could underwhelm. The platform is an enabler, but the vision and strategy you apply are what create standout digital experiences. Align the choice to your strategy: if agility, scalability, and continuous improvement are paramount, XM Cloud aligns well; if complete control and one-stop capabilities are paramount, XP can still serve. Either way, ensure you have the right skills and partners to get the most out of the platform.

In closing, for most organizations in 2025, Sitecore XM Cloud will be the logical choice moving forward, with Sitecore XP remaining a reliable but eventually legacy option. Adopting XM Cloud sets you on a course to leverage Sitecore’s evolving innovations without the operational drag – an appealing proposition for those looking to accelerate their digital maturity. Evaluate carefully, plan thoughtfully, and you’ll make the choice that best empowers your digital experience goals.

What is a Pipeline Profiler?

Firstly, let's answer what a pipeline is. A pipeline in Sitecore is essentially an ordered sequence of processes (called processors) that run to perform a specific task in the system. Sitecore’s pipeline profiler is a built-in diagnostic tool that tracks how long each pipeline and processor takes to execute. 

Why is this useful? In complex Sitecore solutions, it can be difficult to know what exactly is happening inside the pipelines at runtime, especially after deploying to a cloud or container environment. Pipeline profiling helps answering questions like: "Is my custom pipeline processor actually running, and in the correct order?" or "Which part of the request pipeline is slowing down page loads?". In other words, it provides visibility into the inner workings and performance of Sitecore’s processing framework.

By default, pipeline profiling is disabled for performance reasons, but when enabled, it records metrics like execution counts and timings for each pipeline processor. This data is exposed via an admin page so you can see which pipelines or steps are consuming the most time. 

Why and When to Enable Pipeline Profiling

You should consider enabling pipeline profiling only when you need to diagnose or debug pipeline behavior, especially for diagnosing bottlenecks and verifying pipeline behavior in real scenarios. It’s not something to leave on all the time (more on that in considerations below), but it’s invaluable as a temporary diagnostic tool during development, testing, or troubleshooting.

How to Enable Pipeline Profiling in XM Cloud (SaaS and Containers)

You just toggle it via a config patch or environment setting.

<add key="env:define" value="Profiling" />

This above env:define setting named "Profiling" acts as a flag that enables the pipeline profiling configuration. Use the full configuration patch file, as below to enable the profiler:

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <!-- Enable pipeline profiling -->
      <setting name="Pipelines.Profiling.Enabled">
        <patch:attribute name="value">true</patch:attribute>
      </setting>
      <!-- (Optional) Enable CPU time measurements for profiling -->
      <setting name="Pipelines.Profiling.MeasureCpuTime">
        <patch:attribute name="value">false</patch:attribute>
      </setting>
    </settings>
  </sitecore>
</configuration>

How to access the Pipeline Profiler page?

After enabling profiling and restarting, log in to Sitecore and navigate to the special admin page on your CM instance URL: /sitecore/admin/pipelines.aspx. You must be logged in as an administrator to access it, like you do for other admin pages.

You should see a table of all pipelines that have executed since startup. There's a Refresh button on the page; clicking it will update the stats to include any pipelines run since the last refresh.

IMG

You can filter by pipeline name or simply scroll to see various pipelines such as initialize, renderLayout, item:saved, publishItem, etc. Each pipeline row can be expanded to show all the processors within it, in the order they execute. The key columns to pay attention to are:

• #Executions: how many times that pipeline or processor has run since the last reset. For example, after a site startup, you might see the initialize pipeline ran once, whereas something else runs for every HTTP request, so it could be, say, 50 if you've made 50 page requests so far.

• Wall Time / Time per Execution: the total time spent in that pipeline or processor, and the average time for a single execution. It is particularly useful for spotting slow components; if a single run of a processor takes, say, 500ms on average, that’s a potential performance hot-spot to investigate.

   

• % Wall Time: the percentage of the pipeline’s total time that a given processor accounted for. This helps identify which processor within a pipeline is the major contributor to the total time. For example, if one processor is 90% of the pipeline’s execution time, that’s your primary suspect.

• Max Wall Time: the longest single execution time observed for that pipeline or processor. This is useful to identify spikes or inconsistent performance. If the max time is significantly higher than the average, it means one of the executions had an outlier slow run.

Remember to Remove/Undo the Config! If you added a config patch or environment variable for profiling, make sure to remove or disable it after you're done. For example, in XM Cloud SaaS, that means taking it out of your code (and redeploying) or toggling off the environment variable in your cloud portal settings. This prevents someone from accidentally leaving it on. It also ensures your deployments are clean and you don't want to carry a debugging setting to higher environments unknowingly.

Enabling pipeline profiling in XM Cloud is straightforward and gives Sitecore developers a powerful lens to observe the inner workings of the platform. Whether you’re chasing down a production slowdown or ensuring your custom pipelines run as expected, this feature can save you countless hours. As always, use it wisely!

XM Cloud is a purely headless CMS, so your front-end app (say, a Next.js site) calls Sitecore APIs for the layout and content rather than having on spot, similarly to what traditional monolith CMS page requests did. 

IMG2

At the same time, this approach brings a variety of ways that content+layout could be consumed, depending on which particular endpoint is being used and the mode it serves. I wrote this post to explain the options and differences between them.

GraphQL Endpoint Working on a Local CM in Docker containers

When you run your app locally with Docker containers, all content calls go straight to your local CM instance. For example, a Next.js app using JSS or Cloud SDK might fetch layout or GraphQL data from the local CM at endpoints like:

• /sitecore/api/graph/edge (the GraphQL Preview API on the local CM)

• /sitecore/api/authoring/graphql/ide (the URL of GraphQL Playground IDE on the local CM for querying)

In other words, your locally running headless app pulls content directly from the local Sitecore CM, including any unpublished edits. You’ll usually develop this way to see live changes immediately. Notably to say, there is no mock/substitute of Experience Edge with local Docker containers, which means you only have a preview endpoint with local container-based development.

Cloud Delivery API

The Delivery API for each of the cloud environments has two modes: Preview, which runs on the CM itself, and Live from Experience Edge. Once content is published from any XM Cloud environment, it lands on Experience Edge for that environment – the cloud GraphQL delivery service. In practice:

• Preview API: Every XM Cloud environment (dev, QA, etc.) has a preview GraphQL endpoint on its CM, at */sitecore/api/graph/edge. Content fetched here includes unpublished draft changes. Editors use this to see a work-in-progress.

• Live API: The live GraphQL endpoint is on Experience Edge service at https://edge.sitecorecloud.io/api/graphql/v1​. This serves only published content – essentially a read-only high-performance delivery API.

In other words, no publish = no live content. If you never publish your edits, the live API returns nothing (or only older content, if pre-exists), because Edge only knows what’s been pushed from the related CM.

Key differences:

• Endpoint paths: Preview GraphQL is /sitecore/api/graph/edge while Live Edge GraphQL operates at /api/graphql/v1.

• Publishing impact: Only published items show up on the live API.

• Managing content through APIs: it is important to mention that Authoring and Management API relates only to the CM and cannot be applied to Experience Edge directly.
• Authentication key: preview environments rely on API Key for authentication, while Live requires Experience Edge Token. I explain this below:

When your headless app connects to a Preview endpoint (/sitecore/api/graph/edge) on your local Docker CM or cloud CM for Dev/QA/Prod, it must send an API Key for authentication. API Key is effectively an ID of an item located under /sitecore/system/Settings/Services/API Keys folder

When your headless app connects to the Live Delivery API (/api/graphql/v1) on Experience Edge, it must instead authenticate with an Experience Edge Token. Edge tokens are environment-specific. Without a proper Edge Token for a given particular environment, the /api/graphql/v1 endpoint will reject requests.

This table illustrates what 

One of the easiest ways to reach out to specific environmental access keys is through the Deploy App:

IMG1

Setting up multiple preview environments

If you want multiple preview environments for dev, QA and prod, you’ll need separate deployments of your front-end. Essentially, each environment needs two “versions” of your headless app: one pointing at the CM in preview mode and one pointing to the content published to Edge (live mode). For example, in a project with 3 environments (Prod, QA, Dev), this could mean:

• Dev-Live (queries Edge)

• Dev-Preview (queries Dev CM)

• QA-Live

• QA-Preview

• Prod-Live

• Prod-Preview

That’s up to 6 different sites running your headless app: 3 envs × 2 modes. Each one has different environment variables/URLs. It sounds like a lot, but it's pretty easy and quick to configure and lets each team see exactly what they need.

Hope this post explains how different modes and environments operate well together.

Distinguish Between Definition and Content Items

In XM Cloud, serialization is primarily a developer/ops concern, not a task for content authors. Developers and DevOps engineers use the Sitecore CLI to manage definition items (templates, layouts, SXA settings, etc.) in version control, whereas content authors continue to work in the Content Editor/Experience Editor and publish content via the usual publishing pipeline.  In contrast, content authors simply publish content; they shouldn’t be expected to run CLI commands: we reserve the CLI workflow for dev-defined items, and let content authors handle content via Sitecore’s authoring tools.

In XM Cloud, all configuration and template definitions are items in the Sitecore tree - many of these are delivered as items-as-resources in protobuff resource files. By default, XM Cloud provides a base set of definition items in resource packages; custom definitions (such as your templates, renderings, layouts, SXA component definitions) should be added via serialization. The CLI can push/pull any item in the tree, so treat your custom definitions like any other serialized item. For example, you would include custom layouts (under /sitecore/Layout/Layouts/YourTenant), rendering definitions (/sitecore/Layout/Renderings/YourTenant), SXA rendering variants, themes, and placeholder settings in your modules. In fact, the Sitecore docs note that SCS modules allow you to "organize and separate serialized items according to their purpose".

You generally do not manually transfer definitions by hand; instead, you define them in your project and let the CLI handle serialization. As a special tool, Sitecore provides an Items as Resources CLI plugin (dotnet sitecore itemres) to package definition items into *.DAT resource files, but in most cases, you simply let sitecore ser push pack the YAML and deploy it to XM Cloud.

Note, that some environment-level settings are not items. For example, custom Sitecore security domains live in a config file on the server, not in the content tree, so they cannot be serialized or deployed via CLI. In those cases, you must handle them outside of SCS.

In summary: treat definition items as code: include them in your serialization modules and commit them, and let the Sitecore CLI bundle them into the XM Cloud resource IAR package. Content items, by contrast, should be managed by content workflows.

Content Serialization

Generally, don’t serialize day-to-day content. XM Cloud follows the old wisdom of treating content differently from code: the CLI is not intended as a general content migration tool. Instead, content authors create or edit content items in the CM interface or Pages Builder and then publish them to delivery targets. Serializing content will lead to conflicts and source-control bloat.

That said, there are a few exceptions where you might include minimal content stubs or settings in serialization. For example, it’s common to serialize the homepage item itself so that a brand-new environment has the correct site entry point immediately upon first serialization. You'd want to explicitly include the tenant and site root with CreateAndUpdate operations - this ensures that new environments get a placeholder homepage item (and updates propagate), without overwriting content. You might also serialize certain settings or dictionary items that are truly "configuration" (say, a language items folder or a set of shared data templates). But actual content (articles, product entries, news items) should be kept out of serialization.

In practice, restrict content serialization to very small, static subsets (often at most the single site-root node) and mark them as create-only or create-and-update. For example:

{
  "name" : "TenantA_SiteRoot",
  "path" : "/sitecore/content/TenantA/SiteA,"
  "scope": "singleItem",
  "allowedPushOperations" : "CreateUpdateAndDelete"
}

This would ensure the /SiteA item exists in all environments, but leave its children alone. The rest of /sitecore/content/TenantA/SiteA descendants (actual page content) would not be included.

Remember that after you push any content items, you still must publish them to make them live. The ser push command only writes into the CM database; it does not publish to Experience Edge. To serve content, you must run a publish command (dotnet sitecore publish --target Edge).

Summarizing: Limit content serialization to definition items with some exceptions like an empty homepage or settings, and let normal publishing handle real content.

Also, "do not include vanilla XM Cloud items – include only custom-created items". Content changes by authors should flow through Sitecore’s normal publishing workflows, not through SCS commits.

Serialization Scopes

Sitecore CLI modules use scopes to control how deeply an include or rule applies. The scope property can be one of:

• SingleItem – only the specified item itself (no children).

• ItemAndChildren – the item plus its immediate (one-level) children.

• ItemAndDescendants – the item and all levels of descendants - the full subtree. That is a default value.

• DescendantsOnly – all descendants of the item, but not the item itself.

• Ignored – skips this branch entirely, used in rules to exclude subtrees.

For example, suppose you include a path /sitecore/content/TenantA/SiteA in a module. If not specified, that is ItemAndDescendants by default, so it would pull the entire site tree. If you want only the root item and none of its children, you would add a rule with "scope": "SingleItem". Conversely, to skip an unwanted subfolder, you could use "scope": "Ignored" on that path.

A concrete example of a rules section might look like:

"items": {
  "includes": [
    {
      "name": "SiteA",
      "path": "/sitecore/content/TenantA/SiteA",
      "allowedPushOperations": "CreateUpdateAndDelete",
      "rules": [
        { "path": "/sitecore/content/TenantA/SiteA/Data", "scope": "Ignored" },
        { "path": "/sitecore/content/TenantA/SiteA/Home", "scope": "Ignored" },
      ]
    }
  ]

This says "include the SiteA item (with all descendants by default) but ignore the entire Data and home Page subfolders." In practice, you’ll define scopes to precisely include what you need: broad (ItemAndDescendants) for full branches, and narrow (SingleItem or Ignored) to exclude or limit depth.

Serialization Order and Modules

Since you organize your serialized items into modules within each .module.json file in the Sitecore CLI, you must somehow define which modules depend on stuff from others. This each module can have an optional references list to other modules. The CLI uses these references to enforce a load order. For example, if you have a Foundation module with templates (Foundation.CoreTemplates) and a Feature module that depends on them (Feature.Shop), you would write:

{
  "namespace": "Feature.Shop",
  "references": [ "Foundation.CoreTemplates" ],
  "items": {
    "includes": [
      { "name": "ProductTemplates", "path": "/sitecore/templates/Feature/Shop", "allowedPushOperations": "CreateUpdateAndDelete" }
      // ...
    ]
  }
}

By specifying "references": [ "Foundation.CoreTemplates" ], you ensure the CLI pushes/pulls Foundation templates first, then the shop items. Wildcards are allowed ( "Foundation.*") to reference all Foundation modules. If you omit references, the CLI may process modules in alphabetical or file order, which can lead to missing-dependency errors, such as pushing a rendering before its template exists.

In practice, follow Helix conventions: have a base module for core templates/branch templates, then project-level modules that reference it and use the references array in each module to declare dependencies.

Alternatively, you can also tag modules in CLI commands (with -i) to run only subsets, but the fundamental sequencing comes from references. If dependencies are missing or misordered, you will see errors during push (like “item not found” or unresolved references). Always review dotnet sitecore ser info to verify your module graph.

SXA Serialization Considerations

When using SXA in XM Cloud, treat SXA definition items as code. As usual, you should serialize your SXA component definitions and site structure, but not your actual content. Key SXA assets to include are:

• Rendering Variants and Templates: Anything under /sitecore/layout/Rendering Variants/... and the SXA Page/Partial designs under /sitecore/layout/Layouts/... or /sitecore/content/TenantName/SiteA/Presentation/....

• Placeholder Settings and Layouts: SXA uses placeholders and page layouts, which live under /sitecore/Layout or under the site; include those as part of layouts and placeholders sections.

• Themes and Styles: If your SXA site uses a custom theme (under /sitecore/media library/Themes or the SXA Theme item), serialize that.

• SXA Site Settings: Under each site (e.g. /sitecore/content/Tenant/SiteA/Settings), include any site-level settings items that define colors, etc., if they are required for deployment.

• Site Templates: SXA allows site templates in the dashboard; if you have custom site templates, serialize those under /sitecore/templates/Project/....

Do not serialize authored page content (articles, products, etc.) from SXA sites. Also consider shared vs. site-specific: if multiple sites under one tenant share variants or partial designs, put them in a shared module (under the tenant node). If a design is only for SiteA, put it under the SiteA module. In general, follow the same include rules as above, putting SXA assets under your project/feature paths. For example, include renderings and placeholder settings under /sitecore/Layout/Renderings/Project/... and /sitecore/Layout/Placeholder Settings/Project/... - these would cover your custom SXA renderings and placeholder definitions as well. By version-controlling SXA assets in the CLI, you ensure that your site designs, variants and styles are consistent across environments, while leaving content (pages and datasources) to the content pipeline.

Module Organization

For the multisite and especially multi-tenant data architecture, it becomes crucial to organize your modules and serialization in a totally isolated way. Thus, everything becomes self-contained so that removing one site/ tenant folder does not affect the rest of the serialized assets. To achieve that, I would recommend doing this:

• Organize all the assets under a specific folder, for example: authoring/items/client
• All the relevant modules fall into this folder. I usually split them into three groups: client.global.module.json; client.components.module.json and client.site.module.json
• Each of these module files must include a path directive, which effectively defines a subfolders structure: "path": "components" or "path": "site". This is the most crucial bit.
• Nothing else exists immediately under authoring\items folder other than clients and areas; typically there would be a global folder followed by client1, client2, etc.

Every organization must consider regulatory requirements when choosing how to deploy Sitecore. The choice between a self-managed Sitecore XM/XP and Sitecore XM Cloud can be influenced by how well each model meets various compliance and data hosting needs. Choosing between XP and XM Cloud is a trade-off: XP gives you full control over data location and security, while XM Cloud delivers built-in compliance where it’s available. Below is a concise comparison of how major regulations affect each model, followed by deeper details.

This post provides an in-depth look at key regulations and data sovereignty concerns, comparing their impacts on traditional self-hosted Sitecore XM/XP versus SaaS XM Cloud deployments. I will cover major data privacy laws: GDPR, UK GDPR, CCPA, industry-specific regulations: HIPAA for health data, PCI DSS for payment data, DORA for financial services, localization laws: Russia, China, Brazil, etc., emerging AI regulations, and data encryption/sovereignty considerations. A comparison table is included at the end to summarize how each issue affects XM/XP versus XM Cloud.

GDPR and UK GDPR

GDPR – the General Data Protection Regulation in the EU – and its UK counterpart (the UK GDPR, retained from EU law post-Brexit) impose strict rules on handling personal data. Both laws are similar in core principles, but they apply in different jurisdictions: EU versus UK. Organizations using Sitecore need to ensure compliance in terms of data processing roles, user consent, data subject rights (access, deletion, etc.), and data residency.

Data controller vs. data processor

• A data controller decides the purposes and means of processing personal data and bears primary liability for compliance.

• A data processor acts only on the controller’s instructions, must secure data appropriately, and assist the controller in meeting its obligations.

Why it matters
Controllers face direct fines and enforcement actions if they fail to collect valid consent, uphold data-subject rights or secure data properly. Processors are liable only for processor-specific duties (security, breach notification, sub-processor management) but must still be tightly contracted and audited.

• XP

  • You act as both controller and processor. You choose EU or UK data centers (or on-prem), enforce TLS, encrypt databases at rest, maintain records of processing activities, conduct impact assessments, and sign DPAs with any cloud or analytics vendors.

  • You are obtaining valid consent for tracking cookies since Sitecore XP, by default, can track visitors via analytics databases and identify repeat visits. You also deploy consent banners

  • You build workflows for subject-access, rectification, and delete a contact’s data from the Experience Database upon request. Sitecore provides tools like the xConnect API to help delete or anonymize contact data, but it’s your job to use them appropriately.

  • If using a cloud provider (Azure, AWS) to host, you must ensure EU->US data transfers, if any, comply with GDPR transfer rules. Hosting entirely within the EU avoids needing special measures. For UK personal data, hosting in the UK or in countries with UK adequacy decisions facilitates compliance.

• XM Cloud

  • You remain the controller; Sitecore is the processor. Sitecore encrypts data by default, segments customer data in EU or UK regions, and provides a processor agreement covering lawful transfers (adequacy decisions or SCCs), breach notifications, and sub-processor transparency.

  • Your team focuses on capturing valid consent, configuring Sitecore’s privacy settings, and using its APIs to fulfill data-subject requests.

  • With XM Cloud, you cannot self-select the exact data center location in the same way as self-hosting, but Sitecore offers regional hosting options. For example, a European client’s instance can be hosted in an EU data region, ensuring data stays in Europe to comply with GDPR’s data locality expectations.
  • If you require UK-only data residency, confirm if Sitecore can host specifically in the UK or an EU region that is acceptable under UK GDPR.

CCPA and CPRA

For organizations handling personal information of California residents, the California Consumer Privacy Act is a key regulation. CCPA focuses on data disclosures, the sale of personal information, and consumer rights to access or delete data. While CCPA doesn’t mandate data residency, it imposes obligations on how data is collected and shared.

• XP

  • You implement “Do Not Sell or Share” links, provide the required privacy notices on your website, detect opt-outs in your code, map personal data across xDB, and delete or export records via Sitecore APIs or SQL queries.

  • CPRA adds rights to correct inaccurate data, limit the use of sensitive personal information, and receive detailed disclosures.

  •  

    CCPA’s concept of “service provider” would apply to any vendors you use. If you host Sitecore on a cloud platform, that cloud vendor is your service provider (they process data only on your instructions). You should have a data processing addendum in place with them that meets CCPA’s service provider criteria (major cloud providers do offer these). Sitecore, as the company, typically wouldn’t be directly involved unless you send data to Sitecore support.

• XM Cloud

  • Sitecore is your contracted service provider and certifies that it never sells or shares data. You still build front-end opt-out logic.

  • For consumer requests, you invoke Sitecore’s deletion/export endpoints or submit a support ticket for complete removal, including backups.

  • Opt-Out of Sale/Share: Since Sitecore Cloud itself is a service provider, data stored there isn’t a sale, but any other integrations of third-party ad networks via the site that could be considered a "sale" of data. That’s outside Sitecore’s scope, but you might use Sitecore to manage tags or content that could involve personal data transfers. Ensure you have a consent management solution for your website.
  • XM Cloud being headless means you might implement a separate consent banner in your front-end application.
  • CCPA does not require local storage in California, so having data in a Sitecore data center, even if in another state or in the cloud abroad, is fine as long as protections are in place. Typically, a U.S. company using XM Cloud would choose a North America region for data residency.

HIPAA (Past & 2025 Updates)

If you are in the healthcare sector or otherwise deal with Protected Health Information (PHI) in the U.S., compliance with HIPAA (Health Insurance Portability and Accountability Act) is required. HIPAA safeguards health information in the U.S. under three rules—Privacy, Security, and Breach Notification. Recent guidance expanded "PHI" to include behavioral tracking on health sites, and enforcement ramps up in 2025.

• XP

  • Host on a HIPAA-compliant platform with a Business Associate Agreement (BAA).

  • Encrypt all PHI in xDB and analytics stores, enforce strict role-based access, maintain detailed audit logs, train staff on HIPAA policies, and have a breach-response plan.

• XM Cloud

  • Sitecore has third-party attestation and signs a BAA, applying required safeguards for encryption, patching, access controls, and breach processes.

  • You focus on front-end consent capture, limit tracking to necessary PHI, and use Sitecore’s secure controls for record management.

  • Customer Responsibilities Remain: Even with Sitecore’s platform being HIPAA-ready, you, as the healthcare organization, must still use it properly.
  • You can still use personalization, but do so under the umbrella of HIPAA compliance. For instance, if using Sitecore CDP/Personalize for a patient portal experience, it will treat tracking data as PHI and store it accordingly.

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) applies to any environment that processes, stores, or transmits credit card data. If your Sitecore implementation involves e-commerce or donations where card payments are handled, PCI compliance becomes a factor. PCI DSS sets twelve requirements for any system handling credit-card data, covering network security, data protection, vulnerability management, access control, monitoring, and policy.

• XP

  • If you process or store raw card data, your entire Sitecore environment is in PCI scope. You need segmentation, encrypted vaults for keys, scans, penetration tests, strict logging, and a formal QSA audit.

  • Most avoid this by using tokenized forms or redirects so card data never touches Sitecore.

• XM Cloud

  • XM Cloud is not PCI-certified for raw card handling.

  • Best practice is to use a PCI-compliant gateway, for example, Stripe via client-side scripts, and store only non-sensitive tokens or order IDs in Sitecore, keeping the CMS outside PCI scope.

DORA

For organizations in the financial sector, especially in the EU, the Digital Operational Resilience Act (DORA) is a new regulation, EU 2022/2554, that takes effect starting in 2025. DORA is all about ensuring that financial entities (banks, insurance companies, investment firms, etc.) and their critical IT service providers maintain robust operational resilience, including cybersecurity, incident reporting, and business continuity. It essentially mandates strict ICT risk management and includes rules for contracts between financial institutions and IT providers.

• XP

  • Deployed on-prem or in your cloud, XP is an internal ICT asset. You include it in your ICT risk framework, resilience planning, and incident reporting—no special contract with Sitecore is needed.

  • If you operate Sitecore yourself and experience an incident, you handle reporting per DORA’s rules.

• XM Cloud

  • Sitecore becomes an outsourced ICT provider. You must sign Sitecore’s DORA addendum, embedding clauses on SLAs, data access, subcontractor control, and incident notifications.

  • You rely on Sitecore’s resilience measures (backups, failover) and formal incident reports to meet DORA obligations.

  • DORA expects robust continuity plans. Sitecore, running XM Cloud, will have its own resilience measures (redundant infrastructure, backups, disaster recovery) to ensure continuity​
  • As a customer, you should inquire about RPO/RTO (Recovery Point/Objectives) for XM Cloud in disaster scenarios, and ensure those align with your needs.
  • You should also have an exit strategy (how to retrieve data from Sitecore if you needed to switch systems – DORA mandates having plans for termination of a provider contract).

Localization Laws

Beyond global regulations, many countries have specific data localization laws or restrictions requiring personal data of their citizens to be stored within national borders or meeting certain conditions. If your Sitecore implementation serves users in such countries, you must account for these:

• Russia (Law 242-FZ) mandates that all Russian-citizen data be stored in-country. XP lets you deploy to Russian data centers; XM Cloud cannot comply without a local region unless Sitecore establishes a dedicated local region there, which is unlikely given geopolitical complexities.

• China (PIPL) demands in-country storage unless a security assessment is passed and public sites hold an ICP license. XP supports local clouds: Alibaba, Tencent, China-hosted Azure/AWS; XM Cloud is unavailable under these rules.

• Brazil (LGPD) mirrors GDPR but allows cross-border transfers under adequacy, consent, or contractual safeguards. Many host in Brazil for performance - both XP and XM Cloud can comply.

• Other Markets: India’s law permits whitelisted transfers; Canada’s PIPEDA has no strict localization; some Middle-East governments require local hosting. XP adapts universally; XM Cloud is limited to Sitecore’s region footprint.

AI Regulations

As Sitecore adds more AI-driven features, such as Sitecore Stream – the new AI orchestration and “copilot” capabilities across the platform – and AI-based personalization or content generation tools, organizations need to anticipate compliance with emerging AI regulations. Emerging rules govern AI by risk level:

• EU AI Act classifies AI from unacceptable to minimal risk. Marketing personalization and content generation are “limited risk,” requiring transparency and logging; high-risk uses, such as credit scoring, need full conformity assessments.

• U.S. Guidelines (FTC, NIST) urge against deceptive AI use, mandate bias mitigation and data privacy; states address biometric profiling.

• XP

  • You bear full responsibility for AI integrations (recommendation engines, chatbots). You must document model purposes, disclose AI use, ensure human oversight, and conduct impact assessments if required.

• XM Cloud

  • Stream AI offers built-in guardrails, never trains on your data, and runs on Azure OpenAI with compliance certifications. You label AI outputs and disclose usage, while Sitecore manages secure model operations and regulatory alignment.

Summary Comparison Table

Conclusion

Sitecore XM/XP (self-hosted) and XM Cloud each have distinct strengths when it comes to compliance and geographic hosting:

• Sitecore XM/XP (On-Premises or Customer-Managed) offers ultimate control over data – you decide where it lives, how it’s secured, and when to upgrade or patch. This makes it well-suited for organizations with strict data sovereignty demands or heavy regulatory obligations that standard cloud setups can’t meet. For instance, if you absolutely must keep data within a certain country’s borders (Russia, China) or within an isolated network, XP gives you that flexibility. It’s also advantageous if you require deep customization at the infrastructure level (custom encryption key management, specialized audit logging, etc.). In short, when localization and direct control are non-negotiable, the traditional XP deployment can fulfill those needs. However, with this power comes responsibility: your team must invest in security and compliance efforts (hardening servers, obtaining certifications, managing disaster recovery). As one Sitecore expert put it, XP’s flexibility can address strict compliance scenarios, though the effort is on you to secure and certify such an installation.
• Sitecore XM Cloud (SaaS) provides a compliance-aligned platform for the most common needs. Sitecore has done the heavy lifting for GDPR, HIPAA, and cloud security standards, relieving customers from worrying about infrastructure-level compliance. This model shines for organizations that want to offload operations and focus on content and digital strategy, while trusting Sitecore to maintain a secure, compliant service. It’s especially beneficial if your regulatory requirements can be met by the service’s existing framework (e.g., hosting in broadly acceptable regions, encryption, standard certifications). For EU personal data, XM Cloud can keep you compliant by hosting in-region and acting as a proper data processor with a robust DPA. For healthcare, XM Cloud now meets HIPAA requirements, allowing use of cutting-edge features in a regulated context that previously might have required on-prem. For financial services, XM Cloud can be used with the right contractual protections (DORA addendum), letting banks leverage SaaS agility. The trade-off is reduced flexibility: if your needs fall outside the service’s design, there’s little you can change. You must also be comfortable ceding control; for some, that trust in a third party is a hurdle.

Ultimately, the choice may come down to the specifics of your compliance landscape. Many organizations will do a risk assessment: if using XM Cloud, can we accept its regional hosting options and trust model for our data? If yes, the benefit is quicker deployment and less maintenance burden, with Sitecore’s expertise backing compliance. If no – perhaps due to a unique law or an internal policy – then running Sitecore XP in your own controlled environment remains a valid path.

It’s worth noting that some organizations pursue a hybrid approach: using XM Cloud for most content management needs, but keeping certain data or functions on-prem. For example, a global company might run XM Cloud for its main website but have a separate XP instance for the Chinese market due to localization rules. Or use XM Cloud for content, but integrate with an on-prem analytics store for sensitive customer data. These approaches can mitigate compliance concerns while still reaping some SaaS benefits, though they add complexity.

In conclusion, both XP and XM Cloud can support a compliant solution – the difference lies in who manages the compliance controls and how granular your control is. If your organization has strong compliance and IT teams and needs fine-grained control or non-standard hosting, Sitecore XM/XP gives you the needed freedom (with effort). If your organization prefers to leverage vendor compliance investment and standardize on best practices, XM Cloud offers a convenient, secure choice that is continually updated by Sitecore.

References: