Migrating to Sitecore XM Cloud: The step towards a Composable DXP

1.1 From monolith to best-of-breed 
Platform DXP, or the Sitecore Experience Platform as it was named before, is the original all-in-one Sitecore product. It’s a monolithic design, and thus less flexible in selecting the ideal subcomponents for your use case and more demanding when upgrading to a newer version because of all the implementation-specific modifications being built into it. But that all-in-one approach also means it offers all of the DXP functionality next to its CMS capabilities, like email campaign management and a marketing suite with profiling, personalization and multivariate testing.  

This product is still available, still supported and maintained, and still widely used. But it makes a lot of sense that Sitecore started offering a Composable DXP next to its Platform DXP in a time were using maintenance friendly SaaS building blocks allows for much faster development, offering the flexibility to adapt your product stack to the increasingly shorter innovations cycles we see lately.  

Sitecore XM Cloud is the CMS product within that Composable DXP offering. And although it offers less functionality than Platform DXP, its enhanced flexibility, integration capabilities, and developer experience more than make up for this sacrifice. And it even is a little more nuanced than that, because XM Cloud even contains basic personalization functionality and very useful built-in analytics out of the box!

1.2 Effortlessly build new pages with Sitecore Pages 
Apart from the better architecture and differences in functionality, XM Cloud also offers a completely revamped in-page editing experience: Sitecore Pages. This new editing tool is easier to use than the original Experience Editor, is considerably faster, but it also introduces a new concept: components – together with the component builder.  

Using Page Designs and Components as building blocks, you can effortlessly build new pages within your site and even add completely new components using the Component Builder, without the need to do any development or write a single line of code!  

It also offers the ability to switch between multiple themes, component variations, and it contains a site creation wizard, taking the convenience for content editors to new heights. This hugely improved editing experience alone is a reason to consider migrating to XM Cloud. Most of the other motivations are technical in nature, or budget related, but this is the major advantage for anyone working with Sitecore as a CMS on a daily basis. 

1.3 A SaaS solution with PaaS flexibility 
Where Platform DXP could be hosted both on premises as on PaaS architectures like Azure Web Apps and SQL PaaS databases, XM Cloud only comes as a SaaS offering. Though where typical SaaS products offer you a login to a shared environment, XM Cloud still allows for (or even requires you to) setting up your own instance within Sitecore’s SaaS environment and gives you the opportunity to deploy small customizations, together with your own custom front-end. But from there Sitecore maintains the environment, does the necessary scaling, (infrastructural) maintenance, and regular updates. And your development environment based on Docker container images is updated in parallel.  

This way, you get all of the SaaS benefits, but with the flexibility of PaaS architectures. It really improves the whole development experience and makes setting up a new Sitecore environment much easier.  

Be cautious though, as you do not want to over-use the ability to deploy customizations: strive to keep the Sitecore implementation as vanilla as possible! I will show you how and why later on. 

1.4 Composable implementation architecture for improved standardisation, separation of responsibilities and futureproofing 
With XM Cloud, also the application architecture of your implementation changes. In short: you don’t build on top of it anymore, but next to it. What does this mean?  

The traditional role of a CMS in website implementations 
For years CMS’s (not only Sitecore) have been seen as the fundament to develop a website implementation on. Before the headless era this was a necessity, because the rendering was done by the CMS (for example using MVC in .NET). And additionally, Sitecore offered a lot of possibilities to hook into the core processes of the CMS: hook onto events, alter processing pipelines and customize the UI or specific behavior of the CMS in certain scenarios. These endless possibilities led to highly customized implementations that were tightly coupled with the code and installation of the CMS itself. This makes upgrading to a newer version challenging, because you have to split default Sitecore code and configuration from custom code and configuration to be able to update the vanilla installation of Sitecore to a newer version. 

As indicated, your current implementation dictates what your migration path is going to look like. If you utilize a lot of XP functionality, you need to carve that out first. And from a Composable point of view, it’s perfectly possible to do that on your current implementation before starting with the actual migration itself. In general, we could divide a typical migration project into four stages:

2.2 Step 2: Preparing the migration by reducing the gap between Platform DXP and XM Cloud 
When the assessment and planning is finished, we can start with the preparation of the actual migration. In this stage there are no migration tasks involved, but we are going to prepare our current implementation or solution for the intended migration. This stage has two goals: reduce the gap between your Platform DXP and the XM Cloud functionality, and minimize the implementation size for the final migration. 

