Hacking a site through a vulnerability in Drupal is a common story. According to statistics, 80% of successful attacks exploit known CVEs for which patches have already been released. Regularly updating the core and modules is the only way to protect yourself.
According to Drupal.org, more than 90% of vulnerabilities are closed by security updates. We help clients carry out this process safely and without surprises. Our engineers have 7+ years of experience with Drupal 7/8/9/10 and guarantee a rollback of changes at any time.
Drupal uses Composer for dependency management — updating the core and modules happens through it. Without Composer (manual installation) — switch to a Composer-based setup, otherwise every update will be a manual operation.
We migrate projects to Composer and set up CI/CD for automatic updates. This makes it possible to cut update time by 3 times compared to manual work.
What problems do we solve?
Outdated modules and their dependencies
Using composer outdated "drupal/*" and drush pm:security, we identify modules that require updating. Modules often have mutual dependencies, and updating one can pull a whole chain.
We analyze the dependency graph and update everything with a single command composer update "drupal/*" --with-all-dependencies to avoid conflicts.
Version conflicts during a major update
When migrating from Drupal 9 to 10, many contributed modules may be incompatible. We use Upgrade Status for preliminary analysis and Rector for automatic fixing of custom code. If a module has no alternative, we adapt it for the new version.
Data loss due to missing backup
The main mistake is skipping the backup. We always create a full database dump and archive the files: drush sql:dump --result-file=/backups/drupal-$(date +%Y%m%d).sql --gzip and a file backup. We test on a copy to eliminate production downtime.
A real-world example: for an online store on Drupal 9, we set up CI/CD on GitLab CI. The pipeline automatically created a backup, updated the core and modules, ran Nightwatch tests, and applied changes to staging.
As a result, manual update time was reduced from 4 hours to 30 minutes, and the risk of error decreased by 80%.
Drupal Update Process
Updating the Drupal core and modules follows 6 sequential steps:
- Create a backup of the site's database and files.
- Check for available updates via
composer outdatedanddrush pm:security. - Update the core and all contributed modules.
- Apply database schema updates via
drush updatedb. - Test on a staging environment (PHPUnit, Nightwatch).
- Deploy to production and monitor for errors.
Preparation and Backup
drush sql:dump --result-file=/backups/drupal-$(date +%Y%m%d).sql --gzip
tar czf /backups/files-$(date +%Y%m%d).tar.gz /var/www/site/web/sites/default/files
drush state:set system.maintenance_mode 1 --input-format=integer
drush cr
Checking for Available Updates
composer outdated "drupal/*" drush pm:security
Updating Core and Modules
composer update "drupal/*" --with-all-dependencies drush updatedb drush cr
For a major update, additionally:
composer require drupal/core-recommended:^10 --update-with-all-dependencies
vendor/bin/rector process web/modules/custom
Testing
drush state:set system.maintenance_mode 0 --input-format=integer
drush cr
./vendor/bin/phpunit web/modules/custom
drush watchdog:show --severity=Error --count=50
Comparison of update types
| Update type | Time | Risks | Tools |
|---|---|---|---|
| Minor (10.2 → 10.3) | 1-2 hours | Low | Composer, drush |
| Major (9 → 10) | 1-3 days | Medium | Upgrade Status, Rector |
| Security | 30 minutes | Minimal | Composer audit |
The Importance of Timely Security Updates
Vulnerabilities in modules are the most common cause of hacks. Security patches are released monthly, and delaying them increases risk. CI/CD allows such updates to be applied automatically during off-hours, minimizing the impact on users.
How to avoid mistakes when updating Drupal?
| Mistake | Consequence | Solution |
|---|---|---|
| No backup | Data loss | We always create a backup before updating |
Skipping drush updatedb |
Database incompatibility | We run drush updatedb without fail |
| Ignoring module compatibility | White screen | We check via Upgrade Status |
Example of a failed update
One client tried to update a module without a backup and got a white screen. We restored the site in 2 hours, but if there had been a backup, the update would have taken 15 minutes. More details in our process.What the update work includes
- Full backup of the database and files
- Updating the core to the latest compatible version
- Updating all contributed modules
- Checking custom code compatibility (for major migrations)
- Testing on a copy of the site
- Documentation describing the changes
- Setting up CI/CD for automatic updates (GitHub Actions, GitLab CI)
Timeline and cost
A scheduled update of the core and modules takes from 2 to 4 hours, with the cost calculated after audit. A major migration (Drupal 9 → 10) takes from 1 to 3 days, with the cost calculated after audit.
Setting up CI/CD for automatic updates — the cost is calculated after audit; automation is cheaper than manual monthly maintenance and pays for itself within 3–4 update cycles. The cost is calculated individually after an audit — we will assess the project within 1 business day.
Get a consultation on updating your Drupal site and contact us to calculate the optimal maintenance plan.
