I recently blogged over on Nonlinear Thinking about the 9 steps to a successful Sitecore website launch.  While targeted at a Sitecore audience, these steps do apply to pretty much any website launch.

So, if you are about to plan the site launch for your most recent project, putting together a cutover project plan, or you are just wondering about some common obstacles you should watch out for, check it out!

Read more: https://medium.com/valtech-sitecore-experts/how-to-successfully-launch-a-sitecore-website-in-8-steps-a2c07efe77ef

UPDATED 2020-02-13: The Nonlinear blog site is no longer valid and the redirect did not work. I have found an alternate blog copy of this on Medium which i have included instead. Because of the likelihood this content may be removed, I have duplicated the content below:

Are you preparing to launch a Sitecore website? Make sure you check out our nine item checklist to ensure smooth sailing.

Anybody who has ever done a production launch of an application knows three things:

• There are a lot of variables at play
• Inevitably the law of averages catches up to you
• Something pretty much always goes wrong.

Whether you are launching something internally or externally, these three things will apply; a Sitecore launch is no exception. If you are about to start your cutover planning, here are nine things to keep in mind for your run up to launch day and your post-launch plan:

1. New “must-haves”

During cutover testing, new end-users or business groups may be brought in to review the site prior to launch. These individuals may not have had input into the project until now and may have business needs that have not been met. Suddenly, new “must-have” features or bugs are identified on launch day. Don’t worry, you’re reading this before launch day! (Right?) Sound familiar? If so, you have two options: either bring these folks into the project earlier or set their expectations for a “quick turnaround” post go-live to address their concerns.

2. Task estimates are wrong

Task estimates are just that, estimates. The preliminary projections for cutover tasks are usually incorrect, and as a result, dependent tasks can begin to slide throughout the day. This can become compounded, especially if multiple teams are trying to co-ordinate. When reserving your resources for launch day, ensure some flex time for the end of the day so that these resources are still available to continue launch activities beyond the estimated time frame.

3. Domain name transitioning issues

This is easier to fix when launching an intranet, as standard worldwide DNS-propagation time won’t apply. It’s possible that there may be issues ensuring that users are being sent to the new site as opposed to the old domain, and also issues with sites that are supposed to be linked to the production environment. These issues can both be mitigated by resolving the DNS in advance to a load-balancer inside the network that can be pointed at the old site, and then swapped over to the new site. This allows for advance propagation of the change in DNS/IP mappings without serving up the new site until launch day.

4. Content issues

Once the full version of the website has been launched, there are usually multiple users who begin reviewing the site and its contents. Typos, grammar errors, layout problems, synchronization with publishing issues, etc. are often discovered as visitors explore the end-user site for the first time. While this can be avoided by establishing a proper Sitecore governance structure, it’s possible that prior to cutover, many users will be focused on content migration and viewing content in the authoring environment and less concerned with the end-user. This is to be expected but thanks to Sitecore’s easy CMS interface the changes can be made directly in production and published without needing to do another deployment. A note of caution: make sure you have a tracking system to track all the issues that are identified during this process!

5. Go/no-go time frame needs to be flexible

Project teams will usually have the initial go/no-go meeting and look at remaining issues to determine if the team should be given more time to resolve them followed by another go/no-go meeting to reassess. These meetings often reveal obstacles to a successful launch that might include incorrect estimates, newly discovered bugs or other barrier issues. Be prepared to change the time of the go/no-go decision to reflect the extra effort that will be required to address the new issues.

6. Sitecore performance

Performance testing should cover finding most of these issues but when the actual load of users begin using certain features new issues may be identified. Your team needs to be ready to disable these features for further investigation or real-time capability to address the performance issues. Integration points are the most common cause of this, so make sure these are included in your performance tests prior to launch.

7. Browser compatibility

While QA has been doing browser verification, it is inevitable that slight differences in end-user browser/OS/hardware may find previously unknown compatibility problems. If your organization is launching an intranet, you may have control over the hardware and software installed on company-issued workstations, however users with various mobile devices or working from home may encounter unforeseen problems. When launching to the internet, make sure the focus on browser testing is based on your historical analytics data to know where to focus your testing/development efforts, smaller groups can then be scheduled in based on business priority and desired markets.

8. Handling influx of support

Due to the new user experience, and possible remaining issues in the system, there are usually a lot of questions that will come in via email, phone, forums, or your Twitter account. Resources need to be prepped for this increased load and there will be many prioritization decisions that need to be made to ensure tickets are handled efficiently. During the first few days only critical issues should be addressed and everything else should be prioritized into the backlog.

9. Schedule for post-launch deployments

After the initial cutover, there needs to be an agreed upon deployment plan for pushing out priority fixes for issues found during cutover or on the first few business days after cutover. Expect that the first day will likely be handling the influx of questions and prioritizing the issues, so starting on the second day you will likely need a scheduled deployment of priority fixes.If you follow these steps, you’re sure to feel a whole lot better on launch day. Are there any Sitecore pre or post launch tips you’d add as being integral for a successful website deployment?