Hello Sitecore Enthusiasts!

In the previous post, we saw some basics of Sitecore Version Upgrade! In case you missed it, you can always go and have a look by clicking here.

In this post, I would like to share some findings while performing the Sitecore Version Upgrade.

Well, along with the findings, I have also had some brief/detailed explanation, based on some experience as well as some by asking in forums or searching on the internet. Reading the details or not is solely your choice, but if you ask me, I would insist you do it at least once! — if not be now then sometime later!

  • Always install Upgrade package in FF Browser rather than IE.
We somehow happened to have find it while installing the Upgrade Package in our local environment. Without going into much details of it, I would like to share an article written by  Kiran Patil, which explains it fully http://sitecorebasics.wordpress.com/2012/02/26/browser-timeout-error-while-doing-sitecore-version-upgrade/
  • Change the values of DefaultSQLTimeout and DataProviderTimeout.
By default, these two settings are set to 5 minutes, and actually they are not present in the Web.Config file. But, you can add these settings, in case you want to override them, and set it to something greater than that.
Lets understand why this is required. Sitecore Version Upgrade consists of two main things — the Database Upgrade Scripts and Installing the Upgrade Package.
While applying the Upgrade scripts, its never a problem, because we are directly working on the Database with Database Management System (i.e. say SQL Management Studio in case of SQL Database).
But, while installing the upgrade package, it is a continuous database activity from Application to the Database. And the time required to install the upgrade package, is relatively dependent to our database size — for us it took some Hours! :(
We had tried without changing this setting and it gave us SQL Timeout while executing the package, but after changing these settings, it worked fine for us.
Some details about what these settings would do — These settings define how long will the .Net Code wait, before it declares that the SQL query has timed out. These settings, would allow some heavy queries to be executed successfully instead of been claimed as time out.
To override these settings, Please add the following in the <settings> section in Web.Config File:
<setting name=”DefaultSQLTimeout” value=”00:30:00″/>
<setting name=”DataProviderTimeout” value=”00:30:00″/>
  • In case you have overridden some basic items,say from Content Editor Ribbon or Web Edit Ribbon, it is better to keep them in tact as packages.
A very important and a must remembered step! Majority of us tweak the Content Editor and/or the Web Edit Ribbon as well as some other options, say the right click Context Menu options and some others, to make our working environment easy. So, at the time you install the upgrade package, (i.e. at the time you execute analyze the upgrade package) you will be able to see, the conflicts for such items (in case they have something added) as they will not be same as basic Sitecore Items.
On ignoring this and moving ahead with installation, its quite possible that you lose your Custom Fields/Items from the Ribbon/Context Menus.
So its better to be on a safer side and make packages of such items and fields, so that you don’t have to rework after the upgrade package installation, just installing your package will make all those functionalities working again.
But one thing to be remembered while making such packages, is that only consider your custom items and fields while creating package and do not make a package of all the items with its subitems in the package.
  • Better apply your changes to the updated items one by one rather than installing a package from the previous version.
Well, we saw something above, and this is actually contradicting the above case. Instead of creating a package of your custom items and fields, you know what is a safer solution? Creating the items and fields all over again. Do this in your local development environment, and after you upgrade, and check that they are working fine. Then you can obviously create package from this upgraded environment. This one would be safer, as you in no case would override any of the Sitecore items that you shouldn’t have.
  • If you are upgrading your Sitecore solution, do keep at least one of your older versions up and running so that its easy for you to compare!
I think this point should be marked with High Importance! We need to and must have at least one old version running either in our Development Environment or somewhere, so that at any point of time we can directly compare after upgrading our Sitecore Solution to the target version.
This is because there maybe some deprecated functionalities, and some newly added ones, or some replaced by some others which may affect your Business needs, say just like Sitecore replaced Telerik RAD by Telerik RTE, which had many changes, and even though RTE had many added functionalities, It was missing out some of our Core Requirements, which we had to plug-in to it, with help from Sitecore and Telerik.
  • Always decide your Target Version based on your Business Requirement rather than the Recommended Version.

I do agree, I am going somewhere different from what any Sitecore Lover would say or a Sitecore Professional would say. If you ask anyone from Sitecore, which version should I upgrade my Current Solution to, they will always say, the Recommended Sitecore Version.

But practically, upgrading a Sitecore Version is not that easy a job! Also, this is not what you are going to do every now and then! So make sure before upgrading to which Sitecore Version you want to upgrade your Current Solution to? This decision should be specifically based on is the main for you to upgrade covered in your target version?

Lets say, you have requirement “A” for which you want to upgrade your Sitecore Solution.

Now, if that “A” is already taken care in some Sitecore Version “X-1″ and Sitecore Version “X” is the recommended version, then please upgrade to the version “X”. :)

But, in case the requirement is covered in some version say, “X+2″ then better go with that Sitecore version “X+2″ — but only after making some serious study, that the version “X+2″ does not have any performance hit or some critical issues reported. For this, you may refer to the Sitecore Developer Forums or ask Sitecore Support directly, as to whether you can go ahead with it or not.

  • Comment out your custom Commands/Processors/Agents/Schedulers if any in your Sitecore Solution before going ahead with installation of Sitecore Upgrade Package.

Here, I would like to share something that we faced while upgrading our solution in Local Environment. We had a custom command in Commands.config — specifically for delelting items in some way — and you know what we were facing? After upgrade when we checked, the items in Core Database for WebEdit Ribbon, the item’s content were not present. (It asked us to add a new version). At first we were shocked, and thought might be some mistake from our side only, and hence did the whole procedure again, with the same result. Then, we tried commenting all our Custom Processors & Commands and everything, and Bravo! It worked.. This was as suggested by a Great Sitecore Lover - Kiran Patil! 

Some other low priority issues that we faced on our end, would like to mention them as precautions to be taken:

  • Sometimes, if you get an error related to the Database Schema, dont worry, just proceed to your Target Version.

It was in our case! For more details on this please refer to the following article : http://varunvns.wordpress.com/2012/06/12/error-while-applying-upgrade-invalid-column-name-sequence/

  •  Shrink your Databases so that you don’t have a heavy LDF files, and all/most of your data is in MDF so that the upgrade Transactions can perform faster.
  • Always Analyze and then Install the upgrade package, and make sure you save all these Log Files. You never know when you require those!
  • [Update] Keep a full backup of your databases as well as application before starting the Upgrade, and also keeping a second copy of the same databases restored with a small modification of names, so that in case of some issue, reverting back in application as well as databases is possible in minimum time. —  Thanks to Devashri Oza for this point! A quite important one when we talk reverting on Live environment! [/Updated]
These were some of the findings that we did and I am penning them down here!
Thank you for reading this Article patiently, and Sincere Apologies for such a long and a theoretical post! :)
Hope you guys enjoyed and/or benefit from this article!
In case you face any other issue, or have any other finding, please share it here in Comments to this Article, so that it can help some more Sitecore Enthusiasts!
Happy Sitecore Version Upgrading! :)
About these ads