Potential Migration Issues with Sitecore XM Cloud
Recently I wrote a post about Sitecore Experience Manager Cloud (XM Cloud), Sitecore’s SaaS model content management system (CMS), which allows you to adopt composable cloud architecture for your organization. In that post, I offered some advice on how to determine whether your business should migrate to XM Cloud, and when the right time is to make the switch.
Once you've decided to migrate to Sitecore Experience Manager (XM) Cloud, you might encounter some bumps along the way. As a Sitecore MVP who has helped clients make the switch, I wanted to share them with you, so you know what to expect.
Potential Speed Bumps in the Sitecore Experience Manager Cloud Migration Process
XM Cloud's Headless Architecture
Sitecore XM Cloud requires headless architecture. You need to use the Sitecore Headless Services to power the front end of your components.
Any traditional MVC Sitecore components need to be rebuilt for XM Cloud. The Sitecore rendering host’s ability to run MVC sites in a headless architecture is not supported in XM Cloud.
Speaking of migration, your website's content tree needs to be moved over as well. If you're not redesigning your site, it should be easier port over, but content management and migration is never as simple as you think it will be.
Custom Modules Don't Transfer to Sitecore XM Cloud
Any custom modules you’ve created or installed from the Sitecore marketplace, GitHub, or other sources need to be removed before you can migrate to XM Cloud.
In XM Cloud, you cannot install modules the way you did traditional Sitecore Experience Manager (XM) or Sitecore Experience Platform (XP). Additionally, XP functionality is not directly transferable to XM Cloud so anything that relies XP features it will likely need replacement.
You may need to develop a new solution to meet the business needs that your custom XM or XP modules served. So make sure you have team members who know headless development or that can quickly learn it.
XM Cloud Doesn't Currently Offer Forms
Sitecore Experience Manager Cloud doesn't have a form offering at this time. There are plans in the roadmap to develop that functionality, but for now, a third-party system will need to supply that functionality in XM Cloud.
CRMs usually have some sort of embedded form capabilities that you can use to meet your business needs for forms. As another option, you can build the forms as components using headless architecture. It's important to note that if you build them as headless components, you won’t natively have a server available to store form data on.
MVC Renderings Likely Won't Work in XM Cloud
Traditional MVC Sitecore builds tend to use rendering parameters. MVC Sitecore Experience Accelerator (SXA) in particular, uses a lot of these. Unfortunately, they aren’t likely to work in your new headless components. So new ones, ideally that work with Pages, need to be built into the headless versions of your components in Sitecore XM Cloud. This is already taken care of in headless SXA, but you'll need to do it for you own Sitecore components.
Sitecore Experience Manager Cloud Offers Major Changes from Older Versions of Sitecore
If you’re upgrading from a Sitecore version older than 10, you should know that have been major changes to Sitecore in the intervening time. The introduction of SXA and Sitecore headless services will inevitably break a lot of things you try to migrate as-is. You'll need to rethink publishing, component data source locations, dynamic components, layouts, and global elements if you migrate to Sitecore XM Cloud.
You'll need to Make Design Changes to Your Website with Sitecore XM Cloud
If you're switching to Sitecore XM Cloud as part of a redesign, changes to your site's design and content structure are almost guaranteed. Additionally, there may be places where you need to alter or compromise on the existing design simply because certain things will naturally be harder and take longer to implement in a headless solution like XM Cloud.
There is No CD Server with Sitecore XM Cloud
You can use custom content resolvers in Sitecore XM Cloud if you need to, but it’s not a best practice. You may have functionality that relies on CD server session information, you may have authentication that relies on the CD server, or you may even have pipelines that handle environment variables for the CD servers or something similar. Any feature of your website that relies on a CD server will need to be re-architected to fit Sitecore XM Cloud's headless environment.
Using .NET Rendering SDK Creates a Steeper Learning Curve for Sitecore XM Cloud
If your Sitecore developers have stronger skills in C# than Next.js, you may be tempted to use the ASP.NET rendering SDK when you migrate to Sitecore XM Cloud. While this is a possibility, all the documentation and examples assume that you'll use Next.js. So if you avoid Next.js in favor of ASP.NET rendering SDK, your development team's learning curve will be much steeper. Also, you may be more limited in sending data from your Sitecore XM Cloud environment to Sitecore Personalize.
You Can't Perform One to One Personalization Migration to XM Cloud
The migration of personalized experiences from XP to XM Cloud is not one to one. Personalization in XM Cloud is a limited version of Personalize, not the functionality from XP. Some of the rules available to you will even look the same but these execute in fundamentally different ways with XM Cloud. Personalizations should be rethought strategically and built in XM Cloud instead of migrated, especially if you’re doing a redesign.
XM Cloud limits you to:
- 8 variants per page
- 5 conditions per page
You can add the full Sitecore Personalize to your XM Cloud instance if you need more personalization options.
Access Restrictions Don't Work the Same Way in XM Cloud
If you're dealing with content access restrictions through Sitecore’s role-based security, that logic needs to be rethought in XM Cloud. These restrictions were often used for gating content, usually alongside some sort of authentication. Though field validations are now working in XM Cloud, access restrictions for end-users through the security field don't work. These will only apply to logged in users.
Completing Your Migration to Sitecore Experience Manager Cloud
Now that you know some of the potential speed bumps you can encounter while you're migrating to XM Cloud, you can plan head for them. Your Sitecore development team will know that you need to use Sitecore Headless Services to power your components. They'll also understand that custom modules from XP and XM can't be transferred, there isn't any form functionality at the moment, MVC Renderings likely won't work, there are major changes from previous versions of Sitecore, you'll probably need to make design changes to your website, there's no CD server, developers should work in Next.js instead of ASP.NET rendering SDK, personalization can't be migrated one to one, and content access restrictions don't work the same way.
Armed with this knowledge, your development team can develop solutions and solve problems for your business in a way that works specifically for Sitecore Experience Manager Cloud. That way your new Sitecore implementation will be set up for success on this SaaS platform.
Encountering any of these issues while you're migrating to Sitecore XM Cloud and not sure what to do? Or running into a different one we didn't discuss in this post? Contact us.
Our Sitecore MVPs can work through any issues you're having with Sitecore XM Cloud, so you can make the switch, and take advantage of this SaaS platform.