It's safe to say the one thing on almost everyone's mind lately is, how do we get our websites modernized so they remain under support, and even better, headless and in the cloud. Like many of you, I recently drew up the roadmap for such an effort for a bunch of supported clients. In one project, I'll be upgrading my company's v9.1 managed cloud multisite instance to XM Cloud-based v10.x. When the words “full rewrite” hit our stakeholders, the request was to break this down into digestible chunks, so it could be dispersed across a couple budget cycles.
So here we are. This is the first installment in my series called, “The Road to Headless”.

In the example below I'm going to assume there's just a Content Management and Content Delivery role in place. Our real-world managed cloud has about 7 apps for different roles, but it's not important for this topic.

What's Going to be different for your team

Users of Sitecore's won't see much of a difference after an upgrade like this, but your development team will require complete retraining and/or reconstruction. Here's some things to consider:

• The workload will shift a great deal towards the front-end team, and they should be proficient with NextJS. If they're not you'll need to get them trained, or you can hire a lead developer to bring them up to speed.
• The back-end team will need to learn Azure functions for your customizations, since Sitecore as a SaaS offering won't provide this flexibility.
• Your development environments will be different if you're going the cloud route. 
• You'll be using an entirely different deployment process, an unfamiliar management system for this. Training is available.

First, the Fast and Straight Approach to Cloud

My first option was to use the following process to upgrade the site:

1. Inventory the custom pipelines, content components, installed modules, etc., and make that our work breakdown structure (WBS) from it.
2. Run workshops to determine what customizations and components are still needed to try and reduce overall effort. I find in time the client realizes something “cool” in the first implementation was never really used by their team.
3. Identify what won't work for XM Cloud since customizing Sitecore is no longer possible and create a list of Azure functions that can help bridge this gap.
4. Establish a template for our developers to follow as they transition from MVC (or even yes, Forms), so they can run through the inventory of components that will make up the new site.

This is by far the most efficient way to get modernized, but it's a big investment. I have some clients on v7.2 so it's obvious they're in need of a big change, and they've been anticipating it. There are others, however, who haven't been online all that long and are still looking for their ROI of the first build. They need something with a little less effort.

The Phased Approach We're Going to Take

Let's talk about doing this in smaller pieces. Like I said earlier, this could be due to financial constraints, but there's other possibilities such as small or inexperienced development teams. We can break down the transitions into smaller pieces.

Step 1 - Get to the latest version

Ensuring we're still in a supported version is most important, so we want to either upgrade in place or do a lift and shift (like I will be doing). This will get the instance in a safe place if it was out of support before, and it also starts to expose the development team to new features offered by Sitecore 10+. Like I said, make no mistake, your development team is going to need retraining in the following steps as nearly everything is different about the new architecture. 

Step 2 - Rebuild the front end, site by site

Once upgraded, the new version will have Sitecore Experience Edge, so the front end team can build an app to use it. I'm upgrading a multisite solution, so I'll have the team run the smallest site first since it's simple with no need for things like Azure functions, Personalization, etc.  The team can understand the development and deployment process in this easy win of the front-end side, and then move on to the larger and more complicated sites.

Once all sites are migrated to headless, the Content Delivery servers can be decommissioned (after a stabilization period). So all we have left of a monolithic approach is the Content Management server.

Step 3 - Prepare for XM Cloud

Now that the sites are running headless, we can prepare the XM instance for its journey into SaaS. All customizations that require migration to Azure functions can do so while we're still using the monolithic instance, so the transition can be broken down into smaller efforts.

The solution can then be deployed and validated, along with full content migration before switching over the cloud instance, which ends the dependency on anything monolithic. Of course, before making this final move you can always take advantage of the XMCloud Migration Readiness Package offered by Sitecore, where they review your entire solution.

What's Next

That's it for a high-level overview of this journey. Stay tuned for an in-depth look into each of these steps as we upgrade some clients this year.