One of our larger clients was using Sitecore 8.0 rev5 on-prem for their website, and their SLA was out of compliance. For this reason, as well as being many versions behind, the client opted to upgrade the site. What follows is a high-level account of the journey our development team took to get them from Sitecore 8.0 to Sitecore 9.3.
Getting the Lay of the Land
In taking on a project of this magnitude, our team wanted to get a clear picture of what the upgrade would look like. This was a very large site consisting of over 13,000 content pages and 5,000 products, spread across 500 locations. There were also many integration points with external data sources such as:
- Physicians (Client API)
- Classes and events (LVM Weblink)
- Locations (Client API)
- A large repository of patient mortality chart data (HighCharts)
- Newsfeeds (Meltwater API)
Not only were we tasked with making sure content remained unchanged, but we also did our best to clean up technical debt and improve performance where possible. We identified bugs that would be fixed by the new version and took advantage of a parallel project to convert from Lucene to Solr. We deprecated old indexes in favor of the built-in Sitecore indexes. We converted their Web Forms for Marketers content to the new built-in Sitecore Forms. This site also fed data to their native mobile app which needed to function the same after the upgrade. This was a massive project, for both the development and testing sides.
The client’s 8.0 website was still live and in production, and the upgrade was going to be a long-running project. We needed to maintain an environment to code bug-fixes and maintenance items while simultaneously working on the upgrade. Thus, we stood up an entirely new set of hardware to host the 9.3 infrastructure. This included a DEV integration server; a UAT content manager; two load-balanced UAT content delivery servers; a production content manager; and two load-balanced, production content delivery servers. We also needed to stand up a Solr server for both UAT and production. Once the infrastructure was in place, it was time to install Sitecore 9.3. The installation and configuration of Sitecore is no easy task. There are many moving parts, including but not limited to, the core website, XConnect, Identity Server, databases, certificates, and Solr integration. This is all managed by a rather large and unwieldy PowerShell installation script. Throughout the installation process, developers on our team encountered a varying array of issues, sometimes with completely different error messages based on which machine the install was being run. This led us to develop our own Sitecore installation wiki with common errors and their related solutions. After documenting these issues, our team was able to collectively solve the common errors we were seeing. Our blank Sitecore 9.3 website had been created, and it could be accessed in a browser.
With a new blank Sitecore 9.3 website set up, our next challenge was to migrate the content into the new site without disrupting our highly componentized architecture. The 8.0 site was utilizing a popular community-supported solution for dynamic placeholders, which allowed content authors to drop multiple components with nested placeholders onto their pages. However, this came with its own set of problems. Mainly, content authors had to use workarounds to get content to display in the correct order, and in some cases could not format their content in the order they needed to. Sitecore 9.3 offered built-in dynamic placeholders which solved these issues, but there was a breaking change in how these were implemented. This led to our team needing to create some sophisticated PowerShell scripts to convert presentation details on 13,000+ pieces of content from the old format to the new. Following this, a massive ongoing QA effort was required that utilized a third-party tool called Percy to continuously compare both sites, flag differences, and create work items for the team to investigate and fix.
Technical Debt and Other Updates
During this project, we took the time to clean up some technical debt that had been accrued since the implementation of the original 8.0 site. We put effort into shifting much of the in-memory query logic for site search and physicians into the Sitecore API so the heavy lifting could be handled by a dedicated Solr cloud instance. This resulted in a site-search that could take 10+ seconds to retrieve its data being reduced to less than one second. In turn, we also reorganized the indexing and other site config files. Sitecore 9+ utilizes a different structure on the file system for its config files, creating a perfect opportunity to clean up and centralize files for when future maintenance is required.
This project was an absolute success and a win for so many of the parties involved. The entire soft launch took about an hour to complete and went live with virtually no defects related to the upgrade. Unfortunately, we were not able to implement Helix principles due to the large amount of existing code and the timeline of the project. With the lessons we’ve learned from this upgrade as well as good documentation in our wiki, we have the blueprint for the next upgrade when we move to Sitecore 10+.