Version Upgrades for Sitecore - Planning for an upgrade

Author: Anurag Agarwal | Categories: Sitecore CMS, CMS, CMS selection, Software, Websites

As mentioned in Part 1 of this series on upgrading versions of Sitecore, a version upgrade from a broader perspective looks as simple as executing some SQL scripts on Sitecore databases and installing an Upgrade package. However, most Sitecore customers that have attempted upgrades have faced complexities and challenges. What are these challenges and how can customers be better prepared for them?

In the first part, I also introduced you to some frequent questions that customers have around Sitecore version upgrades, and provided simple hacks for an upgrade process.

To take you a step forward, in this part of the series, we’d want you to prepare a plan and follow it religiously to mitigate risks associated with upgrades.

An upgrade plan must consider the following:

Determine your Version Jump Points

In order to know how you’re going to do your upgrade, you need to determine your current version and your target version. Sitecore upgrades from version-to-version often allow you to upgrade from each major release to the next, but not skip major releases. For this reason, you need to map out your plan.

Prepare everything upfront

Seasoned developers know that it takes a lot of upfront planning and discovery before actual development can occur on a project. This can help plan out tasks and break the larger process into smaller, manageable chunks. The same thing happens with the upgrade process. Each version jump is a pivotal milestone in the process, so it is good to prep everything upfront.

First, create a spreadsheet or some tabular way to track versions. Next, create some dummy folders on your file system for each version of the site. Yes, this sounds tedious, but you want to maintain the integrity of the site from start to finish, and having the separate incremental jump versions will help you with QA and in the case of a disaster.

Now that you have empty site roots, create new websites in IIS, one for each version. Again, this probably sounds tedious, but it will really help in the long run with identifying problems areas and overall QA. In your spreadsheet, for each version you have listed, list the respective www root folder, and the hostname in IIS.

Also, you should have been saving or bookmarking the various Sitecore download pages for each version along the way. Put in the links for these versions in your spreadsheet for fast access to exactly what you’re working on.

While we’re keeping track of everything, go ahead and list out the database for each site as well. Many Sitecore upgrades cause database changes, so it’s best to have unique sets. First, plan out the names using a version naming convention to keep the groups together.

Upgrade in segments

It is always preferred to upgrade in parts. Divide your upgrade into logical segments and then start the upgrade process from one version to the next.

Repeat the pattern

Now repeat this same process for the next release. Copy the site root from this newly updated version to the next again. Also, remember to do a database backup again but this backup should be done from the latest databases. Again, the database names should be listed in your spreadsheet. Update the dataFolder and connection strings again and do the backup all over again. Continue this process until you’ve reached your target version.

QA across Jump Points

Now that you’ve finished the process of upgrading, it’s time to run quality check on your website(s). For every jump site you’ve created, you need to test minutely. We recommend you to look at all of your pages for each version you’ve created, so you must ensure everything is consistent throughout. Also, test out the Sitecore interface and page editor if you use it. If you find pages that break, you can determine which version jump caused this break by having each site reviewed.

For instance, I find a major issue on a site going from v7.5 to v8.0. I receive parser errors on a multi-line text field. This leads me to the v8.0 documentation and release note which reveals that the FieldRenderer had some changes with break tags and new line characters. Thus, having all versions of the site allowed for an instant understanding of which version upgrade caused the issue. There can be a variety of other issues that arise, such as the breaking of dynamic stylesheets in the rich text editor, so it is advantageous to test each website being moved on each intermediary version till the target version is attained.

 We normally upgrade Sitecore versions manually. This leads to occurrence of many issues/bugs, and also needs the deployment of a technical team for months on the project. However, if there is an automatic utility which can upgrade you to higher versions and test automatically along the way, then it does sound like a treat!

In the third part of this series, we’ll be talking about some compelling reasons for upgrading to Sitecore 8.1 and how you can do so in a matter of days….so, stay tuned!

Sitecore, CMS