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.