Getting to the 'launch' stage of a project can feel like a huge relief. You've finally done your development work, creating a site according to your client's brief or your own requirements, and now you can press that metaphorical button and launch the site for the world to see.

But wait.

Before you launch, you need to run some checks to make sure it's robust and future-proof. By running these checks before you launch each new site, you can avoid running into problems later on. In particular you can avoid the headaches, embarrassment, and damage to your reputation caused by having clients or users spotting problems once the site has gone live.

In this article, I'll share the checklist I use before migrating a site to live. I'm not claiming that this is the holy grail of lists - you will have some things you don't do, that you do differently, or that you do in addition to this.

It's worth noting that pre-launch checks aren't just relevant immediately prior to launching a site - depending on the complexity of your project, you'll need to work many of these in as you go along. This will save you time and rework when the site's ready to go live, and will help with sign-off and credibility at stages throughout development where your client is reviewing work on the site.

But having said that, I do think it's worth giving that list a final run-through before launch, just to be sure.

My list is split into four categories:

1. Project or brief-specific checks
2. Robustness
3. Future-proofing
4. Final actions

Below I'll outline what each of these is about and provide a list of items for each category.

1. Project or Brief-Specific Checks

Making sure the site meets the agreed brief is something you should be doing all along, but it's worth running a final check before launch. 

This checklist will be different for each project so I can't really give you one standard list, but there are some key pointers you can use. You should run through this list before you migrate the site to the live server:

1. Check the brief. If the brief you agreed with the client has a checklist of site features or elements, check these are all covered, and if not, that you've agreed this with the client.
2. Check issues or tasks. If you're using an issue or task tracking system (e.g. issues in GitHub), check that all issues have been closed or tasks completed, and that there are no outstanding bugs or questions.
3. Check requested changes. Check any changes requested during development (which may not be in the original brief) have been made, unless these are being saved for post-launch.
4. Test in-site processes. If the site includes processes or interactions users will need to perform, run through those processes on multiple browsers and devices to be sure they work according to the brief.
5. Tidy up users. If you've created any dummy logins or, say, linked the site to a sandbox PayPal setup, change these to the live versions (you may need to check this again after migration).
6. Check any copyrights and/or credits such as photo credits.
7. Tidy up text. If you've used filler text (such as lorem ipsum), make sure it's all been replaced by more appropriate content. Even a note advising visitors that a page's content is under development is a lot more helpful and professional looking than lorem ipsum text.
8. Test admin customizations. If you've customized the WordPress admin, check that this works for all the user roles your client will be using.
9. Test third party services. If the site is integrated with any third party services, check that this is all working and that software is up to date (you may need to check this again after migration).

This isn't an exhaustive list as your project may have additional items you need to consider, but it will give you a basis to work from.

2. Robustness

Most of the items in this checklist will apply to all sites, but there may be some variations for different projects, for example if a client requires you to support specific devices (although I would always advocate a device-agnostic approach to development).

Work through the first part of this list before migrating the site to the live server:

1. Browser testing. Test your site in all of the browsers you are supporting (which you should have agreed with your client). You should be doing this as you go along and ideally using progressive enhancement, but you should make final checks before going live. Test content using each template in your theme: single posts, pages, archives, and custom post types.
2. Device compatibility. Test your site across all of the devices you are supporting. Again you should have done this as you worked on the site, and used responsive design to accommodate different screen sizes. If your site uses plugins or enhancements with varying levels of support across devices, check what users will experience when they view it on these devices and put in place an alternative, or a link to somewhere they can access content otherwise unavailable to them.
3. Validate your code using the W3C's validator - again you really should be doing this as you go along. If your code doesn't validate, you may sometimes decide not to change it, for example if you are using HTML5 features which don't validate. If this is the case, make sure it won't cause problems in browsers which don't support newer features (using the progressive enhancement approach already referred to).
4. Check your site is accessible. For advice on accessibility in WordPress, see Graham Armfield's excellent web accessibility guide and the guidance in the WordPress codex.  

After migrating your site to the live server, there will be additional tests for robustness which you may need to do:

1. Test your navigation and links, especially any redirects.
2. Check that the database is being read correctly and from the right place - if your live site is reading content from your development database, this won't be immediately apparent if you've copied the database's contents across, as the two will be identical. In particular check links in text widgets and images.
3. Double check integration with third party software and services. These should all be communicating with your live site, not your development site.
4. Check that site settings refer to the live url (for example the site url and WordPress url).
5. Make sure permalinks are working correctly for all content types - you may need to configure these or visit the Permalink settings screen to flush them.
6. Users. Test your site (front-end and admin) using all of the WordPress user roles your client will be using. Set up any users you need to.

3. Future-Proofing the Site

The third list is all about making sure the site is ready for future development and additions. This will be particularly important if you are handing the site over to your client for them to manage and update.

1. Ensure basic SEO has been set up. Titles and meta descriptions should be worked into your theme or added using an SEO plugin. Depending on the needs of the project, you may need to spend time configuring the plugin to meet your client's needs. Another important but easily overlooked check: if you blocked access to search engines during development, remove the block at launch, either using the WordPress settings or with a robots.txt file.
2. Make a backup of the files and database at launch.
3. Set up an automated backup system for theme and plugin files and the database. How this is managed and who has responsibility for it will depend on what you've agreed with your client and on what hosting setup they have. There are a range of WordPress plugins for this, including premium plugins like Backup Buddy or free plugins like WordPress Backup to Dropbox.
4. Configure the site for Google analytics, either using a plugin or by adding the tracking code to your theme.
5. Put in place a system for keeping the site updated. This doesn't just include WordPress itself but also themes and plugins. Whether you do this, the client does or their hosting provider looks after it will depend on what you've agreed with your client. You may need to agree a specific site maintenance contract for this.
6. Agree a schedule for site reviews. Once launched, a website shouldn't just be left alone. Agree with your client how frequently you will review the site's performance and effectiveness, and make sure you keep in touch with your client so they come to you when they need further development work done.

4. Final Actions

The fourth and final part of my checklist is very short, and completes the launch process.

1. Revisit any of the above checks as necessary. If you've made changes following any of your checks (e.g. if you've edited the theme after finding code that didn't validate), redo the check that prompted the change and any checks you did before that whose results may have been affected. For example, does your new validated code work across all devices or browsers?
2. Approval. If there are any significant changes following your checks, you may need to obtain client sign-off again.
3. Communicate. Make sure your client and any other stakeholders know that the site has gone live. If it's your own site or your client has asked you to publicise it, do this using social media, blog posts or other channels. Add it to your portfolio if you're proud of it!
4. Get paid. Don't forget to send your client an invoice for the launch stage of the project.

Summary

As I mentioned earlier in this article, this list doesn't aim to be the definitive list for all WordPress developers, but hopefully it's helpful to anyone looking to introduce some consistency into their site migration process.

Take this list and edit it so it works for your way of working and your projects, Add to it, change it and scrap things that aren't relevant to you. But if you use this to develop your own checklist that you refer to every time, you can be confident that you won't miss anything important, and that any problems will be spotted by you before the site goes live, not by your clients or users afterwards.