In this part of the migration series, I am going to look at migrating an existing Sitecore XM “Jamstack” solution over to XM Cloud. Follow the series to look at different Sitecore XM and XP scenarios and how you can gradually migrate your Sitecore platform solution over to a composable DXP architecture.
The goal is to walk through the example migration and highlight for you:
- What challenges will you face along the way?
- What options are available and when do they make sense?
- What are the benefits of making certain changes to your architecture?
Every project is a little different, so hopefully this series can help you understand some of the questions to ask, and what options you have, to guide you in the right direction.
The “Jamstack” starting point
In this scenario, we have a team that keeps updating to the latest Sitecore all the time and builds headless apps. They have done so many upgrades now that they know how to do it, but are interested in never having to do these upgrades again.
The team has multiple layers of responsibility:
- At the top, we have applications that have already been transitioned into a SaaS or Composable DXP architecture. This is where their static site is being hosted, with Vercel.
- Their solution is running a headless Next.js JSS site and primarily using Sitecore Experience Edge for global content delivery to support the static site.
- In their marketing services, they are currently only using content features, nothing from XP, so they have a simple XM infrastructure to support this.
A while back, the team started moving responsibility for the infrastructure out of their own VMs and had migrated to Managed Cloud. They initially adopted containers and had to ramp up a lot on container technology within their team. So the team is familiar now with Docker for their local development and has developed a GitOps flow that works for their Managed Cloud infrastructure.
Their site has a global delivery, but is pretty simple from a solution perspective. A single language, only a single website and no other channels, and they have a centralized content team.
The marketing team has hinted they want to introduce personalization, but it’s “Phase 2” and still waiting to be done.
So how does this move over to XM Cloud?
The transition for this team is going to be straight-forward.
The Next.js application should have little to no changes required as the schema for Experience Edge is the same for the both XM and XM Cloud. Next.js JSS SDK uses the same calls too, so the team could do this transition even if Experience Edge wasn’t there.
The team will need to migrate the content from XM to XM Cloud though. That is the likely area where most of the effort will go, focusing on validating that the content is imported correctly.
Why does this scenario matter?
This scenario seems, on the surface, to be “too easy”. One of the main reasons to show this simple scenario is to show an ideal state that you can target in your existing Sitecore platform architecture to make for an easier transition when you are ready to move to XM Cloud.
Most teams with an existing Sitecore XM architecture might not be at this starting stage, but it can give you a sense for what you might want to target from where you are if you have a simpler XM setup.
Things to watch out for
We all know content migration is never “simple”. This one should be easier than most (XM to XM), but I wanted to call it out because somebody always has a strange piece of data that nobody expected so the team will need to expect regression testing for this part.
Another thing to watch out for is content delivery customizations. There are no content delivery instances in XM Cloud, so you need to remove all those customizations and solve that in another way in your headless application.
As a note, since XM Cloud has no Sitecore Experience Platform (XP) features available, this means that any XP modules you have will not migrate, even if you are only using the content parts of those modules. Teams need to do an audit of the modules you are using to see if there are any XP DLL dependencies, especially if you are running XP in CMS-only mode.
Related to this is Sitecore Forms. XM Cloud will not be offering this as a module, so if you have dependencies on Sitecore Forms those forms will not be able to migrate over. Right now the best bet is to pull in one of the many headless forms products from other industry vendors to keep your solution truly composable and not tie into the MVC-based Sitecore Forms module.
Watch the session!
I recorded a session with Pieter Brinkman (@pieterbrink123) talking about the migration from the Sitecore platform to the Sitecore Composable DXP. You can watch it on YouTube now!
Top comments (0)