XM Cloud is the CMS of Sitecore’s new Composable DXP. It is a further development of their original CMS, but packed and serviced completely different. It’s SaaS, less hassle to maintain, quicker and easier to develop on, a lot easier to work with for content editors, but still as powerful and versatile as before. So when starting a new Sitecore implementation, choosing XM Cloud over the original Platform DXP is a no-brainer. But what about migrating your existing implementation to XM Cloud? There is no set upgrade path and your starting position greatly influences the desired route to take, but also the business case behind such a migration. In this article I will share my view on the important differences, challenges, benefits, caveats, possible approaches for a migration roadmap, and everything you would like to know and consider before embarking on this journey.

What makes XM Cloud different from Platform DXP?

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!

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.

SaaS-like

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.

Implementation architecture

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? 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.

When the headless capability was introduced with Sitecore JSS, the ability to run the front-end completely separate from the CMS – both the architecture and the infrastructure – created a clear separation between the CMS implementation itself and the JavaScript based front-end. Though still, the habit of customizing stuck. For example with custom content resolvers in Sitecore to alter the output sent to the front-end. These custom content resolvers required deploying a custom implementation solution to the Sitecore instance, and thus adding additional functionally onto the Sitecore installation remained the default; sometimes even being functionality unrelated to Sitecore like external data transformations or third party integrations.

As a Composable architecture, XM Cloud is the next step up from headless, offering a cleaner, more scalable and easier to maintain architecture, greatly improving future-proofing, agility and productivity

With XM Cloud, Sitecore has sent a clear message: “as a SaaS and Cloud-native product, we will keep your Sitecore CMS implementation up-to-date, and also handle the scaling and infrastructure, if you will keep things vanilla”.

Following the MACH principle to maximize maintainability and agility, separation of concerns is very important. So I would also strongly recommend keeping your Sitecore implementation as vanilla as possible, by deploying any customizations and integrations to a separate microservice. And that’s what I mean by building next to it instead of on top of it. Your CMS instance isn’t the foundation of your web project, it’s merely one of the data providers and one of the tools to maintain your website. Separate your front-end (by going headless), but also separate any business logic from it into microservices. And by keeping things vanilla, like omitting custom content resolvers, you greatly improve the maintainability of your web platform architecture, and allow for pain-free and flawless automatic upgrades in the future.

Functionality comparison chart

As I said, XM Cloud is a more focused product, offering less functionality than the Platform DXP. XM Cloud though is part of the new Composable DXP of Sitecore, which consists of multiple products that follow the same principles as XM Cloud: SaaS and best-of-breed with a strong focus on integration. In the following table you can see which product would match which functionality within Platform DXP.

As a preparation to migrating to XM Cloud, it’s a good start to map out which features you are currently using within Platform DXP, as this greatly influences your required or desired upgrade path. Basic personalization and analytics are supported by XM Cloud, but if you want to utilize more advanced personalization like cross-session personalization or custom personalization rules, you would want to add Sitecore Personalize to your Composable stack. With the complementary Sitecore CDP (Customer Data Platform) you can create customized user profiles, set up and analyze personas on your website and gain in-depth insights into your visitors’ behavior.

If your current Sitecore implementation contains custom developed search functionality based on the (Solr) indexes that run on your Sitecore instance, you have to find an alternative solution, as XM Cloud does use Solr internally, but the architecture no longer allows for using your own indexes to search for specific content. Why? Because the architecture now separates the Sitecore instance that publishes content to the Edge (a CDN running in front of Sitecore) from the headless front-end implementation in a JavaScript framework like Next.js. Meaning there’s no way to reach the indexes behind the Sitecore instance from your front-end implementation. All content retrieval is done via GraphQL queries on the Edge.

One of the best and easiest ways to implement content search, while also allowing you to gain valuable insights into your visitor’s search behavior, is to add Sitecore Search to your Composable stack. This product runs stand-alone and can even run on Platform DXP to allow for an easy transition (more on that later!).

Sitecore EXM (Email Experience Manager) is also not compatible with XM Cloud, so for email campaign management you could opt for Sitecore Send.

And lastly, if you are not already using JSS in your Platform DXP, but classic MVC renderings, you need to rebuild your front-end using JSS and (for example) Next.js. For most existing Sitecore implementations, this change would have the biggest impact on planning and strategy: if you were planning to modernize your front-end anyway, it’s a good idea to combine these two innovations. Build up a new headless front-end directly on XM Cloud, while migrating your content data templates and content items from your existing implementation to XM Cloud.

Migration roadmap

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:

Assessment

