Sitecore Upgrade Strategy

There are many parts to the full life-cycle of a Sitecore solution and one that often gets ignored or de-prioritized is the upgrade process. Like other pieces of software available on the market today, Sitecore comes with a built-in update/upgrade mechanism. Ok, let’s be real, its not like WordPress’s one-click, 10 second, upgrade. The Sitecore upgrade process is certainly involved, but definitely doable. The key to continuing to leverage all of the new features and enhancements of Sitecore is to have an upgrade strategy in place and keep on the upgrade path. This post is an examination of various things to consider when doing an upgrade and more specifically, a roadmap for upgrading across many versions.

Determine Your Version Jump Points

First, 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. For example, I recently upgraded a solution from 6.1 to 6.3.1 (latest recommended release). I will use my recent upgrade as an example here. The process involved:

  1. Go to the download page for the target version (6.3.1)
  2. In the upgrade section, find the prerequisite version and take note of it and the download page URL (in this case, 6.3.0 rev. 100716+)
  3. Following the same pattern, go to the prerequisite version of the version you just note
  4. Continue this process until you determine each version you need to upgrade to, in reverse order
  5. Once you find all versions you need until you’re current version is within the prerequisites, you can start to plan your upgrade process

For me, upgrading from 6.1 to 6.3.1 involved these version jump points:

  1. 6.1 – original version
  2. 6.2 (initial release)
  3. 6.3 (initial release)
  4. 6.3.1 – target version

Prepare Everything Up Front

Now its time to prepare everything you can up front. Seasoned developers know that it takes a lot of up front 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 is true with the upgrade process. Each version jump is a pivotal milestone in the process, so let’s first prep everything up front.

First, create a spreadsheet or some tabular way to track the 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. You’ll probably want something like this for a file system:

  1. c:\inetpub\wwwroot\mysite (this is the original)
  2. c:\inetpub\wwwroot\mysite_620
  3. c:\inetpub\wwwroot\mysite_630
  4. c:\inetpub\wwwroot\mysite_631

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 listed, list the respective wwwroot folder, and the hostname in IIS. For me, I used the following hostnames:

  1. mysite
  2. mysite_620
  3. mysite_630
  4. mysite_631

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 its best to have unique sets. First plan out the names using a version naming convention to keep the groups together, e.g.

  • MySiteSitecore_620_Core
  • MySiteSitecore_620_Master
  • MySiteSitecore_620_Web

This is what your spreadsheet could look like:


(click for full-size)

Upgrade in Segments

Now that all prep is done, its time to start the upgrade process. First copy your original site into the next version’s folder (e.g. copy into c:\inetpub\wwwroot\mysite_620). I highly recommend you use a free program such as TeraCopy to copy the files at fast speeds. Seriously consider TeraCopy, it will really copy much faster than Windows. Leave the other dummy version folders alone at this point. To save some time, delete any temp files you can from your site before you do the transfer. This will make your copy operation leaner.

In addition to copying over version-specific files, you need to backup the databases and create new versions of them. Backup the initial version’s databases (core, master, web — no extra module databases) and create new ones with a similar version naming convention. The database names should be in your spreadsheet, so its a matter of copying and pasting the names you listed.

Update the configs for your newly copied files. Once your files are copied over to the new site, make sure you update the dataFolder path in the web.config and update the IIS site root to the “website” folder. Also update the ConnectionStrings.config to use the newly duplicated databases. Make sure your site runs at the new hostname (e.g. mysite_620). At this point it’s still running the former version of Sitecore, despite the hostname.

Now go to the SDN download page for the version your upgrading to (the link should be in your spreadsheet). Don’t do anything except read the upgrade directions. Once done, re-read the upgrade directions. Download the update pseudo-package (it ends in .update) and any other files for the upgrade, like .sql files. Follow the directions and do your upgrade.

If at any point in the upgrade you get a .NET error about permissions, its likely due to the process that’s running the site trying to replace Sitecore DLLs. This is ironic because Sitecore its literally trying to replace itself. You’ll end up with a clash and get a .NET error. Don’t worry. Just go to your site root’s “temp” folder (e.g. c:\inetpub\wwwroot\mysite_620\website\temp). In here find the most recent Upgrade folder (marked by the version number and timestamp). In that folder run the process.bat batch file which will overwrite the DLLs with the new ones. Try our your site now and it should work.

Repeat the Pattern

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

Note: Not all upgrades are the same in both effort and timing. Some may be fast while others will require extra work, like updating database schemas.

QA Across Jump Points

