14 Must Do Items for your Drupal Post-Launch Checklist

To ensure a launch process goes smoothly I like to create three checklists. A pre-launch checklist covers everything you need to do a few days before launch to ensure everything is prepared. A launch checklist outlines the actual process the launch team will go through during the launch window itself. And a post-launch checklist details a variety of tasks you can’t really do until the site is live, and you do a few days after launch.

I recently had to prepare three such checklists for the launch of a high-traffic Drupal site. I wanted to share the post-launch checklist I used for the launch:

1. Disable old site on server
Once the site is live you will want to turn off the old web server. I usually recommend turning it off for a few days before actually destroying it. If the server was doing anything you didn’t expect it will be obvious during this off time and you can recover and move any needed assets.

2. Review Google Webmaster Tools for index issues
Making sure a site continues to be happily indexed by search engines (especially Google) is vital to ensure client confidence during a launch. A quick check of Google Webmaster Tools will let you know if there is any old content that needs to be migrated, if Google is having problems indexing the site, or if your sitemap is not working as expected.

You might also consider checking the search site map in Bing as well.

3. Report top pages not found
Site launches involve migrations of content or changes of URLs for content. A quick check of the common 404 errors in the Drupal log will let you know if you have missed anything major.

4. Enable and review slow query log
We perform query reviews and tuning before launch, but nothing beats production data. Reviewing the MySQL slow query log is a great way to tell if you have any bottlenecks under production traffic.

5. Turn off unused modules
There are many modules you don’t need on a production site. Post-launch is a good time to make sure they get turned off. (Example: If the client isn’t going to be changing views, why not turn off the Views GUI?)

6. Perform load testing
We load test before launch, but nothing beats a load test on a production environment to validate the server will remain stable during load spikes.

7. Test your backups!
I’m from the Joel Spolsky School of Hard Knocks Backups: If you haven’t tested a restore, you haven’t backed up anything. I like to perform a full restore test of backups on the production database and files directory (to a temp directory of course) to make sure what I think is backing up actually is.

8. Review MySQL configuration and adjust as needed
Now that MySQL has been running under production traffic it’s a good time to see if you need any MySQL configuration changes. I like the Perl script mysqltuner.pl.

9. Check key server settings
I like to make sure Apache max_clients is set correctly and that the memory setting for APC is right (meaning it’s not filled up under production use).

10. Run a fail-over test
For this project we had a load balancer with multiple web servers. Like backups, until you test the fail-over you haven’t set it up.

11. Deploy stage site
If you have plans for post-launch support and development now is a good time to setup a stage server.

12. Setup vulnerability scans
We use an automated scanning tool to periodically ensure various servers and sites don’t have any security vulnerabilities. Now is a good time to add the site to this tool.

13. Capture SEO benchmarks
If you made SEO improvements in the new site now is a good time validate them. Hopefully you captured data before launch so you can compare.

14. Prepare emergency support instructions
If you are providing monitoring and support after-hours for the site this is a good time to prepare emergency support instructions which detail the process one goes through to troubleshoot and communicate during an unscheduled outage.

Do you have any others? Let me know!

UPDATE: Used a more current link to mysqltuner.pl. Thanks dalin!