With support for Sitecore 8.2 coming to an end 31st Dec 2019, several clients are planning their migration to Sitecore 9 if they have not done so already. This post describes the process and some of the tasks involved in upgrading from Sitecore 8x.
There are two main approaches when upgrading you might consider:
1. Upgrade existing instances – the upgrade is performed against the existing instances and rolled out to all environments.
- Additional infrastructure is not required for the upgrade
- Usually Requires a code freeze while the upgrade is rolled out to all environments.
- Unanticipated Issues can arise during the upgrade that can cause delays in the development lifecycle.
2. Clean Approach – setup a clean environment and clean Sitecore instances, migrate data.
- Upgraded and tested in isolation of the current production instance.
- Provides an opportunity to upgrade the OS & SQL.
- Easily rollback if issues occur.
- Code freeze to existing solution not required for the entire duration of the upgrade and bug fixes and new features can be rolled out and worked on in parallel to the upgrade.
- Additional Infrastructure is required for the new environments to run in parallel. We would need to spin up new servers to support the new environment as these would be running on different versions of the operating system and version of software to meeting the requirements of Sitecore 9.
- We will have the additional overhead of managing two sets of environments for a period of time while.
The clean approach effectively means you a Sitecore 8x environment – current site and a brand new Sitecore 9 environment – for the upgraded site.
Once you have switched over to 9 you can decommission the old environment. Continue reading
In my previous post in this series on load testing I provided an introduction to JMeter to help get you started in this post I’ll explore the following topics and provide solutions to some challenges you may come across while creating your load tests.
I discovered an issue with the Resolve Sitecore Pipeline step in DEF 1.4.1 on Sitecore 8.2 where my Pipeline Batch process would occasionally return and attempt to update the wrong item. In this post, I will explore how that is possible and provide a simple solution to prevent it from occurring.
I ran into an issue with Sitecore’s Data Exchange Framework v1.4.1 where my pipeline batches would intermittently create thousands of duplicate Sitecore items. This caused a bit of management overhead having to clean out the duplicates. Following some investigation, I decided to add some defensive coding by introducing a Custom Resolve Sitecore Item Processor to replace Sitecore’s OOTB pipeline step and prevent duplicates from being created.
I’ve worked on various Sitecore implementations where the customer has often run into issues with data not being returned as expected the first thing I do now to troubleshoot is to check the Solr Index.
Check Solr Is Up
- If you are not sure of the address of your Solr instance you can locate the url in the following configuration file app_config/includes/Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config and the setting, for example: <setting name=”ContentSearch.Solr.ServiceBaseAddress” value=”https://localhost:8983/solr“></setting>
- Use Solr Ping to check the status of the master solr index http://localhost:8983/solr/sitecore_master_index/admin/ping?wt=json
- You should receive the following output with the status of OK: