Drupal go-live checklist
A new or updated Drupal site goes live more smoothly when the final day is not driven by memory.
Go-live starts before launch day
A Drupal go-live is not only pointing a domain or uploading code. By that point, the team should know exactly what is being released, how the result will be checked and how to roll back if needed.
A good checklist keeps attention on the things that are often missed during the final rush.
Before going live
Before the public change, at least these points should be ready:
- a fresh backup of database, files and code;
- a known rollback plan;
- tested forms;
- checked administrator permissions;
- correct email settings;
- reviewed redirects from old URLs;
- checked titles, meta descriptions and sharing images;
- sitemap and robots.txt;
- a cache clearing plan.
If the site is multilingual, language switching, canonical URLs and hreflang links should also be checked separately.
During go-live
During go-live, the order of work should stay simple. Each change should be made so that its result can be checked immediately.
A typical order:
- create the final backup;
- release code and configuration;
- run required database updates;
- clear cache;
- check the homepage, important content pages and forms;
- check logs;
- check redirects and sitemap;
- allow search engines if access was previously blocked.
Drupal's official update documentation is a good base for technical steps, but the real checklist depends on the site's modules and hosting.
After going live
The work does not end when the site opens. During the following hours and days, real use may reveal issues that were not visible in staging.
It is worth checking:
- contact forms and notifications;
- payments or requests, if they exist;
- server and Drupal logs;
- 404 errors;
- indexing;
- performance;
- user permissions.
If the change was large, someone should watch the site after go-live.
A checklist reduces the cost of rushing
A fast go-live is not a problem when preparation is good. The problem appears when the team discovers at the last moment that there is no backup, a form does not send email or old URLs return errors.
WebPro uses controlled releases as part of custom Drupal development, Drupal maintenance and automated testing. This does not make the work slow. It makes the result checkable.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.