Now that you’ve finished the process of upgrading take a break — it’s probably been a few hours. Now it’s time to QA the site. Errr, I mean sites. For every jump site you’ve created, you need to QA. Seriously. I recommend you look at all of your pages for each version you’ve created and ensure everything is consistent across all. Also test out the Sitecore interface and page editor if you use it. If you find any pages that break you can determine which version jump caused this break by having each site to review. For example, I found a major issue on a site going from 6.2 to 6.3. I received parser errors on a multi-line text field. That led to the 6.3 documentation and release note which revealed that the FieldRenderer had some changes with break tags and new line characters. 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 dynamic stylesheets in the rich text editor breaking, so really take advantage of having a site for each version to QA.

Summary

If you follow the detailed directions above, you’ll be able to manage a potentially overwhelming process by breaking it down into separate tasks. As with all things a developer does, take each piece at a time, in this case a version upgrade. Separating out all of the versions will give you better visibility into what versions could cause issues on your site. They also serve as checkpoints. If one of the later upgrades fails you don’t have to start at the very beginning. You can also more consistently QA your site across every single version change to understand at what points things change with the Sitecore API and/or the Sitecore interface.

 

Mark Ursino

Mark is Sr. Director, CMS Practice Lead at Rightpoint and a Sitecore Technology MVP.

 

9 thoughts on “Sitecore Upgrade Strategy

  1. Hi,

    We also want to achieve the same goal by moving from 6.1 to 6.3.1. This is actually a recommended way from sitecore.

    But I was thinking some other options as well. Like can we directly install the 6.3 and then install the full content package from current tree? i

  2. Hi Vipul,

    Based on the Sitecore documentation it doesn’t look like you can do that. My question would be, why would you want to? It would save them but if there are any breaking API changes in the process it will be harder to fix and/or QA. My approach above is intended to help you plan a large upgrade which spans many versions. It assumes you will follow the normal upgrade path provided by Sitecore.

    1. Hey Mark,
      Thats a good answer. The reason I came to this idea is, we have 3 different environment. And in Dev we have almost 6 more instance of same content tree for each developer. Also we have QA and Prod. Lets say this option is good for DEV and QA. People can spend time and then do quick regression test, But how about Prod. For this process we might have to change the database name and all. Also, we might have to put a cut off time which we want to avoid if possible. Any suggestions in this regard?

      1. I would recommend you duplicate your prod site and databases and run the duplicates in parallel of the live site. Maybe do all of the temp version sites not on the prod machine, maybe on a dev or QA machine. Then once you’re all QA’d and good to go, move the final upgraded site to the prod server and run it in parallel of the live site. Give it a test hostname, e.g. www2.yoursite.com then once you view it in the live environment and its good, swap the IIS hostnames to point to the new site. If you keep the folders and databases with the version number it will make it easy to identify what version of Sitecore its on.

  3. Hi Mark,

    thanks for the great post. It has helped make the process much easier to undertake. I’ve gone through the process on a local version of our site and it has worked well. One of the complexities which you don’t mention much is the need to recompile your code with some of the updates. How you manage this is important and can bring in the need to branch your code if other development is going on or you want to maintain the ability to push changes up during the upgrade process.

    The other concern I have is for content that is created during the time it takes to do the updates and testing. Hopefully the testing will be minimal because I have done this already with a local version, but it is never the same as on a server so some testing will have to be done then too. Can content packages be safely created on one version and installed on a new one? I have tested this and it seems to work but I thought I’d check and see if there are any issues I might be missing.

    Thanks again,

    James.

  4. A few hours!? I laughed when I saw that. I’m doing an estimate to go from 6.3 to 6.5 and I’m thinking 10 days!

    Mark – with your upgrade were you upgrading a client site or a vanilla instance for testing purposes?

    A colleague I was just talking to mentioned a client who tried the upgrade path and it failed to the point that the started again by just setting up the target version site and deploying everything across.

    My gut wants me to follow the upgrade path but I can see sense in starting with the clean install of the latest code.

    1. This was for a client, not a stock install. Not only was this an upgrade from 6.1 to 6.3.1 but it was an existing application we did not develop and didn’t have source for, only compiled DLLs.

      Its less about an exact figure and more about managing the pieces that go into the upgrade. If you have significant integrations and touch points to test, those take hours of testing. I’m talking about the raw upgrade of Sitecore, not the overarching entire process which has more pieces to it. If you simply following the detailed instructions from Sitecore on an upgrade, you will see the raw upgrade itself does not take 10 days, it takes a seasoned developer a few hours per jump, bundle them together and you’ll gain momentum. For every non-best practice implemented, you risk your upgrade path being deviated and increase the exposure to more cans of worms.

      I’ve done many Sitecore upgrades before and they all vary, as I said, its largely based on each solution and all of the customizations that go into them.

  5. Hi Mark –

    I know this post is old but your approach is great. Thanks for sharing your ideas.

    We use git so i’m going to try and extend your idea by using commit points (or branches) for each upgrade. Using this approach I can then upgrade the same folder and fall back as needed.

    If this works well I’ll update my blog with my approach.

Leave a Reply

Your email address will not be published. Required fields are marked *