The advantage of Composability is that Composable and MACH-based components, or Packed Business Capabilities (PBC’s), can integrate with non-Composable architectures as well. So any Composable or SaaS product that you add to your current implementation now, can be set up in pretty much its end state already. And by removing functionality from your monolithic DXP implementation, your final migration will be simpler and cheaper, while lead times will be shorter. This process is what we call the carve out of your current business logic: 

2.3 Step 3: Reworking the front-end with headless & GraphQL 
Now it’s time to take a close look at the front-end. Logically, this stage is the most variable in terms of impact on the required investment to migrate to XM Cloud. If you are already using a headless architecture, keeping your renderings is perfectly possible. If not, you will need to plan for a rebuild of the front-end, partially or completely.

2.3.1 Rendering pipelines 
If you are using custom rendering pipelines, you will need to drop those and re-architect your rendering mechanism or switch to default JSS. The whole concept of rendering pipelines has become obsolete with XM Cloud, as it only supports a headless setup. Content is published statically to Edge as the CDN, and from there you can query for content from your JavaScript front-end. The Sitecore Layout Service Client handles routing and page requests, and additional GraphQL queries can be used to retrieve specific content collections like the latest news, or a list of all items of a certain template type.

2.3.2 Content resolvers (for JSS) 
Secondly, custom content resolvers should be avoided in a greenfield XM Cloud implementation, but in some cases they do still function properly. So for migration purposes, you can hold on to them and decide to replace or re-architect them later on.  

The reason for partial compatibility towards custom content resolvers again lies with the mechanism of publishing towards the Edge. Traditionally, a content publish pushed content from your working database (master) to your published database (web) and got resolved only on request time, which was the exact time content resolvers were executed. This allowed for dynamic and contextual content resolving operations.  

But with XM Cloud, the web database is no longer used, and publishing content creates a static content and layout snapshot that is being placed on the CDN. So basically, the publishing operation now performs the content resolving and pushes the outcome to the Edge. At request time, you can retrieve that cached and resolved piece of content, but you cannot reach the content resolving process or back-end, so dynamically or contextual resolving is no longer possible. 

2.3.3 Rebuild options 
Depending on your starting point, several different scenarios may be applicable for rebuilding your front-end for the migration to XM Cloud: 

• If you were running on 10.x using JSS without any custom content resolvers, you can port the whole front-end to XM Cloud with minimal changes; 

• If you are already using JSS on an earlier Sitecore version, also using custom content resolvers, you need to upgrade your Sitecore version (if not done already in the preparation phase) and redesign the parts that use incompatibly content resolvers; 

• If you are using MVC with a React front-end using custom rendering pipelines, you might be able to re-use parts of your React renderings in the new Next.js setup, but need to redesign the Sitecore implementation to move from MVC to a headless approach – though this scenario is quite exotic and if you are using such a custom setup, rebuilding using the default Next.js and JSS setup might be a better choice; 

• If you are using classic MVC, you need to rebuild both your front-end and the Sitecore implementation, meaning that you would be best of replacing or modernizing your entire front-end as a part of the migration project. 

2.4 Step 4: Migration and setting up your new Cloud solution 
The last stage of the migration roadmap encompasses the actual migration or transition to XM Cloud. Start with setting up a new solution based on https://github.com/sitecorelabs/xmcloud-foundation-head and update your Nuget Feed to Sitecore.XMCloud.*. Update the default build configuration in the xmcloud.build.json file to configure your item serialization, the projects to build (which should be kept to a minimum!) and your rendering hosts. 

Next, in preparation of the content migration, configure Sitecore Content Serialization (SCS). If you are still using Unicorn or TDS, I would recommend considering SCS, as it’s a Sitecore native technology and very fast and powerful. When you have your serialization set up, you can start migrating your content. This works just like any Sitecore to Sitecore environment content transfer, and you can use both content packages as the SCS process to inject your existing templates, layouts and content items into your new Sitecore solution. Also Razl might be helpful when comparing databases (with your local Sitecore XM Cloud instance) or to do a single content item push to your new environment outside of the SCS configuration. 

If you need to re-apply personalization rules (based on your new design), now would be a good time for that. Depending on your timelines and possible content freeze, doing so after delivering your new XM Cloud website to production could also be wise though. 

Lastly, you need to design and implement new CI/CD pipelines. Those pipelines can utilize the Sitecore XM Cloud native CLI commands and will be fairly easy to set up opposed to what you’re used to from a PaaS infrastructure or custom on premises Sitecore deployment. Your front-end can be deployed separately from Sitecore, so you can use any existing or newly created self-maintained process for that. 

Having covered all steps of a typical migration roadmap towards XM Cloud, there’s one more decision to make to finish up our action plan for the migration: how to cope with this transition while keeping the store open? Broadly speaking, there are two possible scenarios.