Upgrading Sitecore 6.6 to Sitecore 8 (Part 1 of 2)

After a few months of being preoccupied with a prior project and a presales assignment, I am finally able to spend some time here to share my experience on my role as a Technical Lead for a Sitecore rebuild and migration work for our client for a six month period till early of December 2015. Our client is a prestigious news press and digital media company, who have used Sitecore as their platform and repository of thousands of news articles and stories. I hope that this article will be an enjoyable read as much as it was to write and recap my experience in this article.

The one most important thing to consider when working on a Sitecore upgrade is planning.  I cannot emphasize it more. This means listing down every possible scenario in every category and area for the rebuild and migration. The next thing is communication. I was given the privilege to ask honest questions from my customer during the Planning phase around requirements.

Our Customer’s primary concern with the system was poor performance. This included topics such as how we can better streamline Editor’s (who are the Content Authors) daily activity tasks, increase Editor experience and navigation with the back office. For instance, our users did not enjoy clicking through too many levels deep to get to an article content item. Thousands of articles accumulated over the years further degraded the user experience due to slow loading of content items. In addition, uploading of media items takes a long time to process and complete. More are mentioned down below under Customer Requirements.

To take things further, I was engaged to come up with a presentation to engage the customer’s Head of Technology as to why they needed to upgrade to Sitecore 8. This means putting their top priority concerns in a deck and providing them a proposed scope of delivery items that is addressable with Sitecore 8’s features. I hope that the below can be used  to help any Sitecore developers or consultants involved whereby in presales or in actual delivery of a Sitecore Upgrade.

Customer Requirements

Every customer has unique requirements and circumstances. And it is extremely important to understand how these can impact them from the short to the long term. After having attended several preliminary face to face meetings with my customer, I decided to understand more of their concerns and pain points with their use of the existing system. Below are the key pain points

  1. Poor CM performance whereby content authors were experiencing Kill Pages when navigating multiple levels down to navigate to their stories.
  2. Poor Publishing performance which often led to the Publishing activity being queued often. This is a news press company that often publish hundreds of story content every 10 to 15 minutes. This contributes to issue no 3)
  3. Slow upload of media images to Sitecore resulting in failed uploads and further exacerbating the CM performance.
  4. High data requirement with thousands of articles and millions of media items being stored over the past 10 to 12 years. This contributes to the issue 3)
  5. Poor media, stories and articles taxonomy which results in Content Author frustration to click through to many levels to reach their desired content item or media item.
  6. Inconsistency between indexes reflected in their Content Delivery servers in the Production environment. The customer were using Lucene to index large volumes of contents across their Content Delivery servers. This resulted in inconsistent viewing of news and article information on the front end site between servers.
  7. Inability to implement Content Personalisation as a lack of foundational setup with the current HTML structure and its data sources.

The Upgrade Questions

The next question is to ask ourselves why do you need to upgrade?

To follow up from the issues highlighted above,  I then decided to put a list of points in bullet form on the areas I considered that were important to highlight to the customer in pushing them for an upgrade.

  1. Does a minor/major upgrade address their performance issues immediately and in the long term?
  2. Do we need changes to the infrastructure?
  3. Are there limitations to the current customer’s environment (can this be onsite network limitations, physical hardware, etc.). If so, how this can affect the platform?
  4. Consider the Sitecore’s Product Lifecycle as to when main stream support will be made available for the customer. (https://kb.sitecore.net/articles/641167)
  5. Where possible, provide  them with Sitecore’s Compatibility Matrix to understand offerings between Sitecore 8 and Sitecore 7.2 so  that the Customer may understand what they can gain from Sitecore 8 and map these features to the issues highlighted in their requirements as addressable.
  6. What are the customer’s data and security policies around cloud hosting options?

In terms of the Digital Marketing System, my customer had not enabled this feature due to performance reasons already experienced with the CM. Nevertheless, our Customer were keen to realize their Digital Transformation Road Map in the second phase and treat the first phase as an opportunity to rebuild and prepare the platform for Digital readiness. Hence,  it was safe to speak about Sitecore 8.0’s new Experience Analytics Database (xDB) and its offerings to our customer on a high level. This was a gold point to point our Customer to adopt the upgrade and use the first phase as a Baseline Phase to ensure critical requirements related to performance issues were met.

Planning points

Next, I have gathered a must have list for any developer prior to planning their Sitecore Upgrade with their customer. The questions below are must-ask questions  from a CMS and DMS point of view.

Firstly CMS:

  1. How much data is stored in the CMS such as content items and media definition items.
  2. Are they are any customized items as the following described:
    • Custom events, modules, pipelines, processors and commands.
    • Custom agent tasks or schedulers.
    • Custom workflow definitions, items or commands.
  3. What are the various events, pipelines, processors and commands.
  4. Are there any current Sitecore’s owned modules. If so, check if it is first compatible with Sitecore 8.
  5.  Are there any shared source modules available in the Sitecore Market Place. If so, check if it is first compatible with Sitecore 8.
  6. Custom configuration files found in App_Config/Include.
  7. Are there any current third party integration or touch points.
  8. Are there any current Sitecore Support dlls that were issued by Sitecore or obtained from their Knowledge Base site. If so, check if it first is compatible with Sitecore 8.


  1. Has the customer adopted DMS on their existing platform? If yes, how can we plan to migrate their analytics data from Sitecore 6.6 to 8. Note that with Sitecore 7.5 to 8 and above, Sitecore has introduced the Experience Marketing Analytics and Platform to host user visitor data, tracking, profile, personal, campaigns etc. in MongoDB, a NoSQL document database that is able to support schemaless data. For more information on MongoDB, you can find out here (https://docs.mongodb.org/getting-started/shell/introduction/)
  2. Are the current components for current Sitecore system configured to support Page Editor mode. Note: Page Editor experience is a prerequisite for Digital Marketers to configure content personalisation at a later date.
  3. Regardless if the customer has or hasn’t adopted Sitecore’s Engagement Platform (in this case it will be DMS for my customer), you must spell out the option to the Customer if they will like to host its Analytics infrastructure on-premise or on the Cloud. As mentioned, some companies adopt strict data security policies around Cloud hosting options, and as such may prefer to host the xDB infrastructure on premise. Where as, others prefer to cut short an learning curve on MongoDB and delegate the actual work (be it processing and aggregating analytics data, auto scaling, etc.) to Cloud xDB.  List the options down to the customer. It is important to pose these options upfront to the Customer so that they can make a considered decision and manage risks if any.

The next thing you need to know is which version of Sitecore 8 suits your project. Many people will be quick to think that the latest version of Sitecore 8 is the safest choice. Well thanks to some advice from a good Solution Architect friend at Sitecore, this is not always the case. Always check the feature release version of the product. Not every latest feature releases are stable as yet. Service packs are definitely recommended as Sitecore tends to introduce fixes to major performances and security vulnerabilities.  I will prefer staying with one version below the latest version update. And if there is a service pack which I can grab from Sitecore’s 8 Release downloads, use the service packs before the feature releases.

In the next part of this series, I will aim to demonstrate some of our approaches in addressing these performance pain points. These will be described in a summary and accompanied with a technical architecture diagram for ease of understanding.

To refer to key learning points of the upgrade, you can read my experience article here.

Please stay tuned.

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 )

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.