Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Drupal publishes security advisories on a predictable, documented schedule.
- The risk on most sites is that nobody is monitoring or applying them.
- Every contributed module is a long-term security and maintenance commitment.
- A backup nobody has restored is a hypothesis, not a backup.
The advisory process
The Drupal Security Team publishes advisories on a predictable schedule, with severity scored using a documented risk model. Core security releases are usually announced in advance so teams can plan a window.
That predictability is an advantage over platforms where updates arrive unannounced — but only if somebody is subscribed and acting on them. An unmaintained Drupal site is not more secure than any other unmaintained site.
What a maintenance agreement should cover
- Monitoring of core and contributed advisories, with a named person responsible.
- A defined window for applying critical patches, and a slower cadence for lower-severity items.
- Regular dependency updates through Composer, not just Drupal itself.
- Backup verification — a backup nobody has restored is a hypothesis.
- A staging environment where updates are applied and checked before production.
The last point matters more than it sounds. Applying a security patch straight to production on a Friday afternoon is how a security fix becomes an outage.
The contributed module question
Every contributed module is a long-term commitment. Before adding one, check the maintenance status, the number of open issues, the release cadence and whether it has a Drupal 11 compatible release.
Modules that are abandoned upstream are the most common source of upgrade pain and unpatched vulnerabilities. Auditing the module list once a year and removing what is no longer earning its place is cheap compared to discovering the problem during an upgrade.
Hardening beyond patching
Patching is necessary and not sufficient. Restrict administrative access by role and by network where practical, enforce strong authentication for privileged accounts, keep the PHP filter module off, and ensure file uploads are validated and stored outside the webroot where the use case allows.
Log administrative actions and review them. Most incidents on content-managed sites involve credentials rather than exotic exploits.
Building the routine
Security maintenance fails when it depends on someone remembering. It works when it is a scheduled routine with a named owner and a defined window, in the same way as any other operational task.
A workable rhythm: subscribe to the security advisory feed so notifications arrive automatically; hold a short monthly slot for routine updates applied to staging and then production; and keep a defined path for critical advisories that can be executed within a day rather than waiting for the monthly slot.
Record what was applied and when. When a question arises about whether a particular vulnerability affected you, having the record turns a stressful investigation into a lookup — and if you operate under any form of audit, you will be asked.
Frequently asked questions
It depends on the severity and on whether the vulnerable path is reachable on your site. Critical advisories affecting a module you run should be applied within a day or two, on a staging environment first. Lower-severity items can wait for the routine cycle.
Yes, on a slower cadence. Sites that only apply security patches drift steadily further from current releases, and the eventual catch-up becomes a project rather than a task. Routine updates keep each step small.
Neither platform is inherently insecure. Both have mature security teams and a strong advisory process. The overwhelming majority of incidents on either platform trace to unpatched extensions, weak credentials or unmaintained hosting rather than to a flaw in core.
