Successful Sitecore Go Live Planning
Do you enjoy last second insane adrenaline life on the line type decisions? If so, then this article is not for you. Learn how to successfully plan a low-risk launch of your Sitecore site, whether a new implementation or a rebrand, by focusing on the roles and responsibilities for launch, communication planning, and a step-by-step approach to “soft launch” your new site to maximize the chances of a smooth and successful launch.
The aforementioned is achieved by following a Go Live Plan that contains detailed steps for a successful site launch. This goes beyond the technical aspects of the launch itself and into the “Go Live Team”, business readiness, communications, and embracing a “soft launch” methodology where feasible to reduce risk. This plan relies on successful governance and communication alongside stepped plans in the Pre-Launch, Launch Day, and Post Launch activities phases.
Contents
Go Live Team and Contact Information
Keeping an up-to-date list of the roles and contact information for the Go Live Team is critical for Go Live Success. To that end, ensuring that all roles required for go live have a contact person, there may be instances where a single individual could hold multiple roles (ex. Networking and Security).
| Role | Name | Phone | |
| Executive Sponsor | |||
| Business Owner | |||
| Project Manager | |||
| Sitecore Administrator | |||
| Network and Infrastructure Lead | |||
| Security Lead | |||
| Sitecore Development Lead | |||
| Sitecore Content Manager | |||
| Sitecore Marketing Manager | |||
| Internal Communications Lead |
Soft Launch Methodology
A “Soft Launch” methodology is when you deploy code, content, and configurations to the Production environment but do not switch DNS traffic to the new Production environment until the site has been reviewed, tested, and given the clear to receive traffic.
The benefits of this approach are as follows:
- Reduce launch risk with less “moving parts” vs. many manual steps requiring immediate validation
- Reduce the complication of rolling back in the case of failure
- Validate that the site and all its integrations are in place before pointing traffic
- Load test the site for any performance issues on the Production infrastructure
- Perform final testing to ensure all code, content, and configuration is in place
- Reduce a negative experience from components or functionality missing from the site (ex. Missing content or a third-party integration that requires the Production IP address to function)
- Validate the site function on the underlying infrastructure
- Validate the site function in the network and edge device flow
- Ease the switchover to the site/launch day activities by focusing on edge device changes such as DNS and WAF components on launch day, while allowing an easier rollback via a DNS switch back
- Lessen the time launch day requires as it is focused on fewer steps with an easier rollback as the site will have already been validated
To conduct a soft launch its imperative to:
- Have a separate “new” Production environment the solution is being deployed to so you can test in isolation from the current Production environment
- Conduct a content freeze during the Soft Launch testing and release the freeze post launch
- Have the networking/infrastructure resources available for any networking/infrastructure testing or configurations (ex. Opening up communication to a third-party integration)
- Have a testing plan and testing resources available
- Conduct a thorough load test
- A nice to have, is the ability to test the network flow from outside the edge devices to return the site. This is typically achieved via a dummy domain name placed as a binding on the application servers and edge devices (ex. Test.MySite.com)
Communications Plan
A clear communications plan is critical for a successful launch. Key stakeholders across the customer and supporting organizations need to be kept informed of the progress of the deployment, and any actions they may need to take. The following communication plan breaks out “example” milestones that trigger a communication, the party being communicated to, the date/time of the communication, communication owner, the message topic, and communication channels.
Of note the “Message Topic” is not the full message, as the full message should be crafted and formatted for the communication channel with any appropriate supporting resources and branding. However, the topic is what drives the communication, and the full message should be evaluated against the message topic to ensure the communication is properly targeted and conveyed.
Use the table below, to provide your communication plan by milestone using the simplified examples as reference. Of note, it’s not atypical to have several steps, but be careful to balance your communications alongside any message fatigue. The “Internal Communications Lead” from the Go Live Team will be critical in this regard.
| Milestone | Communication To: | Date and Time | Owner | Message Topic | Communication Channel(s) |
| Step 1: Content Freeze | Content Editors | 3/4/22 10am EST | Content Manager | The content freeze is now in place | Email, Slack |
| Step 2: Ready to Cutover | All on Go Live Team | 4/1/22, 5pm EST | Project Owner | We are ready to cutover | Email, Zoom Call |
| Step 3: Cutover Complete | Company Wide | 4/1/22 10pm EST | Project Owner | Cutover complete, please check out the new site! |
Business Readiness Plan
Beyond technical users, the business supporting or impacted by the site launch need to be prepared for this change, as this may change existing business processes. Following good change management principles alongside strong communication… demonstrations, training sessions, guides, companywide documentation, etc. should be the target of the “Business Readiness Plan”. In essence, you should aim to capture all activities required for managing the change within the organization.
Using the example tasks in the table below, detail the tasks requires for business readiness, acknowledging that the full details will likely live in a separate document. The intent of this table is to list the overall tasks, descriptions, owners, and track the task through to completion.
| Task Name | Description | Audience | Complete | Owner | Notes |
| CMS Training | Training for content editors | Content Editors | Yes | Owner name | |
| Change in Process 1 Training | Change in process 1 training | Management | No | Owner Name | |
| Change in Process 2 Document | Change in process 2 document | Company Wide | No | Owner Name | |
| Company Wide Demo | Company Wide demo | Company Wide | Yes | Owner Name | Rick Stevens to Present |
Pre-Launch Activities
Deployment Plan
Using a soft launch methodology, the following steps are required for the initial deployment. Once deployment is completed, site and load testing can commence, with a final Go/No-Go decision before launch day where traffic is pointed to the new Production environment.
| Step | Task | Complete | Owner | Date/Time | Notes |
| 1 | Build Code | Yes | Name | 3/11/22 5pm EST | |
| 2 | Deploy Code | ||||
| 3 | Smoke Test Site | ||||
| 4 | Setup Dummy Domain | ||||
| 5 | Test Dummy Domain Externally | ||||
| 6 | Setup APM and Ping Tools | Ping will test dummy domain initially |
Site Testing Plan
Once the site has been deployed into the new Production environment, site testing should be performed to validate functionality and any missing components. This should be a mix of automation and manual testing. Historically, Smoke Testing is the most appropriate testing approach as it goes wide vs. deep on the functionality and will surface issues that are Production environment specific. It is expected that deeper testing, such as unit, interface, regression, and user acceptance testing has taken place in the lower environments prior to deploying to Production.
Use the table below to fill in the pages and automated testing mechanisms.
| Test Target | Description | Tester Name | Pass/Fail | Notes |
| Broken Link Testing | Use the broken link tool to test for broken links | Bob | Yes | |
| Page 1 Test | Review page 1 for any missing items | Rob | No | |
| Page 2 Test | Review page 1 for any missing items | Bobby | No, | Easy Fix |
| Login Page Test | Test login page | Bo | Yes | |
| Function 1 Test | Test third party integration | Robert |
Load Testing Plan
The goal of load testing is to test deployed code on the infrastructure to ensure the site is responding as expected or if there are any infrastructure adjustments required (ex. Scaling or networking items). The load test may also uncover configuration items such as cache tuning, session state tuning, or third-party integration latency issues. In the case that a code issue related to performance is identified, the code should be remediated in development and brought through each stage gate of (ex. QA, UAT, Staging, Production) along with appropriate testing, such as regression and unit, prior to re-running the load test in Production.
Using a load testing tool of choice, it is preferred to leverage load testing tools that can emulate real users from varying locations. If this is not feasible and a synthetic tool such as JMeter is utilized, make sure to increase estimated load by 30% to account for the difference between emulated load testing which is more accurate than synthetic for measuring load (ex. If the desired load for a homepage is 5000 concurrent users, test at 6,500 users).
Using the table below, denote the pages that will be load tested along with the desired and actual response time, number of concurrent users, pass/fail, and appropriate notes. It is not uncommon to test all pages at once with an overall number of concurrent users, but this depends on your load testing tool and approach, bearing in mind that some tools can emulate user journeys at load. The key is to test consistently against a baseline while making any necessary adjustments prior to any additional load tests until the site pages respond within the desired response time.
| Page Name | Desired Response Time | Actual Response Time | Number of Concurrent Users | Pass/Fail | Notes |
| Homepage | 2.5 seconds | 2 seconds | 5000 | Pass | |
| Registration | 4 seconds | 5 seconds | 4000 | Fail | On form submit longest element |
| Product Page | |||||
| Contact Us | |||||
| Blog |
Go Live Review & Sign-Off (Go/No-Go)
Once load testing and all other aspects, such as the business readiness plan, have been completed, a Go Live Review and Sign Off (Go/No-Go) should be conducted with the Go Live Team. The outcome should be recorded as follows, noting that launch dates are finite and no changes can be made to the environment to ensure that no last minute changes creep in as this will invalidate all the testing and introduce risk.
Date/Time:
In Attendance:
Identified Issues/Concerns:
Take away action items:
Outcome:
Launch Day Activities
Technical Cutover Plan
Using a “Soft Launch Methodology” the actual launch day is cutover is greatly reduced in steps and risk with an emphasis on DNS cutover to point to the deployed, tested, and approved Production environment. List the steps in the table below including any security or networking components, testing/validation, and final communications.
| Step | Task | Complete | Owner | Date/Time | Notes |
| 1 | DNS Cutover | No | Name | 3/11/22 5pm EST | |
| 2 | Sanity Testing | ||||
| 3 | Propagation/Clear Caches | ||||
| 4 | Test APM tools and Ping Checks | Ensure Ping is set to actual domain | |||
| 5 | Communicate Successful Launch |
Rollback Plan
Even with detailed planning, a network issue or something else could cause an unsuccessful launch. To that end, its critical to establish a Rollback Plan. Rollback timing is greatly reduced in steps, complexity, and risk using a “Soft Launch Methodology” as it will be heavily focused on DNS cutback and any supporting edge device networking to repoint to the older Production environment. If a rollback occurs, determine the source and remediate before conducting a fresh Go Live Review and Sign Off Meeting (Go/No-Go)
| Step | Task | Complete | Owner | Date/Time | Notes |
| 1 | DNS Cutback | No | Name | 3/11/22 5pm EST | |
| 2 | Communicate Failed Launch | ||||
| 3 | Root Cause Analysis (RCA) | ||||
| 4 | Remediation | ||||
| 5 | Go/No-Go |
Post Launch Day Activities
Post launch, there could be additional communications, outreach (ex. Press Release), training, or short-term site maintenance/monitoring that needs to occur. It’s recommended to use an Application Performance Monitoring (APM) tool with Synthetic Ping Checks (ex. Pingdom) from a monitoring perspective with heightened awareness in the first two weeks of the new launch to ensure any issues that could occur are quickly caught and remediated. It’s not uncommon to keep the previous environment operational to switch back to until operational stability is observed.
| Step | Task | Complete | Owner | Notes |
| 1 | Press Release | No | Name | |
| 2 | APM Monitoring/Ping Check Monitoring | |||
| 3 | New User Training | For new users of the system |
On Call Rotation/Escalation
If not already present as part of Site governance, establish a clear on call rotation and escalation path for continual management of the new environment. Typically, issues that occur off hours are related to networking, patching, infrastructure, bot traffic, or other integrations as code is not deployed off hours/change is not introduced to the environment via code.