When you visit a website, your browser connects with dozens of computers around the globe which act in synchronicity to produce a cohesive result. It’s an intricate technical ballet that must happen in the blink of an eye. When launching a new website, it’s pivotal to plan properly, considering all the moving parts, so that this dance comes together gracefully.

‍

3… Prep

The first thing we do when a site is approved by our QA department is to construct a launch plan. This is a document outlining the steps that will be required to double-check every aspect and to get the site into the hands of the public with minimal downtime and low risk of error.

‍

For a small site, this might be as simple as a few easy steps which one developer can handle with almost no downtime. For a larger site, the process is usually much more complex, depending on the nature of the site and how it is built. Most complex sites use a database, which is a special kind of file that stores interrelated information. Usually, the database stores things that users or administrators have posted to the site. When launching a new site, if the database on the existing site is updated frequently, we have to “freeze” the existing site right before we launch the new one so that we can copy it over as it was at the moment before launch.

‍

Most of the time, we build sites on a separate physical server (a specialized computer which hosts your website) from the existing site. This means that they are disconnected and have different IP Addresses. An IP address is a unique numerical identifier for a computer on the internet. Your PC has one, but so do servers. (For more basic definitions, read our primer on how the internet works.)

‍

2… Preflighting

Before launch, we undergo a series of steps called “preflighting.” These are either redundant checks for critical factors that we already verified once during our QA process, or final steps that don’t make sense to do before a site is about to go live. The exact checklist varies from project to project, but common preflighting steps include:

• Ensuring that the new server can withstand the anticipated traffic load after launch.
• Final testing that “caching” methods are installed properly and will function correctly when the site goes live. Caching is when a site stores the results of time-consuming operations so that it can save time when another user asks for the same information.
• Making sure the site will behave properly when it is being viewed using the real site URL and not a placeholder or staging URL.
• Making sure that “301” (permanent) redirects are in place so that any traffic flowing to currently-working URLs in your website will still lead to relevant pages after launch.
• Making sure that any code blocking traffic to the new server during the development phase is lifted.
• Making sure that any database manipulations that need to run during launch are automated or well-documented so they are easy to run when needed.
• Checking that any image management tools will work properly in a real production environment.
• Making sure that domain name records have a low “TTL” (Time to Live) value. This means that when we change them on launch day, the changes will spread quickly and users will see the new site faster than if we left the default TTL values. This is not relevant if you use a “reverse proxy” service like Cloudflare.

‍

1… Choosing the Right Moment

Once preflighting is complete, we are clear to launch. Our launch plan usually includes a specific date and time. We try to shoot for the time of day when the client’s traffic is lowest. You can check this if you have Google Analytics or a similar tool installed on your site.

‍

Sometimes the client needs a looser window because they are awaiting final sign-off from their stakeholders, or because they need to finish some final pieces of content. In those cases we provide a flexible launch window in which we are ready to kick off the process with 24 hours notice.

‍

We try not to launch on Friday. This is because in the days following a launch, we check the site regularly to validate that everything is going according to plan, and most of our staff does not work over the weekend. If we launch earlier in the week, we can ensure that lots of eyes are on the project in the few days after it goes live.

‍

Launch!

The specific steps vary greatly depending on the status of the existing site, if any, and the structure of the new one. For a large eCommerce store redesign, for example, the process might be:

• T-minus 24 hours: Deploy a banner to the site that announces that there will be downtime during the launch window, and that if a user is shopping during the launch window to please come back at the end of it.
• T-minus 15 minutes: Our development and QA teams convene in a “Control Center” video call. The client is invited and allowed to watch our process but is not required. Our staff, and the client, if present, review the launch plan together.
• T-minus 5 minutes: Any final concerns have been aired and we are 100% committed to launch.
• Launch time: Put the existing site into maintenance mode, preventing visitors from hitting the site or placing orders.
• T-plus 5 minutes: Migrate the old site database onto the new ”production” (final) server.
• T-plus 10 minutes: Perform any post-migration tasks that are required to make the old database work for the new site.
• T-plus 15 minutes: Change the domain name settings (DNS) for the public domain to point to the new production server.

‍

Traditionally, the moments after launch were hairy. When the domain name settings changed, that change would have to “propagate” throughout the internet, meaning that users in different parts of the world start seeing the new site at different times. Historically, this delay could be up to 24 hours. Nowadays, we install Cloudflare for almost all new sites, which mitigates this problem (and provides a lot of other wonderful benefits).

‍

Finally, we triple-check the site. While our QA process is incredibly thorough, we always do a final sweep just to make sure no new problems have snuck in. Since we have a bunch of people in our Control Center call, we all pitch in. Some things we specifically like to test are:

• Making sure that forms are submitting as they should, and are alerting the right people when messages are sent through them.
• Making sure that analytics scripts which are not meant to run in our development environment are running properly now that the site is live, and are and sending data to the right places.
• Making sure that the database looks correct, including changes that were made to support the new site and any potential data that users may have entered in the moments before launch.

‍

We like to construct our plans as a group to minimize our chances of missing anything important. With dozens of years of web experience in our team, we have a great track record of determining what might go wrong before it does, and then mitigating the risk. Launching a site can be harrowing, but with a clear plan, it is a lot more manageable. We hope this process is helpful for your next launch. Good luck!