Assess and Document: The Present

Before diving in, access how deep the water is.

Until and unless you belongs to that rare breed of an IT team which have everything well documented, it’s always better to do a postmortem of your existing state of Project and document at least those critical things which may impact the Upgrade. Especially the list of additional tools/modules integrated with OOTB Sitecore platform, code and configuration level customization to achieve some functionality beyond the OOTB capabilities for Sitecore etc.

Such documentation or a checklist will help you plan the upgrade and its dependencies precisely. You will be prepared proactively with list of items you need to migrate/upgrade/revamp/rewrite in addition to the official Sitecore Upgrade Process.

List additional/third party tools/modules integrated

Although Sitecore as an independent platform is sufficient enough to fulfill most of the Content Management and Digital Marketing requirements. But there are a lot of tools/modules which we integrate with Sitecore for either ease of development, faster time to market,  debugging, optimization or data interchange with different systems .

Hence proactively we should document all the current integrations we have mapping with the latest version available. Don’t forget to check that the latest version is compatible with the Sitecore Version you are upgrading to. Most importantly if any additional licensing cost involved for any tool/module comparing the Source and targeted environment e.g if you are moving from on-premise to cloud, check if the tool/module is compatible without any additional cost involved.

Customization – Code and Configuration

One of my favorites.

Sitecore is very well known to be extended, scaled and customized to achieve variety of business needs which are not built OOTB. Every Sitecore project I worked so far had a good amount of customization like extended/newly implemented pipelines, events, handlers, scheduled tasks etc.

We may encounter various amount of Code or Config level customization done on top of vanilla Sitecore implementation either to implement some new feature or to optimize the performance. Additionally if there were any bugs in the current version in past, you may have installed some patches provided either by Sitecore Support team or your own googled research.

Hence the idea is to consolidate all the customization at a place to plan if any additional efforts would be needed to make sure that we don’t have anything broken on the upgraded instance. There could be three possible scenarios:

  1. Customized code/configuration is fully compatible on the targeted version hence just a simple migrate would work.
  2. If any of the namespaces/coding syntax is deprecated, you need to find the compatible one and update your code/configs accordingly.
  3. The feature or setting is no more supported by the targeted version, this may result a complete rewrite on the customization on the targeted version. You may have to archive the current code and rewrite everything from scratch according to the new architecture in place.

Features/business logic you don’t want to migrate

Perfect time for a cleanup. There are possibilities that some feature you implemented/customized earlier are either:

  1. Code/configuration/patch no more needed by business OR
  2. New version have something similar OOTB bundled with the platform OR
  3. Tool/module you installed on your current project which you are not using or have no plans to use it any further

In such cases if you would not like to carry over the old implementation to the new platform, make a note of such code/configuration snippets to not forget to archive them during the upgrade process.

Maintain a Upgrade Runbook

Based on the size of your current implementation and number of environments you need to upgrade, it may be a project running for couple of months. During this period you will be analyzing and researching about a lot of topics. Hence it’s a great idea and I followed it with most of my upgrade projects to maintain a living document (Upgrade Runbook) which we will be keep on updating at every stage of upgrade. All the important/unavoidable/critical information for the upgrade should be added to this Runbook like:

  1. Documented outcome of above three aspect of the upgrade
  2. Errors/exception you are facing during the process along with the solutions
  3. Choices you had and decisions you made, along with explaining the reason.

Hope this post helped you understand how critical it is to understand what we are going to upgrade and how complex it can be.

Please feel free to post your feedback/queries in the comment section below.

One thought on “Assess and Document: The Present

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: