Sitecore Go-Live planning checklist

This post is a summation of activities that you would want to consider before going live with your Sitecore websites. It is not a one-stop comprehensive list of Go-Live activities as implementation and deployment strategies may be different across implementations, with not all items on the list being applicable. However, hopefully this would as a conversation starter within your teams to identify things that you may have missed to consider.

Go Live Planning

In my experience, a Go-Live is best managed by creating a Release Plan. It’s main objective is to clearly outline all activities that need to be performed for an upcoming deployment. It enlists deployment related activities in the expected sequential order, with action owners, responsibilities and timelines assigned, ensuring there is no ambiguity w.r.t deployment.

While a Release Plan should be comprehensive covering all aspects critical for deployment, having specific tasks that can be checked off one by one prior to the go live date makes it easier for any team to ensure there are no ‘misses’.

Let’s have a look at the typical sections your checklist could include:

Technical Cutover Plan

Should contain a list of all the technical steps that need to be performed, in a sequential order, for the deployment. E.g. running a deployment, turning off specific plugins, etc. It should typically be an hourly plan clearly stating the timeline for each activity with start & end times along with the task owner.

A sample template is provided below:

Technical cutover plan sample template

Release Notes

It is critical to include Release Notes clearly describing what has changed between the version currently on the website v/s what is going to be deployed.

Version details should be explicitly mentioned for each service/component to be deployed.

A sample template is provided below:

Communications Plan

Often trivialised by us ‘techies’, it is critical to have a clear communications plan in place. Key stakeholders across the customer and vendor organizations need to be kept informed of the progress of the deployment, much more applicable for large releases.

A sample template is provided below:

Communication plan sample template

Business Cutover Plan

When the release is meant to deploy features which will impact existing business processes and ways of working, it is critical to have a Business Cutover Plan to highlight all activities required for managing the change within the organisation.

This could include activities such as feature demonstrations, training sessions, etc. requiring technical team inputs with planning & scheduling around the same. It should also include handover points for clear completion of each step.

Typically such plans are drafted as a ‘run-up’ to the deployment day and then extend beyond the release.

A sample template is provided below:

Security & networking

In addition to technical activities & communication planning, the Release Plan should also consider key security & networking related tasks that must be performed.

Reset Admin Password

Ensuring a strong password policy, before deploying your installation, is essential. Hence you must reset the Admin password.

As an extra layer of protection, changing the password and creating a new Admin password reduces the risk of having unauthorized users gaining access to Sitecore’s administrative tools and permissions.

Secure Content Management server

Ensure your Content Management (CM) environment is not exposed to the Internet by securing it with HTTPS. Failing to do so can significantly increase your data’s vulnerability.

Consider using IP Filtering to allow only white-listed clients to connect to the CM environment or consider using the Dynamic IP Address Restrictions feature available in IIS.

If you are deploying to a public cloud like Azure, you will want to configure a firewall, jump box, or VPN to restrict access.

Protect Admins Pages

Ensure the following pages are protected:

1. Cache (/Sitecore/admin/cache.aspx)
2. Database Browser (/stecore/admin/dbbrowser.aspx)
3. Serialization (/stecore/admin/serialization.aspx)
4. Show Config (/sitecore/admin/showconfig.aspx)
5. Size Status (/sitecore/admin/sizestatus.aspx)
6. Stats (/sitecore/admin/stats.aspx)
7. Unlock Admin (/sitecore/admin/unlock_admin.aspx)
8. Installation wizard (/sitecore/admin/UpdateInstallationWizard.aspx)

Keep OS updated

Keeping your OS updated with the latest security features helps reduce risks to your business and facilitates protecting your customers’ information.

Protect Sensitive Information in your Web Config

Sitecore stores sensitive information in the <connectionStrings> section of the web.config file. You can use the Microsoft ASP.NET IIS Registration Tool (aspnet_regiis.exe) to encrypt this section with the -pe or -pef options, in case an unauthorized user gains access to the web.config file.

Note: This rule applies to on-premise deployments only.

Ensure xConnect Security

Communication between clients that write/read to and from XDb via XConnect must happen over HTTPS, and clients need to have the appropriate certificate thumbprint

Implement user related security measures

