Migrating from Drupal 10 to Drupal 11: the practical guide

Drupal 10 reaches end of support in December 2026. If your site still runs on it, there is still time to migrate calmly — provided you start now rather than in the final quarter, when every Drupal agency and freelancer will be fully booked.

Good news: unlike the Drupal 7 → 8/9/10 trauma, the 10 → 11 upgrade is a classic major update, not a rewrite. Here is the method I apply on client engagements, step by step.

1. Take stock with Upgrade Status

The Upgrade Status module is your starting point. It analyses the site and answers three questions:

• is your environment ready (PHP version, database, Composer)?
• do your contrib modules have a Drupal 11-compatible release?
• does your custom code use deprecated APIs?

composer require --dev drupal/upgrade_status
drush en upgrade_status
drush upgrade_status:analyze --all

Export the report and turn it into a backlog: every line is a task, with a severity and an owner.

2. Prepare the environment

Drupal 11 requires PHP 8.3 and recent database versions. This is the moment to upgrade your environments (local, CI, staging, production) — before the migration, so problems stay isolated. If your hosting cannot follow, that is where your real project is, not in Drupal.

3. Clean up before you upgrade

A golden rule I apply on every engagement: never migrate what is no longer used.

• Uninstall unused modules (actually uninstalled, not just disabled).
• Remove dead themes and “just in case” commented-out code.
• Audit your Composer patches: many have become unnecessary.

Every module you remove is migration risk and migration time removed.

4. Fix deprecations with Rector

For custom code, Drupal Rector automates a large share of the fixes:

composer require --dev palantirnet/drupal-rector
vendor/bin/rector process web/modules/custom --dry-run

What remains after Rector is fixed by hand — and that is usually where the real subjects hide (removed APIs, reorganised hooks, changed service constructors).

5. Handle contrib case by case

Three possible situations for each contrib module:

1. A compatible release exists: update, test, move on.
2. Compatibility in progress: there is often a working merge request in the issue queue. As a maintainer of 24 modules I can confirm it: testing and commenting on those MRs saves everyone time — and lenient lets you use them cleanly in the meantime.
3. Abandoned module: look for the modern replacement, or ask yourself — if nobody maintains it, do you really need it?

6. Upgrade, test, cut over

The upgrade itself is a formality once everything above is done:

composer require drupal/core-recommended:^11 drupal/core-composer-scaffold:^11 --update-with-all-dependencies
drush updb
drush cr

The real value is then in acceptance testing: critical journeys tested with the business teams, key pages compared, exports/APIs verified, a documented rollback plan.

7. Do not sacrifice your SEO at cut-over

This is the blind spot of most migrations, and the reason I treat every migration as an SEO project too:

• inventory URLs and rankings before the switch (crawl + Search Console);
• every URL that changes gets a 301 redirect — page to page, not to the home page;
• verify meta tags, canonicals, hreflang and structured data on arrival;
• monitor index coverage in Search Console for the following weeks.

A technically successful migration that loses 40% of organic traffic is not a successful migration.

How long should you plan for?

Orders of magnitude seen on engagements: from a few days for a well-maintained brochure site to several weeks for a platform rich in custom code and exotic contrib. The audit in step 1 gives you the answer for your site within a day.

---

Want an assessment before you start, or the whole migration handled for you? Let’s talk — I do this all year round.