Skip to main content


Upgrading Sitecore Platforms – Testing and Going Live

Going live!

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.


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?

Regression TesingDepending 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?

There is no exact answer – but without automated regression testing becomes effort-consuming. That becomes especially true when you need to repeat it again and again. At the same time, it does not make sense to automate everything (and sometimes is not even possible).
Since you do the upgrade into a new instance of Sitecore in parallel to the existing one, you definitely need to conduct Load Testing prior to this new instance becoming live. The metrics must not mandatory me better than previously had as new Sitecore releases have much of new features and the number of assemblies within \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 admin password, or even better – entirely disable admin account in a production CM environment.
  • In addition to the above, restrict access to /sitecore/admin folder.

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

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!

Leave a Reply

Your email address will not be published. Required fields are marked *

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

Martin Miles

Martin is a Sitecore Expert and .NET technical solution architect involved in producing enterprise web and mobile applications, with 20 years of overall commercial development experience. Since 2010 working exclusively with Sitecore as a digital platform. With excellent knowledge of XP, XC, and SaaS / Cloud offerings from Sitecore, he participated in more than 20 successful implementations, producing user-friendly and maintainable systems for clients. Martin is a prolific member of the Sitecore community. He is the author and creator of the Sitecore Link project and one of the best tools for automating Sitecore development and maintenance - Sifon. He is also the founder of the Sitecore Discussion Club and, co-organizer of the Los Angeles Sitecore user group, creator of the Sitecore Telegram channel that has brought the best insight from the Sitecore world since late 2017.

More from this Author

Follow Us