So, you find yourself in a need of a Sitecore upgrade and don’t know what to start with or how to approach it? This series of blog posts will cover the whole process from zero to hero, or in upgrade terms – from planning to going live. It comes in the form of a guide that will save you at least 2 times of cumulative effort, due to avoiding hidden traps and unobvious issues on your way to a shiny upgraded solution. Over time I have struggled and documented most of these issues and now want to share them all in one place.
Content
- Part 1: Scope Planning
- Part 2: Upgrade Tactics
- Part 3: Content Migration
- Part 4: Upgrading the Codebase
- Part 5: Changes in Sitecore 10.x
- Part 6: Testing and going live
This is the final post of my series on upgrading the Sitecore platform. At this stage, we expect your solution upgrade mostly done, however, there are still several activities to be completed.
Testing and Going Live
I assume by this time you have already established new CI/CD Pipelines so that you are in control of automated releases. If not, please set it up prior to going further ahead. From the outside, release and deployment should work as a set of atomic repeatable operations resulting in the current state of your solution. You simply cannot conduct testing until you stabilize the release process because with (semi)manual releases there are lots of opportunities for phantom mistakes.
When it comes to the testing, you will definitely need to conduct at least one (or if things go wrong – a series of) of the following types of testing:
- Load testing – since we upgraded to a new system, we need to ensure it complies with expected load scenarios.
- Penetration testing – to verify the upgraded solution for known vulnerabilities and to address issues before going live.
- End-to-end testing – to confirm system works under real-life conditions and scenarios
- Regression testing – to ensure the updated system functions the same as the legacy system did.
Since we’re talking in the context of performing an upgrade, I would like to focus on Regression Testing. The first question comes to clarify, what exactly to test?
Depending on the upgrade scope, you will need to at least ensure the following:
- Overall site(s) health look & feel
- 3-rd party integrations aren’t broken
- Editing experience is not broken
- Most recent tasks/fixes function well
Another question, how would you test: manual, automated, or a mix of both?
\bin folder always grows up. But as soon as it meets the projected SLA – that should be fine.
Monitoring is also crucial when going live. Once the new Sitecore instance is up and running, the first thing to check would be Sitecore logs to inspect and fix any errors that are being logged. We have a comprehensive set of automated UI tests that cover the majority of business use cases and are executed overnight. The bare minimum you should do on a regular basis would be:
- Inspect all the logs for any exceptions
- Watch the metrics for anomalies
It may sound obvious, but ensure the monitoring actually functions well at the destination environments prior to factual switching traffic to the new instance. The last thing you want to experience is a crushing new environment without having any way to identify why exactly.
Another exercise to undertake before going live would be Security Hardening – the process of securing a system by reducing its surface of vulnerability, which is high for systems that perform more functions like Sitecore. From older versions, Sitecore comes up with the Security hardening guide and considerations to be followed. It includes:
- Securing Content Management – ideally, CM environment should not get exposed to the Internet. You may either employ IP filtering for white-listing clients or set up VPN access to the CM-hosted network.
- Reset Sitecore
adminpassword, or even better – entirely disableadminaccount in a production CM environment. - In addition to the above, restrict access to
/sitecore/adminfolder.
SEO Considerations are sometimes mistakenly excluded from the scope of the upgrade process. However, it is a crucial part of going live. At the very least you should check that you have implemented the following:
- robots.txt and sitemap.xml files
- sitemap.xml does not contain broken links
- 404 and 500 errors are correctly handled
- where redirects take place, they should operate correct status codes, ie. 301, 302
- GTM is in place and is correctly configured
Make sure SEO-related features are implemented correctly
In case you have the luxury of organizing Content Freeze for the Go Live period – that is great! If not you will need to pick up and care for the content delta produced meanwhile going live. The best thing to advise would be to use PowerShell Extensions to identify and pack all the content produced at a specific timestamp onwards. After installing this package the delta would be applied to the updated instance.
Other things to verify may include:
- Does your solution use email, for example for recovering forgotten passwords? Unless you employ external services, verify that SMTP settings are set correctly and emails are actually going through.
- Have you got the correct SSL certificate for the production HTTPS environment, and if having subdomains they also work well with HTTPS (have you got a wildcard certificate?)
- How do you do backups and restore them? Do you have a Disaster Recovery plan in place and was it tested?
The actual moment of Going Live is when you switch DNS records from a previous instance to the new one. Once done, the traffic will go and be served by the updated instance. There are a few considerations, however:
- You will need to reduce TTL values for the domain DNS record well in advance to make the switch immediate; then bring it back once done.
- You will need to reduce TTL values for the domain DNS record well in advance to make the switch immediate; then bring it back once done.
If everything went well and the updated instance works fine, you still need to keep both instances running in parallel for a certain amount of time, known as the Cutover Period. If something goes totally wrong you could still revert to an old instance and address the issues. The one important thing to keep in mind is that you are likely to keep your upgrade team busy for this period for addressing some immediate requests/issues, but also to hand over the updated site to maintenance and editors teams.
At this stage, if there are no issues we can consider the upgrade project completed. That concludes my series of blog posts and I wish you all smooth and easy upgrades!
