Frequent Sitecore upgrades are good!

Frequent Sitecore upgrades have convincing benefits and lower its TCO.

My employer’s current practice is an annual Sitecore upgrade. I recommend this as the maximum interval; we should do more frequent upgrades when important-to-us new features, fixes, or enhancements are released. It may be prudent to even consider twice-a-year upgrades given Sitecore’s rapid release schedule.

Here’s the specific benefits of frequent upgrades:

  • Fast track putting UI enhancements and bug fixes into production.
  • Puts new features front and center. Even if we don’t use these features right away, they are often the basis of near-term enhancements.
  • Fast track putting enhanced modules into production. Many times, newer module versions require upgrades of the base product, too.
  • Avoids bifurcated environments. Aggressive upgrade policies reduce the pressure to try out and do development on newer releases than what we have in production.
  • Avoid cost of delaying implementing new features. We once delayed upgrading from 6.2 to 6.4. This contributed to not-aggressive-enough learning of 6.4’s enhancements, causing our old technology to get more deeply ingrained in our practices. This made our move to 6.4’s paradigm more complex.
  • Reduced upgrade complexity. We and other customers experienced difficult upgrades when we failed to upgrade frequently. Frequent upgrades means each upgrade is more of a snack than a huge meal.
  • Better supportability. While Sitecore has a generous support policy—they appear to support many versions going back—it is inevitable economic reality that dusty versions will have a harder support experience. The best companies are aggressively forward-looking.
  • Cleaner install and better reliability due to reduced use of hotfixes. If we do a frequent upgrade regimen, we can often defer hotfixes to when problems get fixed in future releases. With infrequent upgrades, we will be under pressure to rely more heavily on hotfixes (customizations) that 1. must later be backed out, 2. may not be as well-tested, creating unintended consequences during use, and 3. when backed out, could cause unpredictable changes.

My employer has a legitimate fear of frequent upgrades due to its experience with our ERP. Indeed, upgrades to this ERP are monstrously complicated. A Sitecore upgrade is a fraction of the complexity of an upgrade or even a patch on our ERP.

Due to the way Sitecore is architected—it generally disallows spaghetti code or direct modification of vendor code or logic—and my disinclination to customize the base product, compared to our ERP, it is rare that we will run into code incompatibilities with newer versions. Our custom code will usually “just work”.

To conclude, I recommend frequent upgrades whenever possible. It has convincing benefits, and, really, it is just a sign of an engaged product owner that wants a relevant, competitive web marketing presence.

2 thoughts on “Frequent Sitecore upgrades are good!”

  1. Totally agree with the idea that frequent updates are the way to go both in terms of the CMS itself and the web site code that it is running.

    To make the CMS easy to upgrade it helps immensely to develop outside of the web root and make good use of include files for customising your Sitecore configuration. This draws a clear line between your application code and the installed Sitecore version.

    There is a growing trend around Continuous Deployment of all types of web applications, including those based on CMS products. Back in March Aqueduct gave a presentation showing how they practice Continuous Deployment with Sitecore. They shared some great advice on automation and the tools that can help with this, here’s the link

    1. Thanks for that video. That’s pretty good.

      I’ve hesitated at getting too deeply into all the tools and tricks he has because, since we’re in-house Sitecore support, we’re not “all Sitecore all the time” here. Sitecore is maybe about 50% of the time of 2 devs. E.g., TDS. It’s slick, but the cost of learning, supporting, and using it appears to outweigh any benefit from our one-instance setup here.

      I was intrigued by how Aqueduct has no feature branches! I can see value in saying no feature branches should be used in your QA or pre-production environments, but I don’t understand that for developer instances.

Leave a Reply

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