Preparing for the Migration from Sitecore XP to Sitecore XM Cloud
Vasiliy Fomichev
In Architecture Posted May 31, 2022
Sitecore is planning to release XM Cloud mid this summer, and that is exciting! There are many reasons to look forward to this release – as a true SaaS platform, it will take application deployment, system maintenance, and upgrades off the hands of Sitecore customers; however, how do we migrate to the new platform? In this blog, I will shed some light on the path to migrating to the new shiny XM Cloud platform.
Important: Sitecore XM Cloud Requires Headless
Let’s get the most important fact out of the way quickly – XM Cloud will be a true SaaS platform, and with that, Sitecore will want to avoid hosting custom code within the application. This means that the only architecture supported on the XM Cloud will be headless. If your company or client created their own custom web APIs to be used with a headless presentation layer – that will not work. The safest way to think of XM Cloud is not being able to host any custom code. My wishlist item is for XM to still allow some scripting with limited libraries and packages.
Preparing for Migrating Sitecore XP Customizations
What about platform customizations? Sitecore plans to support webhooks for acting on events within the platform. A webhook will allow calling an external platform or a custom web service, which would then take on the job of processing the request.
Another item on my wishlist for XM Cloud is the administrative web API layer to help trigger or even manage content operations from outside of the client UI. This is similar to what OrderCloud, Content Hub, and Boxever have and is expected from any modern SaaS platform. Depending on how much Sitecore will be willing to expose in this API, clients would be looking at more or less work in rearchitecting their existing extensions and customizations to their current instance of Sitecore.
I would expect Sitecore to guard the performance of the platform as much as possible, so, likely, they will not allow injecting blocking steps in the platform’s pipelines. This means that we will likely not be able to customize them by injecting new blocking processors or making updates to the existing ones. Thus, if you have any custom processors or entire pipelines that are triggered during various stages of request processing in your current XP implementation, from receiving the request to sending the response, they would likely need to be rearchitected unless, Sitecore will allow custom scripting to be used for these things.
Exporting Business Logic into a Middleware Application
With XM Cloud having limited customization support for request processing, we would be reserving to using custom proxies. This is a common practice in SaaS solutions; in fact, if you had a chance to work with OrderCloud, you should already be familiar with this concept. A middleware web service layer would need to get created between XM Cloud and the application code that would facilitate additional processing, integrations, and other types of operations that would not be allowed or would not make sense to host in the CMS with custom scripting. Think of request manipulations, additional service calls, validations, integrations, response content updates, and data structure changes.
Once XM Cloud MVP is out, we’ll see exactly how much flexibility we will have, which would dictate the approach to handling customizations and business logic. Once these types of challenges are resolved – it would be time to plan the migration to headless. For now, if you are building a new Sitecore solution, create a distributed architecture using serverless hosting to reduce the cost of the future migration.
The Path to Headless
I don’t see brands on Sitecore MVC or .Net Web Forms jumping into the headless rebuild only for the sake of migrating to the SaaS platform. In fact, this requirement will make brands reconsider the platform, especially if they have not been using it’s personalization tools. Unless there is a serious performance issue with the current implementation that can be better solved with headless, the ROI of a migration for the sake of reducing future effort won’t be there; however, Sitecore may surprise us with a feature set of XM Cloud and deliver a lot more value in the platform than expected. It has done that before.
There are four primary causes that I see that would fuel the migration to headless:
- Website redesigns and upgrades – in fact, all new Sitecore projects or redesigns, regardless of the hosting model, should be done headless. Some complex upgrades may also represent a window for cost efficiencies turning it into a rebuild, a “lift and shift” to headless.
- Sitecore support compliance – although there is nothing that has been announced yet, it is likely that Sitecore will use the support deprecation schedule to push the laggards through the migration.
- Some brands will have internal initiatives that may fund migrations to headless as part of internal compliance.
- Lastly, in rare cases, if brands have developers on payroll with some healthy bench, they may begin a slow migration to headless in the meantime.
No matter how we slice it, a rebuild is unavoidable, if you are not already using Sitecore headless services. The paths for scenarios one and two will likely involve rebuilding the entire solution at once; thus, please consider reducing the number of platform customizations to lighten the amount of rework in the future when considering a future migration to SaaS (this is a generally recommended practice, to begin with).
The good news is that if there are internal resources available that can power the rebuild slowly but surely, this route would be the most cost-efficient one, although it may result in complexities for content authors. The good news is that the migration doesn’t have to be all or nothing, and we can gradually start moving pages to headless one-by-one.
Will the Sitecore rendering host’s ability to run MVC sites in Jamstack with XM Cloud?
– No, it’s a stop-gap solution for those on MVC looking to gain headless benefits; however, this architecture will not be supported by XM Cloud.
What Should Brands Keep in Mind
Here are the things for brands to keep in mind while planning new website implementations or redesigns –
- All new initiatives should be implemented using Sitecore headless services. If you are already in the middle of the implementation, let’s say with SXA – it will likely make sense to stay the course (in fact, the SXA does have a roadmap with headless on the path), especially if you anticipate high component reusability across pages or multiple websites or the cost of the switch to headless for the remainder of the project would be prohibitive. Sites built on MVC are perfectly fine; in fact, it may make sense for some brands to stay on XP for as long as possible until the composable story with the new Sitecore products is fully realized, which may take a few years.
- For all current implementations, evaluate the cost of migrating to headless gradually internally (the backend development cost using JSS is reduced by 50-80% in my experience, so if your website is relatively simple, it would be relatively easy to migrate it using internal “bench”).
With all of this said, there has to be a good reason for brands to migrate to SaaS, and the hosting model change alone will not be enough for many brands, for instance, those who have economies of scale using either their own data centers or cloud infrastructure. Additionally, those brands that leverage XP’s marketing tools extensively would be looking at a costlier migration, especially if they want to keep the same functionality. I recommend engaging a Sitecore Platinum partner to understand what your specific migration will look like in terms of timeline and budget.
Migrating Sitecore XP Personalization
A robust rule engine is at the core of Sitecore XP’s personalization capabilities, and that has served the platform relatively well. Sitecore’s personalization has been the DXP’s competitive advantage since the early days. So how does Personalize stack up to that? The short answer is that it’s significantly superior in terms of split testing and decisioning capabilities. In fact, Boxever, the product behind Sitecore Personalize, has been recognized in a Personalization Engine Magic Quadrant by Gartner. Migrating to Personalize is well worth it, especially for the brands that are present in multiple digital channels. The DXP tried addressing the omnichannel story; however, it was still a digital web platform at its core. Personalize brings true omnichannel capabilities with full-stack experiences. There is a lot to talk about in terms of the capability comparison between the DXP and Personalize; however, one thing that’s important for us here is the difference in how personalization is handled by both platforms.
In the DXP, a rule engine powering its personalization capabilities is based on a set of simple yes-no conditions checking for various things. For instance, “If the visit number is [X]” or “If the contact’s engagement value is more than [Y]”, if a condition is met, a configured action gets executed, which is usually either hiding or showing a component or changing its content or presentation. All this checking and computation is done at the time of a page request by Sitecore, in the “backend,” and the page that gets returned to a website visitor is fully personalized based on the rules.
Sitecore Personalize decision model for product recommendations.
Personalize, on the other hand, uses “frontend” personalization using its out-of-the-box Web Experiences subsystem and allows using “backend” personalization via an integration with its Full-Stack Experiences. In both cases, decision rules are a lot more flexible and, unlike the ones in the DXP, in addition to the simple yes-no rules, can return the next best actions and various data sets, for instance, specific product recommendations.
Given the difference in how the two personalization engines work, there is no direct way to migrate the personalization from the DXP to Personalize. It has to be reimplemented. The effort of the implementation will depend on the complexity and the number of the personalization rules needed to be migrated (not the number of personalization use cases because the same rules could be used for multiple personalization scenarios). We want to be smart about these types of migrations because not all rules may be worth the cost of migration; thus, a digital marketing strategy audit should be performed to see what rules our of the ones in use currently “deserve” to be migrated.
Once the personalization rules are identified, we now have to review the two options we have for implementing them in Personalize: Web Experiences and Full-Stack Experiences. Read more about Sitecore Personalize personalization capabilities on the Sitecore Documentation website. In the context of migration, the most important aspects we should consider are:
- Web Experiences provide a rapid and cost-effective way to personalize web pages using the “frontend”, and if you know some HTML, you wouldn’t even need a developer.
- Full-stack Experiences provide a highly scalable omnichannel way of personalizing through the “fontend” and “backend.”
Web Experiences are great at quickly spinning up personalization use cases; however, there may be issues in Single Page Apps, flickers on page loads that would need to be dealt with, and they do not scale without additional integrations and customizations, because each personalization use case requires manual HTML and content entry in Personalize.
Full-stack Experiences scale well; however, they require additional effort to be integrated into the XM’s rules engine or any other digital platform. As of the time of this writing, XM still has the same personalization engine as the XP, which can be extended to support Personalize; however, we know that the engine is changing in XM Cloud, which is something that needs to be considered for long-term cost when implementing the custom rules in general. Given all these caveats, we should now see why the initial audit of existing personalization effectiveness is so important; the ones that make it into the migration scope will have to work hard to pay for the cost of the current and potential future rebuilds. There is little official public information from Sitecore on the new rule engine, and my hope is that there will be a direct migration tool for it; otherwise, Sitecore’s customers willing to switch to Personalize with large amounts of sophisticated personalization will be caught with a double rebuild cost.
What if you are on XP and you haven’t been using its marketing tools? Consider migrating to XM and when ready for personalization – talk to Sitecore about Personalize. In the meantime, the license cost savings from switching to XM from XP can be put towards being hosted on Sitecore MC or with another Managed Infrastructure provider; that way, you would end up with roughly the same platform license cost, the same great CMS, yet without the headache of maintaining the infrastructure.
In conclusion, the information above is what is currently known; however, there is still a lot missing to complete the picture, and I’m looking forward to the release of XM Cloud planned for this summer. In the meantime, the information in this blog should position you and your brand well for a smooth landing into the most awaited CMS of this year in advance. Do share this article with your coworkers, let’s help spread awareness, to ensure we position each other for long-term success with the platform. Warren Buffet once said, “Someone is sitting in the shade today because someone planted a tree a long time ago.” – although we are ways out from the XM Cloud release that will rival the XP’s CMS capabilities, the decisions you and your teams are making now may significantly decrease the future migration cost.
