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.
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.
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 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.
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.
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.
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!
To find out more about Sitecore, and how Box UK can help you get the most out of your Sitecore project as a Silver Implementation Partner, visit the Sitecore section of our website. Alternatively, if you have any questions about any aspects of the award-winning Experience Platform, get in touch with a member of our team.