In this part of the migration series, I am going to look at migrating an existing Sitecore Experience Platform (XP) “Global Brand” solution, with many sites and deep personalization usage, over to Sitecore XM Cloud and Sitecore Personalize. 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 “Global Brand” starting point
Some customers can have very complex Sitecore implementations. Sometimes you have years of technical debt, lots of separate application installations, different ways of building sites, different ways of deploying, different versions.
For this scenario, we are looking at a global brand that is doing delivery all around the world, with hundreds of sites. Some of sites are long-lived, multilingual, and multiregion sites like the official corporate brand sites. Others are short-lived campaign microsites that spin up and then spin down when the campaign is done. Personalization has been implemented on most of the larger sites, and some of the campaign sites.
In this scenario, the customer is currently running different isolated instances of Sitecore XP in multiple regions, with different versions. Some are on version 9, others on version 10. They have different Sitecore xDB data stores for the different regions to meet with regional data compliance rules, and the organization has multiple different authoring regions to support all their brands and different marketing teams around the world.
The need to deliver globally is a must-have and the organization would like to offload some of the responsibility for this delivery infrastructure scaling, as well as the overall management of the Sitecore content and personalization infrastructure.
From an implementation perspective, the dev teams have been building with different tech over the years. Many of the sites are traditional MVC or SXA sites, though a few are now running headless with Sitecore JSS on React or Next.js.
Not exactly the easiest road to SaaS in front of this team!
In this scenario, the customer had already started moving towards a distributed mesh of integrated systems. There are multiple vendor solutions in their architecture such as a DAM, a CDN, a SaaS marketing automation tool, and others. They now want to align their Sitecore application infrastructure with this architecture approach and finally go fully headless and SaaS hosting.
Step 1: Track with Sitecore Personalize
The first step on this road is adding Sitecore Personalize into the mix so that we can start tracking visitors. This will start building up the visitor data and ensure that any site that migrates over to Sitecore Personalize will have data already populated. Any new sites that get launched, like a new campaign site, could also be started immediately on Sitecore Personalize without using Sitecore XP personalization.
Why is this a good idea?
Adding Sitecore Personalize in at this stage to any site is a relatively low effort for the technical team, once the tenants are configured. By doing Sitecore Personalize first while still using Sitecore XP allows for the organization to gradually migrate the personalization from Sitecore XP to Sitecore Personalize. There are simply too many sites and too much personalization already built into this scenario to do a complete “lift and shift” for all the sites at the same time.
Additionally, this allows for the tool to be rolled out to the customer teams gradually. As more teams are brought on board, the organization can refine its onboarding process for each brand. Each team can start learning and building out personalization rules inside Sitecore Personalize, with Sitecore XP still serving up the existing personalization rules while they learn.
This approach also means that we reduce the number of new Sitecore XP personalization rules being built, which makes the later migration effort easier.
Things to watch out for
One downside to this approach is that we start having different analytics data in different stores. Teams are likely already using Google Analytics, and multiple Sitecore xDB sources, and are now adding Sitecore Personalize tracking into the mix. If there are teams doing reporting, this could add some hassle to their ability to report on data. One option here would be to ignore Sitecore Personalize data in reporting until a site is completed moved off of Sitecore XP.
There can also be some confusion when trying to determine where a personalization is coming from with two personalization systems running at the same time. It is likely best to try to make sure a given site or page is not using both Sitecore XP personalization and Sitecore Personalize rules at the same time. This will make it easier for implementation teams to isolate where personalization issues might be occurring and avoid potential conflicts.
Step 2: Go to the Edge
At this point we’re going to assume that the teams have Sitecore Personalize added to the sites. The personalization rules may not have migrated fully yet, but we are assuming that tracking is in place. Now we want to focus on reducing that massive Sitecore content delivery layer. We want to reduce the number of Sitecore content delivery instances that are required to meet visitor demands.
By adding Sitecore Experience Edge as a layer we can roll content delivery caching globally, meaning that requests for content do not need to go back to the Sitecore CD layer. This means that apps like Next.js can deploy a static site to a host like Netlify or Vercel and get the data from an edge layer, instead of going back to origin every time, ultimately speeding up build times and reducing the need for Sitecore CD instances.
But to get that advantage, that means we need to move to static sites, as much as possible, to put our end user site hosting onto a SaaS delivery platform. To get there, the implementation team needs to align to the latest Sitecore XP version which has the Next.js JSS SDK.
Is static publishing a shortcut?
Some of these sites may be easier to move to Next.js than others. Rebuilding a bunch of MVC sites might not be the best option right now, but we can take advantage of static publishing capabilities introduced in Sitecore XP 10.2 and migrate some MVC/SXA sites to Next.js delivery with less effort using the new SSG publishing of sites guide. It should be noted that this is for specific types of sites, and some complex sites might not be the right fit for static site publishing, which means they may need more of a rework. It’s probably best to target content-only sites first.
Moving to static delivery
Migrating over to a static approach is likely to involve a lot of coordination of teams, but this process can be done gradually. One key is to first identify which sites are going to be retired and won’t be migrated, thus reducing the overall effort.
As these applications move to static delivery, the need for the existing Sitecore content delivery infrastructure will go down. It is possible to even target parts of a site to transition to static, and take advantage of routing configuration to serve up certain routes from the existing infrastructure while you migrate.
When complete, most visitor traffic should now be going to the static site delivery layer. There will still be a need for a high availability Sitecore CD layer, though. These remaining instances will respond to server-side requests for XP personalization or other needs that haven’t been migrated. Unfortunately, we can’t eliminate it all just yet.
Why is this a good idea?
By building an architecture with Next.js+Experience Edge+SSG the business will get a few big benefits without doing a full rebuild of all the applications and sites. With Sitecore Experience Edge and static sites, teams should be able to get better global core web vitals, with less effort, which will benefit overall customer experience and SEO.
The ongoing need for global delivery also becomes much easier to achieve, and more simple to expand into new regions and target with new campaigns. All of this also combines with less responsibility for the delivery infrastructure, offloading that to Experience Edge and the static site host.
This approach also allows for gradually moving applications and specifically targeting sites where the best Return on Investment (ROI) will be.
Things to watch out for
There are a few things to think about. I mentioned aligning to Sitecore version 10.2 to get access to the tools you need for the static site publishing, plus aligning better to the eventual move to XM Cloud. Upgrades are often not trivial, especially when moving from earlier versions. If a particular site is on a version before Sitecore XP version 9, it may be better ROI to do a full rebuild/redesign project for that site and build directly onto the SaaS host rather than trying to move gradually through these stages. (This assumes the site is being planned to be kept at all.)
Also, any heavy personalization sites won’t be seeing much benefit from this transition, unless the marketing team has already been migrating personalization rules to Sitecore Personalize. If the sites use heavy server-side personalization, they’ll be pinging back to the existing Sitecore CD layer, and bypassing the benefits of the static delivery layer. If we really want to reduce the content delivery load here for sites that have a lot of server-side personalization, those sites should probably start transitioning to Sitecore Personalize as early as possible to reduce the number of requests back to the CD layer.
One final thing to look out for is the match of MVC sites to static publishing. As much as I wish it was, the static publishing available with Sitecore XP 10.2 isn’t magic and won’t be a fit for all sites. Right now, it does have some limitations that need to be considered (no multilingual, no media library, forms limitations, other limitations). If a site isn’t a fit for SSG publishing, one of the other methods to get to Next.js should be looked at for that site.
Step 3: Transition to XM
It’s time to keep moving on. Now that we’ve transitioned a lot of the traffic to edge delivery, it’s time to start ripping out all that managed XP infrastructure that is not going to be used. This means migrating the personalization in Sitecore XP over to Sitecore Personalize.
Why is this a good idea?
Getting to this point and eliminating all that XP infrastructure drastically reduces what the team is responsible for maintaining.
This architecture is also very close to what will be used in a Sitecore Composable DXP scenario with XM Cloud and Experience Edge, so we’re almost ready for that move.
Finally, by fully adopting Sitecore Personalize the organization is closer to that fully composable architecture and this opens up opportunities for headless personalization across other channels too.
Things to watch out for
One challenge is that Sitecore Personalize does not configure or execute in the same way that Sitecore XP does. Sitecore Personalize is also not natively integrated into the Sitecore XM editor (at the time of writing). Add to that the fact that the data migration is not a simple push or a 1:1 mapping, and this migration might mean a lot of digital strategy is needed to plan out how to achieve the business goals of personalization in a different way.
Some customers in this scenario may already have another CDP in play, in which case migrating xDB data into Personalize or SmartHub CDP isn’t a very good ROI. The data should go to the existing CDP and then Personalize should integrate with that CDP to get the data.
Want more details about migrating to Sitecore CDP/Personalize?
My colleague Dylan Young wrote a nice article to help with some of the decisions around migrating to Sitecore CDP or Sitecore Personalize. It might be helpful as you plan this step!
One final thing to mention is that transitioning to XM can be done a few different ways:
- Upgrade: As part of an upgrade to a new version.
- In-place: Make the change “in-place” on the existing installation.
- Lift-and-shift: Migrate to a new XM installation.
We have seen that some customers who try to do an in-place transition start removing functionality and there are references that don’t get properly removed. A lift-and-shift to new infrastructure is probably the best way to ensure that your target infrastructure only has the XM functionality, but this now adds a content migration effort into your transition.
But what if…?
At this stage, there are a few things that you might want to choose to do differently.
For example, instead of the Sitecore xDB data migration, a team could choose to skip that step and just use the gathered session data from Sitecore Personalize that was introduced in the earlier stage.
Another thing to consider is the use of isolated tenants. Customers of this size may need to use separate Sitecore Personalize applications, or they may need different tiers of functionality for different teams, or perhaps they need to divide by region. Sometimes this might mean one team needs a lighter-weight Sitecore Personalize for some scenarios, but other teams need to use a full CDP functionality for something else. Any number of these scenarios could mean the architecture doesn’t have a single “Personalize” box in the architecture.
Step 4: Migrate to Next.js JSS
By this stage we now have a Sitecore XM infrastructure using Experience Edge with headless personalization. Some of those MVC sites are still depending on that static publishing feature to get us here, and some of the sites are still relying on previous customizations that had been introduced on the CD layer. The next goal is to take the new Sitecore XM architecture and complete the application migration to Next.js without Sitecore CDs.
The first priority is to remove any possible customizations or Sitecore CD dependencies and move to fully Next.js applications. This application logic will usually move into your Next.js application, but you’ll need to look at what the logic is doing and determine where it fits best (service layer, edge functions, etc.)
The team also needs to make sure that any remaining MVC/SXA sites that were relying on the static publishing feature from the earlier stage have been completely reworked to true Next.js headless applications.
This work can always start during earlier stages, but what we are aiming for at this point is to make sure we have completed the full migration off of MVC/SXA and CD customizations for all sites.
Why is this a good idea?
In order to eliminate the Sitecore XM infrastructure, we need to first eliminate the dependency on Sitecore content delivery instances. That means that our Next.js applications need be pulling everything fully from Sitecore Experience Edge and API calls, with no reliance on customizations or server-side rendering. This step ensures the remaining architecture is ready for moving to XM Cloud.
Things to watch out for
Just like in the XM Jamstack scenario, we face the challenge of content delivery customizations. We have to remove these customizations and rethink them in a headless way. This is not always straightforward as you may have been used to building customizations against Sitecore pipelines which can alter output at a specific point in the rendering cycle. You’ll need to find the equivalent approach in your Next.js application.
Additionally, with this many sites running on SXA or MVC, there may be functionality relying on CD server session information. Those need to be solved for in a headless way on the static site. Unfortunately, this is so scenario-specific there isn’t much guidance that can given here other than to find it and replace it.
Step 5: Migrate to XM Cloud
Finally, it’s time to rip out the Sitecore XM infrastructure! The architecture has been prepped into a Jamstack model, just like in the XM Jamstack scenario. All of the Next.js applications have reached a state for a smooth transition. Our goal is to remove the Sitecore XM infrastructure and replace it with Sitecore XM Cloud infrastructure instead, which will be the responsibility of Sitecore to manage.
One or multiple XM Cloud instances?
One of the time-consuming parts of this task will be the content migration. Content must move from our Sitecore XM instances into Sitecore XM Cloud for all regions and all sites. In this scenario, we started with multiple Sitecore content repositories, which means we might have content conflicts if we push all the content repositories together into a single XM Cloud. Even without conflicts, there may be other business reasons to keep some of the content repositories separate.
For this reason, we may actually want multiple XM Cloud instances in different regions. We recommend deploying based on specific projects/teams as needed. From an architecture perspective, content reuse may be a big deciding factor on when you’ll want to share XM Cloud instances across teams.
Where should XM Cloud be?
Another factor to consider is the proximity to the content team. The initial version of Sitecore XM Cloud is not going to support geo-replication across different regions, which means that it is using a single origin in one region.
Tearing it down!
Once all of that content has moved into the appropriate XM Cloud instances and the applications have been pointed at the new Experience Edge layer, it is now time to tear down the Sitecore XM applications and the underlying storage and platform. No more Sitecore application infrastructure in your environment!
With the final bits of the Sitecore XM Infrastructure gone, the infrastructure is now fully transitioned to the vendor solutions layer. The technical team now has a fully headless architecture with a composable network of applications.
Through these steps, the applications have transitioned from layers of application and infrastructure responsibility to a network of connected SaaS point solutions, solving specific needs with the right tool for the job. Now the team can focus on bringing these pieces together and adding additional functionality to their solution by rolling out right pieces at the right time.
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)