The importance of upgrading Sitecore
Just in case you weren’t already aware, Sitecore is an incredibly powerful platform, supporting the delivery of personalised experiences at every stage of the customer lifecycle and attempting such a feat as performing an upgrade to it has haunted many a developer’s dreams.
It’s vital that you start the right way, go the right way and finish the right way. In this article we take a trip along the Sitecore timeline, highlighting the significant changes in each version and how they may impact your upgrade process.
Considerations before starting any upgrade
- Sitecore modules: Web Forms for Marketers, Email Experience Manager, Active Directory, CRM integrations – each of these modules will be specific to a particular version of Sitecore, and have its own specific upgrade process. So it may be a case of moving to a new Sitecore version > updating modules accordingly > continuing to upgrade Sitecore… The dependencies between these modules can also be incredibly complex, so make sure you have a clear view of the order in which upgrades need to be made before you get started.
- Sitecore Marketplace modules: Sitecore has an extensive Marketplace, and any modules sourced from here will also need to be upgraded. As these aren’t created by Sitecore you may need to upgrade by downloading the source code from GitHub and/or getting in touch with the creator, but in some cases modules are simply no longer supported.
- Bug fixes: If you’ve had bug fixes through from Sitecore for past issues, you should check whether these have been permanently resolved in the new version, and remove the temporary fixes accordingly.
- Customisation: Make sure that any custom code you’ve implemented will still work on the new version of Sitecore. There are always slight changes (such as the order in which code gets executed) to watch out for, but generally if the code has been written according to Sitecore standards it should continue to work without too much hassle.
Pre-Sitecore 7: steady progress
Up to Sitecore 6.6, upgrades follow a fairly standard process. You take your codebase, download packages from Sitecore and follow their instructions. Simple! Except… each version of Sitecore has a minimum version from which you must upgrade. Oh and that minimum version has its own minimum version you have to be on to start with… and repeat. So upgrading several versions must be done in a series of small hops rather than a single bound.
Sitecore 7 and 7.1: breaking changes
While there is clearly still a lot to think about, the upgrade process up to Sitecore 6.6 is generally steady and incremental. The upgrade from 6.6 to 7 introduced some ‘breaking changes’, on the other hand, that make the process a bit more exciting than downloading a couple of packages.
These changes were mainly centred around the underlying search system, which saw all the APIs used for search completely overhauled. Consequently, upgrading to this version requires organisations to make updates to the code powering their search. Not such a major issue if you are dealing with perfect, unit-tested, search logic!
In Sitecore 7.1, the major change was in the Sitecore Rules Engine, which was reorganised and changed in several areas. However, the upgrade process includes several checks and post-installation processes to make sure your system is restructured appropriately, so there shouldn’t be any major issues (although it doesn’t always work, so be vigilant!).
Sitecore 7.5 and 8: the big shift
Sitecore 7.5 saw possibly the biggest change yet; one so significant that many organisations have chosen to stick with 7.2 rather than tackle the upgrade.
The changes centre around Sitecore’s Experience Database, which powers the platform’s sophisticated analytics capabilities. The database used to collect and store this information wasmoved from Microsoft SQL Server to MongoDB.
This introduced a whole new technology into the Sitecore platform, and with it the requirement for a new server architecture to support it. This can either be done in-house (which has obvious cost implications) or through a cloud service such as those provided by Rackspace, Mongo or Sitecore themselves. With many Sitecore-based organisations entirely Microsoft-led, this is often a major challenge, as it involves a completely different technology stack to the traditional Windows and Microsoft Servers. A completely different skillset is needed too, as teams need to be able to react to issues with the MongoDB server in a production environment, alongside performing maintenance, and fine-tuning security and performance.
Sitecore 8: test everything
With such significant consequences then, why did Sitecore move from SQL Server to MongoDB in the first place? The answer to this question starts to become clear when looking at the updates released in Sitecore 8.
With this version (and the subsequent 8.1 update) Sitecore has embraced a ‘test everything’ mentality, meaning that analytics can be collected, assessed and actioned across every element of the platform, not to mention externally, thanks to the introduction of an API that feeds data in from sources such as mobile apps and non-Sitecore websites. As more and more of this information is stored centrally in Sitecore, databases will subsequently grow in line, and while SQL Server just can’t handle the scale of data required, MongoDB is perfectly suited to scaling.
The improvements to measurements and testing may be the Sitecore 8 headlines, but when you’re upgrading to these versions make sure you also consider the impact of changes that have been made to give the platform a brand-new new look and feel. While in general these are highly backwards-compatible, there may be implications for front-end customisations such as content editors and wizards.
Another way to upgrade
So, there you have it. Sitecore upgrades need to be done incrementally, with consideration at every stage of the changes – major or minor – that may affect existing functionality. But take off your armour, there is another way.
If Team Development for Sitecore (TDS) is used to manage Sitecore builds, then your code can be deployed straight into a clean install of Sitecore 8, and you can make use of the item serialization features to port across large amounts of content. But think very carefully about whether to take this route over the more traditional, recommended upgrade process. You need to know exactly what you’re doing and even then things may not go to plan.
For example, if you’re using the Sitecore Experience Database, you risk losing extremely valuable data unless you migrate everything across correctly which can take several days if the database is large. Don’t forget too that the breaking changes from earlier Sitecore versions will still apply, so you’ll need to have updated code for elements such as the search system and rules engine primed to go before you begin.
Conclusions
As you can see, when it comes to upgrading Sitecore there’s a lot to think about. However, it isn’t as scary as it may look – as long as you know what to be aware of in each version, and how it applies to your specific Sitecore implementation, everything should go smoothly. Good luck!
As a Silver Sitecore Implementation Partner, Box UK can support you in getting the most out of your Sitecore project, while our team of bespoke software consultants have two decades of bespoke software development experience, to help address any digital challenge you’re facing. If you’re interested in finding out more about how we can help you, contact us on +44 (0)20 7439 1900 or email info@boxuk.com.
