Considerations for Going Live with a Website (and when you should)
Written By: Shane Clark on August 15, 2023
The issue has come up more times than I can count about when the best time to go live is. Regarding the textbook answer, the correct answer will always be when the website is at the lowest traffic point. I like to examine why that may only sometimes be the correct answer based on the situation.
Going Live May Not Require Technical Skills
I believe in using a managed hosting company such as WPEngine to prevent the hosting experience from becoming a science project. If using a managed hosting solution such as WPEngine, it is likely that with the help of support, a non-technical person can migrate the website. I find that clicking to copy the website and instantly restoring from a backup can be handy.
Have Everything Up Front
Having everything inside a project management system is vital to efficiently launching a website. Have logins ready; it will make going live much less cluttered, and more efficient. I want to know the following:
- Is the DNS being moved?
- Are all logins in place?
- Where is any authentication happening?
- Is any content delivery network being used? (such as CloudFlare)
- What is the development URL of the website?
- What is the live URL of the website?
The type of migration you will need to perform will determine the job’s complexity. You may just have to overwrite the live site using a duplication plugin that takes only minutes.
Web Developer Does Not Mean Server Engineer
I have seen on more than one occasion, “but you are the web developer,” concerning some issues going live. It would be like me saying, “but you are the SEO expert,” followed by a task to write some very customized JavaScript driven GA4 (Google Analytics 4) event(s) for an enterprise-level website. I am experienced in what I do. And what I do is live within the limitations of what I know.
I have the most success when I have the following:
1) Instructions and all the information ahead of time.
2) Working within the managed hosting environment.
Proper Communication with the End Client
Establishing a line of communication between the client and anyone tasked with making the website live is essential. I recently ran across a case where a web developer (as opposed to a server engineer) tested a site. Someone told him the domain was on a particular network. However, when the domain went live, he discovered that a different network, CloudFlare, was the host.
The developer should have asked the end client if he was using any content delivery network (such as CloudFlare). This is where either direct communication with the person going live or some kind of engineered intake form is critical.
Understanding the Website’s Traffic & Size
Understanding the traffic and size of a website you plan to go live with is essential. A 20 MB(Megabyte) website with a few visitors a month will have different considerations compared to a higher bandwidth and larger site. I make sure to get this information before the start of any migration.
Exhaustion Fuels Mistakes
As I previously stated, the best time to go live will be at the lowest point of traffic on the site. We might find the lowest traffic point at 3:00 AM based on Google Analytics data. Would this mean the developer stays up late? Takes a nap? In an ideal world, going live takes 15-30 min, but many variables outside the developer’s control could turn a 3:00 AM – 3:30 AM effort into one that drags on into the next business day, causing the developer to miss a night of sleep.
Budget Considerations
Another consideration is the budget of the project. If I were accounting for a case where the site going live takes longer, I would not expect my clients to be very receptive to paying me for missing an eight-hour workday to be ready for an “all hands on deck” effort that could last all night.
DNS Changes Can Take Time
Pointing DNS requires time to allow the DNS to propagate. How long does that take? If you ask me to tell you how many minutes, I might say less than 30. A Google search (as seen below) indicates it could take as long as 72 hours. In this case, only going live over a long holiday would prevent going live during peak traffic.
Authentication Issues
The biggest roadblock I have seen when going live in many cases is the hosting or domain (DNS) being a show stopper. You will want to test any logins to make sure you will be able to access them. Ensure that you have access to the notification email/phone number, as needed. In many cases, I have the client on the phone/IM when requesting authentication.
Documenting Any Previous Settings
I strongly recommend documenting the previous settings, especially regarding DNS changes. As I was starting my web career, I was working on a bigger website, and based on advice from hosting support, I made an incorrect change that caused the client’s email to stop working.
Now I will screenshot any DNS changes before I make any updates. The seconds it takes is a good investment.
The Time it Takes May Not be Active Time
As previously mentioned, a DNS change may be the most significant factor when making a website go live. I have seen it take from minutes to several hours. If I am sitting and waiting for a DNS change to propagate, am I billing for the time? The answer to that question could be different at 1 AM versus 1 PM.
Going Live on a Friday / End of the Week
I prefer not to go live on a Friday; if going live at the end of the week does not go as expected, you may work over the weekend. Working in an unplanned manner on the weekend is not only not an option for me but for most developers. I set the cutoff time to before lunch local time on Thursday or will push the go-live time to the following Monday.
Going Live Without a Quarantine Period
One of the most problematic issues I have seen is when you have a go-live date immediately with (a) pending task(s). There should be a period of at least a day from when the developer completes the last task and going live. The larger the site, the longer the quarantine period.
Having a Fallback Plan
If going live does not go as expected, you should have a fallback plan. A fallback goal is critical to already have in place. It may be as simple as reverting any changes.
Don’t be Afraid to Push Back on a Date
If a project manager sets a go-live date based on a previous promise and not an immediate event, feel free to ask for an extension. It is always better to do it right and be a day or so late than risk having a website go live and have more issues later. If you are transparent with the client, they will understand the issues. A well-documented system to update your client is key.
Conclusion
So when someone asks when the best time is to go live, my opinion is that it is better to start the process of going live with a website right after the first cup of coffee in the morning. Going live after a full night of rest reduces the chances that fatigue will play a significant factor. Feel free to contact me with any questions.
