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.
Organisations that lived through the Drupal 7 to 8 transition tend to assume every major version is a rebuild. Drupal 11 is not. Since Drupal 8 the project has followed a continuous upgrade path: deprecated code is removed at major releases, but the data model, configuration system and module architecture carry forward.
In practice that means a site on a current Drupal 10 with well-maintained contributed modules can often move to Drupal 11 in a matter of days rather than months. The work concentrates in dependency compatibility, not in content migration.
The upgrade is gated by your contributed and custom modules, not by core. Start with an inventory: run composer outdated and the Upgrade Status module to produce a compatibility report for every installed extension.
It is worth being ruthless here. A module carried forward through three major versions purely because nobody wanted to remove it is a recurring cost, and an upgrade is the natural moment to retire it.
Drupal 11 raises the floor on the underlying platform. Confirm your hosting supports the required PHP version and database server versions before scheduling anything, because on shared or managed hosting that can be the longest lead item.
If you are running your own infrastructure, treat the platform upgrade as a separate change from the Drupal upgrade. Doing both at once makes it much harder to attribute a failure to a cause.
Get to the latest Drupal 10 release first, with every module current. An upgrade from an up-to-date 10 is straightforward; an upgrade from a 10.0 site that has drifted for two years is not.
Then resolve deprecations in custom code, update the platform, and only then bump core. Rehearse the whole sequence on a copy of production, including the database update step, and time it so you know what the maintenance window really needs to be.
Keep configuration in code throughout. If site configuration lives only in the production database, every rehearsal is guesswork and the real upgrade becomes a one-way door.
Every upgrade surfaces a handful of modules with no Drupal 11 release and no active maintainer. There are four honest options and it is worth naming them explicitly rather than drifting.
You can adopt the module and maintain it yourself, which is reasonable if it is small and central to your site. You can replace it with a maintained alternative, which usually costs configuration and content changes. You can fold the functionality into a small custom module, which is often the cheapest answer for something simple. Or you can remove the feature, which is the right call more often than teams expect.
Make this decision consciously for each one, and record the reasoning. The team doing the next upgrade will need it, and “we do not know why this is here” is how technical debt compounds across versions.
For a well-maintained site with current modules, the technical work is often a matter of days. The variable is dependency remediation: a site carrying several abandoned modules or a large amount of custom code with deprecated API usage will take considerably longer, and that assessment should happen before any schedule is agreed.
No. Unlike the Drupal 7 to 8 transition, this is an in-place upgrade rather than a migration. Content and configuration carry forward. That said, the upgrade should still be rehearsed against a copy of production so that any module-specific update hooks are exercised before the real run.
For a while. Each major version has a defined end-of-life after which security coverage stops, so staying put is a decision with a deadline attached. Planning the upgrade while the current version is still supported is materially cheaper than doing it under pressure afterwards.
Keep reading
Most difficult Drupal builds are content-modelling failures, not code failures. How to model entities, fields and taxonomies so a site stays maintainable.
Drupal has a strong security team and a predictable advisory process. The risk on most sites is not the platform, it is that nobody is watching the advisories.
Drupal handles translation better than most content platforms, but the decisions you make in the first week determine whether adding a language later is easy or painful.
