Nobody likes Sitecore upgrades. They're always ugly projects to do. There's a lot of work involved with little apparent reward, and they can cause all sorts of unpleasantness. But at the end of the day, any upgrade from your existing Sitecore version to the latest version of Sitecore is necessary and it must be done.

But why are they like this? Whether it's Sitecore 8 to Sitecore 9 or Sitecore 9 to Sitecore 10, no Sitecore upgrade is ever easy. Let's talk about some of the reasons behind everyone's favorite least favorite projects.

First, we need to talk about what goes into a Sitecore upgrade project. There are three major task areas that need to be performed during an upgrade process, defined by the people and activities that go into them.

• Environment Setup
• Upgrade Actions
• Testing & Validation

Environment Setup 

Environmental setup often includes coordination with IT or sysadmin-type people to set up an environment for the upgrade to happen. This is needed because, unlike in new development, you still have to keep a production website (and potentially ongoing development against that website) up and running. That means that while you may be able to get away with using some existing development environments for upgrade-related activities, you need a mostly parallel environment to allow for the work to be performed with no downtime to what's currently live.

If you're lucky, you're using virtualized hardware (or Sitecore in Azure PaaS), and it's easy to clone existing environments. That saves some time. If you're not as lucky, you'll need to provision new servers, copy over existing sites and configuration and get everything running in these new homes. This can all take quite a bit of time, and if sufficient rigor is being applied, it also requires a lot of testing to make sure that you're starting from a good baseline.

Upgrade Actions

Once the environment is set up, it'll be time to start doing the actual upgrade work. This generally breaks into two subcategories: upgrading sites and upgrading the "solution". A Sitecore environment is comprised of both the Sitecore application that lives on a server and the code that developers have written that provides all of the components used to build public-facing sites. In an upgrade project, both of these things need to be upgraded.

The Sitecore application needs to have its upgrades from Sitecore applied (the actual core of an upgrade), and the developed code needs to be updated to reference the appropriate Sitecore components and to work with the upgraded Sitecore application. The former task consists of many individual steps like "Remove reducer configuration files in the App_Config\Sitecore\ExperienceAnalytics folder". The latter can be as simple as clicking a few buttons in Microsoft Visual Studio if you're lucky. If you're not, it can include significant recoding of existing functionality. Both of these tasks can take considerable time.

Testing & Validation

Lastly, before you can launch an upgraded Sitecore instance, you need to test everything thoroughly. If you've got a rigorous testing process already, you may be in luck and only have to turn that testing process loose on your upgraded environments. If you don't have rigorous testing processes, an upgrade from an older version to a new Sitecore version will often be the catalyst for implementing them. 

These processes take time and effort to develop, especially if you need to create test cases from scratch or implement the gold standard of automated testing. These things are worth the effort and pay dividends far beyond an upgrade project, but site owners who ignore them do so at their own great peril.

Learn how automation can reduce the time and cost of your next Sitecore upgrade by up to 50%!