A Drupal launch is complete when visitors can finish their tasks, editors can maintain the content, and the team can recover if something fails. Uploading the code and seeing the homepage is one checkpoint in that process.
Use this checklist to organize a release from staging to production. Assign an owner and record evidence for each area. Adapt it for the site's integrations and hosting instead of treating every project as an identical deployment.
1. Agree the release and recovery plan
Identify the exact code revision, dependency lock file, exported configuration, and content migration included in the release. Decide when editors must pause changes and how content or uploads created after the staging copy will reach production.
Take a current backup of the database, public and private files, and the settings needed to restore the service. Test recovery in an isolated environment before relying on it. Our backup and restore checklist covers what to verify.
Define a rollback decision point and who can make it. Reverting code alone may be insufficient after a database update. Restoring an earlier database can also discard enquiries or editorial changes received since the backup, so plan how to preserve or reconcile those records.
2. Rehearse the production deployment
Use the same PHP version, required extensions, and deployment sequence on staging where practical. Install the reviewed dependency lock file rather than resolving new package versions on production. Confirm that required command-line tools are included in the production build.
For projects that use exported configuration and Drush deployment hooks, drush deploy coordinates database updates, configuration import, cache rebuilding, and deployment hooks. Run it with the correct site and URI after deploying the code. Confirm your installed Drush version's behavior and your project's settings before adopting this sequence.
Review the configuration diff in advance. A full import can replace production-only changes, and content is not generally transported by configuration export. If your deployment uses seed scripts or migrations, verify that reruns preserve editor changes and do not create duplicate pages.
3. Check hosting, DNS, and HTTPS
- Point the web server at the intended public document root and keep secrets, backups, and repository metadata inaccessible.
- Confirm DNS for the chosen hostname and any alternate hostname that must redirect.
- Check certificate coverage, renewal ownership, and HTTPS behavior through both the CDN and origin where applicable.
- Test redirects on a deep page as well as the homepage, preserving the requested path.
- Verify scheduled tasks, queues, disk space, application logs, and backup destinations.
Review Drupal's trusted-host configuration. If a reverse proxy is present, trust only the intended proxy addresses and headers. A production host or scheme detected incorrectly can affect generated links and form redirects.
4. Review access and production settings
Resolve relevant findings on Drupal's status report. Review anonymous, authenticated, editor, and administrator permissions using accounts with those actual roles. Confirm that unpublished pages and private files remain inaccessible to visitors.
Keep debug output and development-only overrides out of production. Follow the hosting platform's guidance and Drupal's file-permission recommendations; avoid making the whole application writable just to resolve an upload issue. Document how updates and uploads use their separate permissions.
Protect staging with access controls. A robots.txt rule is not authentication and does not make copied customer data private. Keep production credentials and outbound integrations separated from test environments.
5. Test the journeys that matter
Walk through the site as a first-time visitor on a phone and desktop. Find a service, follow its call to action, submit a valid enquiry, and verify what arrives at the receiving system. Then try missing fields, an invalid address, and the intended spam controls.
Test the editor journey too: create a draft, add an image, preview, publish, translate if applicable, and revise. Confirm that navigation and cached listings reflect the change. Check search, downloads, account recovery, and any transactional integration within the release scope.
Include keyboard navigation, visible focus, form labels and errors, sensible heading order, zoomed layouts, and image alternatives. Automated accessibility scans are useful, but they do not replace testing those tasks with the required assistive technologies and representative users.
6. Confirm SEO and measurement
Check page titles, descriptions, canonical URLs, and social images on representative page types. Remove staging-only indexing restrictions from public production pages while retaining appropriate exclusions for private or administrative content.
For a migration, map important old URLs to their replacements and test permanent redirects. Keep genuine missing pages as real 404 responses. Google's site-move guidance covers URL mapping and search follow-up. Submit a sitemap containing the preferred production URLs; a submission does not guarantee indexing.
Verify page views and confirmed lead events without sending personal details. Test consent choices and make sure analytics failures cannot stop a form submission. Our GA4 contact tracking guide provides a focused test plan.
7. Measure performance with production settings
Test anonymous pages with caching and asset aggregation enabled. Check responsive image sizes, the main above-the-fold image, and requests introduced by third-party scripts. Compare a first visit with a repeat visit and confirm that content edits invalidate the right cached output.
Use a consistent mobile test to identify the largest delays, then validate the change in the actual page. A good desktop score does not establish the mobile experience. Our Drupal caching setup guide covers the initial checks.
8. Monitor after the switch
Immediately recheck the critical journeys against the public hostname. Watch errors, response times, form delivery, and queued jobs. Review CDN events if legitimate users or crawlers encounter challenges. Separate expected scanner 404s from broken links visitors actually follow.
Record the launch result, remaining issues, responsible owners, and the next review date. Hand over monitoring access, recovery instructions, and the maintenance schedule. Druproid Support can help maintain the site after launch, or review your launch plan before the switch.