The first step is to take inventory. Learn what customizations you have in the CMS, considering the content resolvers, render pipelines and any other non-default configurations to both the UI and the logic of the CMS. Do you have integrations with external data providers or do you push data from your Sitecore based website to other systems via the Sitecore back-end? Think of submitting bookings to a booking system, analytical data to GA, retrieving profile information from a CRM, or maybe retrieving vacancies from Salesforce or pushing orders towards Salesforce. Also, if you are using personalization on your website, it’s wise to analyze and document all of the configured personalization rules, as you need to reconfigure them in Sitecore XM Cloud or Personalize later on.

The second part of your assessment stage would be a gap analysis between the XP functionality you are currently leveraging and the funcionality offered by XM Cloud, but also to learn what Sitecore version you are on, and if you are already using JSS. This is going to help you in determining the steps of your migration path, but also the best route or approach to take. I will cover that in more detail when discussing the possible migration scenarios.

To finish up the assessment phase, start planning your migration path: you need to isolate and refactor components in preparation of your migration. Non-XM functionality could be replaced by separate Composable products (like replacing EXM by Send), custom business logic should be removed from your Sitecore implementation, and redundant or outdated content or components could be removed to reduce the size and complexity of your migration early in the process. The order in which you take on those tasks really matter.

Preparation: Isolation & refactoring

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:

Push integration touchpoints to the front-end, move any integrated business logic into separate microservices, and replace functionality like search and email campaign management with Sitecore Search and Sitecore Send for example. Search functionality requires custom code, custom Solr indexes, and also a more complex infrastructure to host and maintain. By removing that complexity from your Sitecore implementation, the next steps will become less complex and time-consuming.

The last step of preparing your Sitecore solution could be upgrading to the latest version of the Sitecore Platform DXP, version 10.4. This is optional though, as it depends on whether you are going to persist any current implementation code. If your current implementation is using MVC and you need to rebuild your front-end nonetheless, and if you are only going to copy over Sitecore content items to the new XM Cloud implementation, a Sitecore upgrade might be obsolete. But if the gap is relatively small, and you are already running on a recent version of Sitecore (making the upgrade smaller and quicker), it might be beneficial to upgrade to 10.4 first. Having tackled all differences like JSS versions, external dependencies and your Next.js version again aids in simplifying the migration process itself.

Rework front-end: Go 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.

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.

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.

---

---

Long story short: if your custom content resolver includes dynamic data, or performs additional (ad hoc) operations, you can not migrate them to XM Cloud, and you should push this logic to your JavaScript front-end. All other applications of a custom content resolver are still compatible, but not optimal for future maintainability. Any data modifications or content re-ordering tasks could be performed by custom GraphQL queries, which is easier to maintain, more elegant, and it keeps your Sitecore implementation vanilla. Furthermore, restructuring content in the content tree could also be a solution to minimize the need for custom content resolvers. In most cases, the default Datasource or DataSource Item Children Resolver, or the Context Item (Children) Resolver or Folder Filter Resolver would suffice.

Of course, this all only applies when you are already using JSS. When your solution is using MVC for rendering, this does not apply, and you should rebuild going to JSS directly, preferably avoiding custom content resolvers completely.

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.

Migration: Set 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.

Migration scenarios

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.

If the gap between your current implementation and the best practices for XM Cloud is manageable, you can use the carve out approach, moving business logic into microservices, re-architecting your Sitecore implementation, and transferring everything to XM Cloud. Given that the lead time for the latter step will be relatively short, and that you can go live with each intermediate step up until the Sitecore XM Cloud migration, this approach can be broken down into several smaller releases and thus the required overlap of the two Sitecore platforms will be minimal.

However, when the differences are greater and when you need to (partially) rebuild your front-end, it might be a better idea to use the hybrid approach. With this approach, you keep your existing Platform DXP implementation intact, and set up a greenfield XM Cloud project as a new instance alongside. You can start with transferring data templates and content you want to keep, and build up new renderings, while re-using as much code as possible, while placing it in its new Composable architecture. Since this usually takes longer, I would recommend gradually releasing parts of your website – by functionality, section or by page – and using a reverse proxy to route traffic to the right environment depending on the URL. This gives you time to learn, adopt to user feedback and best practices discovered along the way, while avoiding a big bang at the end of the migration process.

Conclusion

I hope this article has given you a little more insight into the differences between the two different platforms and some valuable pointers to get you started with your migration to Sitecore XM Cloud, coming from an existing Platform DXP implementation. The required effort may vary greatly depending on your situation, but it’s absolutely worth the investment given that you are not only future-proofing your Sitecore implementation, but also modernizing your entire stack and platform, while implementing a better overall architecture, greatly enhancing both the maintainability and agility of your web platform in general. If the path to Composability is too steep, you can always opt for a more gradual transition over multiple quarters, taking on the redesign and introduction of new components step by step.