During a recent Content Hub upgrade I was surprised to find how little information there was available on the actual process involved. In this post I will share my findings and lessons learned during this process. This information is relevant to upgrade of versions prior to Content Hub 4.2. As from 4.2 onwards Sitecore introduced Automatic Upgrades meaning that upgrades are performed automatically and on a regular cadence.
Why Upgrade Content Hub?
New features & Enhancements – everyone loves shiny new features and Content Hub development are continually adding new features and improving existing features. Being on the latest version allows you to take advantage or those features and provide a better Authoring experience and User Experience for both your users and customers.
Bug Fixes – each release includes several bug fixes that have been identified in earlier version based on priority and impact when you upgrade you should notice these improvements or some pain points you may have had are no longer an issue.
Seamless upgrades and versionless SaaS model – as mentioned previously when you upgrade to the latest version you will be on the Sitecore Content Hub’s versionless Software-as-a-Service (SaaS) model. No more version specific upgrades, you can benefit from latest features and improvements without the need for complex and time-consuming upgrades. Updates will be deployed automatically and identified by dates to your Content Hub instances on a regular cadence. However, if an upcoming release contains breaking changes you will be notified at least one month in advance. That particular update will be deployed to your non-production first, then 14 days later it will be deployed to your production instance. Giving you time to test and mitigate any breaking changes before they hit Production. If you would like to read more on this topic checkout this post by Tim Marsh.
Sitecore Support – upgrading to the latest version ensures you have the necessary Sitecore Content Hub support and SLAs:
- Sitecore cannot guarantee service availability for versions 4.0 and 4.1 after June 30, 2024, and for versions 3.x after December 31, 2023.
- Assistance with errors or unexpected behavior during code or configuration promotion, or development activities. Versionless Only.
- Addressing product defects. Versionless Only.
Things to consider
Before scheduling your upgrade here are some things you should take into consideration:
Breaking Changes – depending on your current version you are upgrading from you will need to review the list of breaking changes in each of the release notes from your current version to the latest version and check if any of these are applicable or are a risk.
Sitecore has changed the structure of the automatic release notes as it no longer has a release number and they are organized by date following the release cadence with a new format. I did notice there are fare fewer breaking changes in these releases.
Customizations – review any integrations, custom pages, external components and custom css that you have within your solution and assess the risk. You should upgrade your lower environments first before production as that will allow to assess impact and resolve any issues before applying the upgrade to Production and mitigating any risk.
Downtime – there will be downtime incurred during the upgrade and the length of that depends on your current version and the size of your solution. Downtime could be anywhere between 4 and 8 hours but it should not be more. The Service Request team will perform some analysis when you make a request to upgrade and provide with an estimate of the actual downtime they anticipate to help you plan and schedule the actual upgrade. What to expect during downtime:
- Content Authors will not be able to access Content Hub.
- Content Hub Rest APIs will not be accessible. This is important if you have built custom web services or have other applications consuming these Rest APIs as you will need to consider how to best handle this service unavailability during the Production upgrade.
- Content sync’d to Sitecore using SCCH will be fine you just won’t be able to sync any new or updated content during the upgrade.
Rollback – if whatever reason the Sitecore service team handling the upgrade run into any unexpected issues and are unable to resolve within a timely manner they will perform a rollback using a backup they take prior to the upgrade. This actually happened during our the upgrade of our production environment even though both non-production environment upgrades went off without a hitch. The service team were able to diagnose the root cause and we rescheduled the upgrade with confidence they could complete the upgrade without having to rollback. An unexpected inconvenience but we got there in the end.
High-level Task Overview
During any upgrade I like to define a list of the steps involved and define the roles/responsibilities, estimated LOE, expected start and end dates and then document actual start and end dates. This information is super useful in helping to plan each of the environments to be upgraded. Capturing any lessons learned for each task between upgrades will help to improve the process and mitigate risk. This helps with planning and tries to ensures there are no unexpected surprises when you get to production. You should plan to upgrade the lower environments first i.e your Dev environment, following by QA and finally Production.
- Review Breaking Changes – list out all the breaking changes listed in the release notes between current version and latest version. Review the list and determine if any of these are significant or are a cause for concern determine any risk and how that could be mitigated.
- Create Service Request for the Environment – raise a service request with Sitecore. They have provided a guide on how to request an upgrade from earlier versions of Content Hub with some instructions about the process. Once the service request is created the Service team will be able to perform an analysis of the Content Hub instance and provide a LOE and expected downtime to perform the upgrade.
- Determine Impact of downtime – knowing the expected downtime you can plan for it and/or take any necessary steps to mitigate the impact of this downtime (if any). With this information you can plan with appropriate stake-holders when best to perform the actual upgrade of the instance. This is not such a concern for the lower environments, however it could coincide with other project release cycles. So its important all stakeholders are made aware.
- Plan for the actual Upgrade – You will need to plan with all the stake-holder including the Service Sitecore Service request team to ensure they have availability to perform the upgrade on your preferred date/time.
- Perform Upgrade – this is handled by the Sitecore Service Delivery team and will notify when is complete and relay any information on the Service request ticket. Once Service delivery have completed the upgrade you can verify by logging into the instance and going to Settings and locating the version in the lower right corner. Once you are on the automatic release this will co-relate to the version date following the new Release Notes format.
- Test Content Authoring – your QA team should perform some tests following the upgrade, ensuring they can create the various assets and workflows.
- Test Integrations – verify SCCH is working as expected and new/updated assets are being applied as expect to Sitecore. Ensure any custom web service or applications consuming the Rest APIs are working as expected.
- Review and test for possible breaking changes – using the list of changes discovered in step one, review each item and test.
- Issue resolution iteration – work through any issues identified in steps 6, 7, 8.
- Sign off Instance Upgrade – once all stake-holders are happy the instance has been upgraded successfully with all issues being resolved and/or mitigated the upgrade can be signed off. You can then start planning the next instance util all your Content Hub instances have been upgraded.
Once you are done upgrading all your instances you can scrunch this up and throw it away… with the automatic updates you’ll never need it again. One less thing for you think about or invest time and resources. Leaving you to focus on other business critical tasks.
Useful Info
- What’s New in Content Hub
- Content Hub Support Lifecycle
- SaaS product SLAs
- How to request an upgrade of a Content Hub environment from versions earlier than 4.2
- Upgrade a Content Hub environment on a version below 4.2 to a newer version
I hope this is helpful!