How to Upgrade to Sitecore 10.4

It’s 2024 and I’m writing about how to upgrade Sitecore because believe it or not, XM Cloud hasn’t taken over the Sitecore ecosystem just yet. There are many Sitecore XP implementations out there and sometimes the cost of migrating to XM Cloud outweighs the benefits of sticking with your current solution. The sites out there running Sitecore XM/XP need to be upgraded as the version they’re on falls out of support.

Sitecore upgrade projects have, historically, been notorious for hidden complexity and ballooning costs. But it doesn’t have to be that way. With the right mindset and a planned, methodical approach, you can reduce the risk of your upgrade project and get it done faster. In this post, I’ll show you how.

Shifting Your Mindset

When diving into an upgrade, most people think it’s exactly that. Upgrading software in a solution. What I’m proposing here is a mindset shift. Rather than upgrading the platform dependencies in a codebase, consider it re-implementing the solution on a newer platform. Hopefully, that distinction will make more sense as you read this post.

I’m assuming you’re upgrading to Sitecore 10.4, the most recent release at the time of this writing. However, you can also apply these concepts to other versions.

Step 1: Take Inventory

Examine your codebase. This is especially important if you’re new to the project! Try to identify and list all the constituent parts of the solution, including but not limited to:

• Feature modules
• Page components
• Sitecore customizations
• External modules
• High profile or complex features
• Hotfixes or support DLLs
• Configuration patches

Put all these things into a list or spreadsheet that makes sense. Try to flag high-risk modules, dense features, or complex dependencies. You’ll update and refer to this list often throughout the project.

Of course, read the docs! Take the time to review the 10.4 upgrade guide in its entirety. Use this information when assessing the risk of running your code on 10.4 and to inform the timeline when you make your plans.

Step 2: Make a Plan

You know what they say, “failing to plan is planning to fail.” Chances are you already have a project plan. That’s great! If you’re a Sitecore developer, chances are your project plan has a line item like, “Upgrade to 10.4 — 30 days,” and that’s it. This is where we can do better!

After taking inventory of your solution, you should understand the number of modules in your code base. You should your integration points, what services you’re using, what software versions you need for 10.4, and so on.

Take the time to outline all of this. It’s a worthwhile effort for a couple of reasons. First, you’ll be able to provide your project manager with a detailed breakdown of the work you need to do. It will help validate that estimate in the project plan and highlight the risks so you’ll know where you’re likely to get stuck and can make contingency plans.

Second, going through this exercise forces you to re-evaluate your project once again. This will likely lead to more interactions or considerations as you decide the order in which you’ll tackle the tasks. For example, are you using WFFM on Sitecore 8 and going to Sitecore 10.4? What’s your plan for handling that module? Do you try to re-implement it with Sitecore Forms, use another composable form tool, or cut the feature entirely because you don’t use it anymore?

It’s always better to identify and plan for these things up front rather than get surprised by them mid-project. And, if you identify a feature to alter or cut, like the WFFM example, you’ll need buy-in from your stakeholders to do so. Better to handle that right away.

Step 3: Upgrade Your Sitecore Databases

Now it’s time to crack open the documentation and start running the steps. The first thing you should do is take your databases (usually Core, Master, and Web) and upgrade them to 10.4. Depending on the version you started on, this can be as simple as running a few SQL scripts. If you’re on Sitecore 8, for example, it can be a lot harder. You need to update to Sitecore 8.1 first, which means installing an update package and doing some manual steps. Hopefully, this effort was captured in your planning phase.

Don’t forget to run the Sitecore DB Cleanup tool! This tool will update your databases to remove stock items in favor of their serialized versions, a feature introduced in Sitecore 10. This tool also generates a log report of all the items it identifies as altered from the stock Sitecore installation. This list is crucial to diagnosing bugs and issues as you test your upgrade.

Step 4: Install a New, Clean Sitecore Instance

The next step is to install Sitecore 10.4 on your local environment, and the target hosting environment. This should be a clean installation of 10.4 with the stock databases and services. Make sure your certificates are correct, check your bindings, test your network and firewall rules, and so on.

Sort all these issues out now with a clean Sitecore installation. If you wait until you’ve deployed the new codebase, you’re introducing more variables, complexity, and failure points that could make these issues harder to diagnose. If you wait until the run-up to launch, you may need to delay the launch while you work through a ticketing system with a hosting vendor to get the necessary changes.

Next, take those upgraded 10.4 databases with all your content and restore them to your 10.4 DB servers. Update the users to use the logins created by the Sitecore installer, then make sure your connection strings in the web apps and services all match the new databases.

Log into Sitecore. You should see your content in the Content Editor tree. If you don’t see your content or get a yellow-screen error, you can handle it now.

Step 5: Re-Implement Your Solution

This will likely take most of your time and effort in the upgrade project. Do this one module at a time. If your solution follows the Helix patterns, start with the Foundation layer. If not, consider starting with code or modules that introduce customizations to the platform. Then move on to your features (individual components), and finally, your Project level modules to tie it all together.

Bring each module back into the solution one by one and test each one consistently along the way. It’s easier to stamp out errors and issues with a small unit of code rather than the entire solution at once. Often the only testing you can do is to ensure the Sitecore desktop still loads without a yellow-screen. And that’s ok!

For each module, examine at its constituent parts: serialized Sitecore data, NuGet packages, App_Config/Include files, and the code itself. Decide what order makes sense to bring them back into the 10.4 solution.

We have the serialized Sitecore items (already ported over with the database upgrade). Pull those back in for this module and make sure they sync properly. Then look at the packages in the module. For example, if your code references Newtonsoft, update the package version to match the one that Sitecore 10.4 ships with. If that doesn’t work with your code and you need to update to a newer version, you can handle that binding redirect immediately instead of getting caught in a version mismatch quagmire later. Next, you can compile your code and see if it builds and handles any obsolescence issues or other things that need refactoring. Make sure any automated tests that you have will still pass.

Finally, look at your configs. For example, make sure custom processors are still in the proper place in a pipeline. Or that a custom field or UI element in the Content Editor still works. Did the original codebase put the custom config into the Sitecore files instead of Include folder patches? Now is the time to change that and implement it properly. And of course, ensure the web app doesn’t throw errors when you publish the module!

Step 6: Make a Deployment Plan

You have your architecture plan from earlier, now it’s time to plan the logistics of the rollout. Work with your stakeholders, IT vendors, hosting providers, and whoever is necessary. Draw up a schedule that includes at least the following: performance testing, security hardening, functional testing, bug remediation, code freeze, content freeze, final content migration, project sign-off, and
go-live procedures.

Step 7: Have a Rollback Plan

Nothing is ever guaranteed in life, including the world of tech. Sometimes things get missed and you must roll back. Plan out the procedure for that. Rehearse it if you’re able to. Sometimes it’s as easy as switching the DNS back to the old servers. Usually, it’s not. How do you handle content created during the go-live and rollback decision, for example? What is the plan to re-launch after a rollback?

Anticipate Complexities to Reduce Risk

No single post can be all-inclusive when it comes to a big project like a Sitecore upgrade. Overall, this method of thinking embraces a shift-left approach. Ideally, that approach helps you catch issues early so you can fix them immediately, reducing your overall implementation effort. Handling an error introduced by a single module is much easier than tracking something down in 100 modules you brought over all at once.

With the right mindset and proper planning and preparation, you can anticipate complexities, communicate more accurate timelines, and reduce overall risk on your next upgrade project.

Need help thinking through your next Sitecore upgrade? Contact us. Our Sitecore MVPs and Sitecore experts can help you plan and execute a successful upgrade to the latest Sitecore version.