Sitecore Upgrade – How To Do It The Least Painful Way

Like many other enterprise-class platforms, Sitecore keeps up with the innovation path through regular updates/new versions and phasing out the older ones. As a Sitecore user, it is always recommended to upgrade to at least a version lower than the latest one. Bigger the gap between our installed version and the latest version, bigger the pain to perform the upgrade.

It sounds simple but is very critical to realize that an upgrade is just a stepping stone. The main objective is to move closer towards a superior customer experience initiative e.g. personalization. Hence an upgrade is done best if it is done quickly and without much errors.

Key phases of a Sitecore upgrade project: I love the classic way of breaking down every process into three phases:

1.      Pre-upgrade planning & risk-assessment: This is the most critical part of the upgrade project. If not done carefully we may end up in a situation where the entire upgrade might be required to roll-back. Risk assessment needs to be done by an architect who has done multiple Sitecore upgrades. These risks need to be registered and mitigation plan should be prepared before starting the upgrade. Some of such common risks are as follows:

a.      Deprecated assemblies/Custom Pipelines

b.     Difference between CM and CD instance

c.      Third party integrations

d.     Additional modules (WFFM, EXM, Commerce, xDB etc.)

e.      Search

f.       Content Freeze availability

2.      Upgrade execution & testing: Two most common methodologies for executing the upgrade are:

a.      Migration methodology: In migration a new instance is created and then the content is migrated to it. The biggest issue with this approach is that the customizations and integrations we had built in our previous instance are lost and have to be re-implemented within the new instance. This methodology is preferred when the customizations & integrations are only a few and not critical.

b.     Upgrade methodology:  This approach is similar to building a new house on top of the current house itself. This is typically done step by step, keeping the existing customizations/integrations etc. in-tact. Typically this approach is preferred when there are critical customizations and integrations in the current instance.

Testing is probably the most cumbersome part of the entire testing exercise and depends on the volume such as the number of pages, forms, components, integrations etc.

3.      Ecosystem upgrade and growth plan: Final step is to upgrade the surrounding ecosystem such as Search, Commerce etc. All these components need to be upgraded to be made compatible with the new version. The growth plan is many-a-times missed out by marketers but this is certainly the step that yields to the ROI from an upgrade.

Tools: There aren’t too many tools available for performing a Sitecore upgrade. Here are the key ones:

1.      Manual: This is the most tedious way and also prone to human errors.

2.      Sitecore Express Migration tool: It follows the migration methodology. Click here to read more about it.

3.      edynamic’s Sitecore Auto vUpgrade tool: It follows the upgrade methodology. Click here to read more about it.

Confusion Creators: The thumb rule of technology - every installation is unique and every upgrade poses new challenges. There are some big confusion creators where the answer would be different every-time. Here are the most common ones:

?      Step-wise Approach Vs. Direct Jump: Should I go for step-wise upgrade e.g. from 7.2 to 7.5 lower update and then higher by each update and then version; Or, should I go for a direct jump into the desired version. The answer will depend on the complexity of that instance e.g. customizations and integrations. I personally suggest following direct jump only in cases of least complexities

?      Non-responsive to Responsive: Though rare, but a lot of us still have sites which are non-responsive. The big question is whether we should make changes to the UI first or should we go for the upgrade first. Again there is no straightforward answer. All these decisions should be taken during the planning phase by the architect.

?      MVC to Helix: Updating the framework is not an easy task and hence the question again arises – should it be done before or after the upgrade. This again needs to be well-planned during the planning stage.

Sitecore upgrade, as said earlier, is an important stepping stone towards achieving a much larger goal. Hence it is always recommended to get it done as quickly as possible by seeking help from an expert partner who has done it multiple times instead of wasting time with experimentations.