Almost every Sitecore developer needs to perform Sitecore upgrade at some point. Unfortunately, the process is heavy and there are lots of failure points and tricky parts.
In that blog post I will share some of the most important things that I learn while performing Sitecore upgrades.
Do not start without an upgrade assessment and an action plan!
Sitecore upgrade can take between 20 and 300 (or even more) hours depending on many things like how far is your
current version from the target version, how many Sitecore customizations are in place,
how much data is stored in the Analytics database etc. Every single thing matters, so do not start an upgrade before having
a good action plan.
Always perform Sitecore upgrades incrementally: you should go through every single revision between your starting and your target Sitecore version. Do not try to use shortcuts.
Patch the configuration files!
Following the Sitecore best practices every single change that you have in the Sitecore section
of web.config (or Sitecore.config in the later versions)
should be applied via
Sitecore Include Files.
This is good but not every project follows that guide and in some cases the changes are
applied directly to the web.config which makes your upgrade process a nightmare.
It`s always better to spend some time on applying the changes under the Sitecore section using patch include files before starting the actual upgrade process!
Try to keep your web.config (Sitecore.config) as close to the original one as possible.
You never know what can go wrong while upgrading Sitecore! You should have this in mind and create a backup of your files and database on every single revision that you go though.
On top of that keep your backups a certain time after you finish the upgrade process – some problems can appear when the users start to exploit the upgraded system.
Each server counts!
When upgrading Sitecore you should perform the upgrade steps for each server: CD, CM, DEV, QA, STAGING etc. If you want to reduce the upgrade time you have the option to
try to make some of the servers equivalent: for example, if you have CD, CM, DEV and QA servers you can try to merge the content of the DEV and QA instances. In this way, your
QA and DEV instances will be pretty much the same: having the same content. In this scenario, you will need to perform the upgrade for DEV and QA just once.
Check the pipeline processors!
When customizing Sitecore pipelines always play a main role. If you have custom pipeline processors you should check if they are still compatible. You also may need
to change the pipeline that you are using to apply your customizations.
Check the search implementation!
Sitecore offers different search options Lucene, SOLD, Coveo etc. Each of them hides compatibility problems that should be covered prior to starting the actual upgrade process.
Have in mind that some parts of the Sitecore Content Search API are different for the different Sitecore versions. It`s the case for the search configuration as well.
In some cases you may need to implement your search functionality from scratch! This should be added to your upgrade estimate, right?
Check third-party services integrations!
Sometimes Sitecore is just a piece of the whole puzzle. You may have Geo Location, Translation, CRM, eCommerce services integrated with your Sitecore solution.
Check all of them and especially the Sitecore API each of them uses for integration. You should be able to predict compatibility/integration problems in advance!
What about the modules!?
Go through every single Sitecore module installed. Some modules need to be upgraded as well, other are deprecated. For instance, Sitecore Social Connected, Language Fallback and
GeoLocation modules come with Sitecore out of the box for the later versions.
You even may need to implement a functionally that was covered by a module which is not available for your target version.
Plan content freeze period
In a perfect case scenario, your content team should stop entering content while you are performing the upgrade. Cool but in many cases this is not possible.
Imagine a news website to stop showing news for a week or even a month. Not good, right. In this scenario, you should evaluate content migration strategy.
With some clients manual copy/paste would fit but usually it`s not the case.
The tool that I use in situations like this is RAZL. RAZL allows side-by-side comparison and merge between two Sitecore instances.
The two Sitecore instances do not need to have the same Sitecore version so the tool works out perfectly for content migration.