Sitecore strongly recommends that we assign security access rights to roles rather than individual users to minimize the risk of accidentally giving someone access to features of Sitecore they should not have. Use the Role Manager in the Sitecore Experience Platform Launchpad diligently to create or manage user roles for your setup/project/environment.

Create a Disaster Recovery Plan

In case of a security breach, you will want to develop a Disaster Recovery Plan to help your organization get its website back up as quickly as possible. A good disaster recovery plan should include the following three elements:

1. A plan to obtain temporary or new equipment.

2. A plan for restoring content backups.

3. A way to test the overall plan and ensure the organization is familiar with what to do in the event of a catastrophic loss or failure.

Performance Measurement & Planning

Nobody likes a sluggish website. The ultimate goal of performance testing should be to ensure unexpected breakdowns or performance degradation of your Sitecore solution do not occur once your site goes live .

1. Prepare or obtain an NFR checklist highlighting boundaries for key parameters like response time, simultaneous users, and the page/second rate, performance thresholds during high volume days(e.g. Black Friday sale)
2. You will need to first identify the tools your team will use to collect metrics for your testing and monitor the details of how much the system is impacted by the test
3. Create a Performance Test plan with each use case scenario demonstrating the expected usage of your Sitecore solution for a particular situation.
4. Determine thresholds for maximum response time, expected page/second rate at a given load, and any identity metrics that will need to be monitored
5. Using a test matrix, you should be able to describe the percentage of user load that will flow into each scenario you are testing
6. Perform load testing on the production environment prior to go live. This will help you to identify if your resources are sized appropriately for your solution. For Sitecore 9 implementations, these guidelines from Sitecore can serve as a starting point for your sizing, but you must test to ensure these sizes are appropriate for your solution.

Pre-configuration before running your performance tests

1. Ensure your scripts (Javascript and CSS) are minified and bundled
2. Ensure your static assets from rendered from CDN (if used)
3. Tune the cache size (data/prefetch/item and HTML caches)- this is done before and after running the load test and reviewing how caches are performing. I highly recommend this blog on Sitecore performance tuning .
4. Disable WebDav — Go to [WebRoot]App_Config\Sitecore\CMS.Core\Sitecore.WebDAV.config and disable it like [WebRoot]App_Config\Sitecore\CMS.Core\Sitecore.WebDAV.config.disabled or delete it after taking the backup
5. Disable Performance Counters — <setting name=”Counters.Enabled” value=”false” />

Generic Considerations

1. Review if your application requires access to internal systems or 3rd party systems and ensure your application has required connectivity before Go-Live
2. Sitecore License — Ensure your production license deployed is not from a developer instance (we’ve all been there :) )
3. Custom Error — Ensure your 404 and 500 error pages are configured and working as expected
4. Configure and ensure your 301 redirects are working expected
5. Configure appropriate Favicons for your multi sites
6. Ensure your robots.txt file values are correct
7. Verify your Sitemap.xml update strategy
8. Check if your Sitecore scheduler jobs are configured correctly
9. Email settings configuration
10. Verify your Search provider configurations , your hosting configurations (Switch on rebuild , Master-Slave etc..)
11. Rebuild link databases and Indexes
12. Verify if your content publish to all targets are working expected

Routine Maintenance Plan

Prepare a routine Preventive Maintenance Plan that includes tasks that help to avoid errors, site outages and slow response times post Go-Live . I have listed a few high-level routine activities that should be part of your maintenance checklist. The list can be extended further based on your business needs:

1. Rebuild the links database regularly

2. Rebuild your search indexes periodically

3. Clean up databases

4. Use /sitecore/admin/stats.aspx for slow renderings and tune your Sitecore caches

5. Review Sitecore logs for application restarts & errors

6. Review the Sitecore Recycle Bin and empty as needed

7. Create maintenance plans for SQL server for fragmented indexes

8. This article should be a good starting point for creating a database Maintenance plan

Review & Sign-Off

Once the Release Plan is formulated and reviewed internally, ensure you circulate this to all stakeholder teams (e.g. Product Owner, Project Manager, DevOps, etc.). This will ensure all parties involved are clear of their duties on the crucial Go-Live date and any confusion/clarification is dealt with beforehand, issues/risks called out and contingency strategies put in place.