How we launch a new website
The launch of a new website is exciting, the end of a long process with involvement from designers, content strategists, product managers, developers, and more. Not to mention all the work done by the client: creating content, learning how to use the CMS, testing user journeys, and managing stakeholders. So a launch is absolutely something to be celebrated — it’s a huge achievement and the end point of some amazing team work. The site launch needs careful thought and planning, and can sometimes be something which is a bit rushed, as everyone stampedes towards the finish line.
1. Before launch 📋
Communication with your org:
It may feel as though your life has revolved around this project from the beginning of time, and unbelievable to think that it hasn’t occupied as much brain space for everyone else in your organisation — however, some people might not even be aware that there’s a new site in the works, or at least, not know when it’s going live. This is especially true if your org is not particularly digitally mature and prone to working in silos.
- Find out if there are other digital plans coming up such as campaign launches, to ensure the site launch doesn’t clash
- Give everyone fair warning that there will be a content freeze for a period of time while the site launches — this will help to prevent any content being lost and help to manage expectations across teams who have digital requests in the pipeline
- There might be lots of different users of the current site CMS who will need training up on the new platform — make sure to book that in to reassure teams that they won’t be left behind
User acceptance testing:
We’ve written a blog post about UAT so I won’t dive into too much detail about it here. It’s extremely important though, as without doing this due diligence, you’re signing off a website to be launched to your users without making sure you’re happy with how it’s working.
- Test key journeys and interactions across multiple browsers and devices
- Get lots of people involved in testing but give them a very clear brief so they know exactly what to test and the expected behaviour of the site — then they can flag any unexpected behaviour as a bug to be fixed or as something to potentially go into the backlog
Hosting set up:
This is a straightforward one and can be decided early on in the project. Hosting can be very cheap or it can be very expensive — and in most instances, you get what you pay for. If your website is expected to receive a LOT of traffic, perhaps in spikes, and with lots of interactive elements such as making payments or filling in forms, then it’s best to go for the more expensive hosting option.
A more expensive hosting option will likely mean the website sits on its own server, is monitored closely for performance, has 24 hour support in case of emergency, and automatically spins up new servers when traffic hits a certain volume, so the site is far less likely to crash during busy periods — maybe something Ticketmaster is reflecting on…
If your website isn’t expecting huge numbers of visitors and isn’t providing a critical service (such as an online mental health tool) then the less expensive options are very viable. We typically recommend a package from Krystal, who provide very reliable hosting services and use 100% renewable electricity from sources like the sun, wind and sea.
- Look into how much traffic you’re expecting to the site, and if there are likely to be (un/expected) spikes in traffic
- Consider whether the agency who is building your site will be looking after the hosting of the site — you need to know who to talk to if the site goes down or something happens server side
2. During launch 🚀
Switching from the dev site to the live site:
This is handled by the developers, and can be thought of as the “push the button” moment - the staging site where the new site has been built, the content has been added to, and the testing has occurred becomes the live site. Often you’re replacing a site, so the DNS (domain name system) switch takes place at this point — the new site takes over from the old one.
- You will probably need to give a developer access to your control panel to let them change the staging site’s URL to use the live domain name (e.g from “yourdomain.dev” to “yourdomain.org”)
- The DNS (domain name system) then needs to be edited to point the domain name to the new site. You or someone in your organisation might handle the DNS switch internally
- Make sure everyone knows there’s a content freeze during the launch
- Aim to launch during a quiet period for site traffic
- Never launch on a Friday — much safer to do it between Monday and Thursday so the agency team can jump on any bugs
3. Post-launch 🔬
Test it again:
Just in case! Especially where other systems are involved — it’s a good idea to test that the launch went smoothly and that the newly live site is connected to, for example, the live Salesforce instance instead of the sandbox environment.
You shouldn’t have to go into as much depth on the testing side after launch (though that does depend on the type and complexity of the site you’re launching), but it’s definitely a good idea to do some spot checks of key journeys.
- Put through several variations of donation
- Sign up to e-news
- Submit a few forms
- Check the site out on a few different browsers and devices (prioritise the ones you know your audiences will be using)
What next?
The launch of your new site is an exciting milestone to hit. But it doesn’t stop there. It’s unlikely that you’ll have been able to deliver every single thing you wanted, so you will inevitably have a backlog full of features, functionality, and test ideas. The launch of a new site can also generate a lot of excitement and ideas from within the organisation, or from your audiences on social media — capture them and put them in the backlog for future planning.
- Write a blog post that shares the news of the launch with your audiences (internal and external) which highlights some of the key changes to the site — why is this one better than the old one? We recently launched a new site with Christians Against Poverty who wrote a fantastic blog post doing just this.
- Maintain the backlog
- Get feedback from audiences
- Remember that this launch is the end of a key phase, not the end of the road
- Look after the website — it will need maintenance: security patches, bug fixes, CMS upgrades. Think of it like getting a new car — you still need to add screenwash, put air in the tyres, even give it an occasional wash if you want it to remain as shiny as possible for as long as possible.
But for now, congratulations on your brilliant new website!
