Drupal 10 End of Life: Upgrade Before December 2026

Drupal 10 now has a firm finish line. The official Drupal release schedule lists 9 December 2026 as the end-of-life date for Drupal 10, and confirms that Drupal 10.6 is its final minor release.

For a business website, end of life is not simply a prompt to click an update button. A Drupal major upgrade can touch hosting, PHP and database versions, contributed modules, custom code, themes, forms, search, authentication, API integrations, deployment and editorial workflows. The more connected the site is, the more valuable it is to start while there is time to test and remediate.

This guide is for Australian business owners, marketing and operations managers, and technology decision-makers responsible for a Drupal 10 website. The practical target is Drupal 11: Drupal's upgrade documentation says major versions cannot be skipped, so a Drupal 10 site must move through Drupal 11 before it can move to Drupal 12.

Why Drupal 10 end of life matters to the business

The immediate concern is security maintenance, but the operational risk is broader. A rushed upgrade can interrupt lead forms, customer portals, payments, search, single sign-on, publishing or integrations that staff depend on. Waiting also compresses vendor availability, internal approvals and change windows into the end-of-year period.

Drupal 11 is the sensible near-term target for most Drupal 10 sites. The Drupal 12 platform announcement says Drupal 11 will remain supported until at least Drupal 13, expected in mid-to-late 2028. That gives businesses a supported landing point without making a December release the first production target.

Who should start now

• Sites with custom modules or themes that may use APIs removed in Drupal 11.
• Sites with many contributed modules, especially where maintainers, compatibility releases or Composer constraints are uncertain.
• Sites on older hosting that may not meet Drupal 11's PHP or database requirements.
• Business-critical websites and portals with forms, search, payments, accounts, workflows or external integrations.
• Organisations without a current development environment, automated tests or clear technical owner.

A small brochure site using well-maintained modules may have a short path. A highly customised platform should be treated as a controlled modernisation project with evidence at each gate.

Start with a Drupal upgrade inventory

Before changing code, establish what the website actually contains and what the business expects it to do. The inventory becomes the scope for compatibility checks, estimates, test cases and rollout approval.

Also record ownership. Every critical integration or workflow should have someone who can confirm expected behaviour and sign off the result.

Find module and custom-code blockers while still on Drupal 10

The Upgrade Status module checks whether the environment and installed projects are ready for the next major release, and can scan custom code for compatibility issues. Drupal specifically notes that most compatibility checks should run on the current site, because removed APIs are no longer present after the upgrade.

Use the report as an evidence source, not an automatic guarantee. For every blocker, choose an explicit treatment:

1. Update the module or theme to a release that supports both Drupal 10 and 11 where possible.
2. Replace or remove it if the project is abandoned, unnecessary or now covered by another maintained solution.
3. Refactor custom code using Drupal Rector where appropriate, followed by manual review and tests.
4. Resolve Composer constraints and patches so the dependency graph installs consistently from a clean checkout.
5. Document accepted risk only when there is a named owner, limited impact and a plan to remove the exception.

Pay particular attention to core extensions removed from Drupal 11. The official guide names Actions UI, Activity Tracker, Book, Forum, Statistics and Tour. A site using one of them may need to stop using it or move to an appropriate contributed replacement before the core upgrade.

A controlled Drupal 10 to 11 upgrade sequence

Perform the first complete upgrade in a development or isolated copy, not on the live website. The exact Composer commands depend on the project, but the release process should be consistent and repeatable.

1. Bring Drupal 10 current. Move to a supported Drupal 10 minor and resolve existing status-report warnings before changing the major version.
2. Create a clean baseline. Back up files and database, record scaffold-file customisations, confirm the repository builds from scratch and capture current smoke-test results.
3. Run compatibility analysis. Scan contributed and custom code, check hosting requirements and classify every blocker by owner and treatment.
4. Update dependencies in development. Adjust Composer constraints, perform a dry run, complete the update and run database updates.
5. Reapply intentional scaffold changes. Drupal warns that core scaffold files, including .htaccess, will change; carry forward only reviewed customisations.
6. Test the application and business workflows. Run automated tests, manual workflow checks and integration reconciliation against production-like data.
7. Rehearse deployment and rollback. Measure downtime or maintenance-mode duration, verify backups and confirm who makes the go/no-go decision.
8. Release and monitor. Deploy in an agreed window, run database updates and cache rebuilds, watch logs, run cron and sample critical transactions.

Drupal's guide recommends a Composer dry run, database update checks, automated tests, log monitoring and cron verification. Those steps are the technical baseline; the business should add its own acceptance evidence.

A practical plan for the next 90 days

Days 1–15: discover

• Confirm Drupal core, PHP, database, Composer and Drush versions.
• Inventory extensions, custom code, integrations, workflows and owners.
• Run Upgrade Status and capture the first blocker register.
• Confirm whether hosting changes or a new staging environment are required.

Days 16–45: remediate and rehearse

• Update or replace incompatible modules and themes.
• Refactor deprecated custom code and resolve dependency constraints.
• Complete the first Drupal 11 upgrade in development.
• Build the business regression pack and fix high-impact failures.

Days 46–75: prove the release

• Repeat the upgrade against a fresh production-like copy.
• Run integration, security, performance, accessibility and editorial acceptance checks.
• Document deployment steps, maintenance mode, rollback triggers and communications.

Days 76–90: release and stabilise

• Schedule the production change before the support deadline and outside critical trading or campaign periods.
• Monitor logs, queues, cron, forms, search and integrations closely after release.
• Close temporary patches, update operating documentation and schedule the next maintenance review.

If the first audit reveals unsupported modules, missing source control, no viable staging environment or unknown integrations, escalate early. Those are scope signals, not reasons to postpone discovery.

Sources Checked

• Drupal.org: Drupal core release schedule (updated 23 July 2026)
• Drupal.org: How to upgrade from Drupal 10 to Drupal 11 (updated 21 August 2026)
• Drupal.org: Upgrading Drupal
• Drupal.org: Upgrade Status project
• Drupal.org: PHP requirements (updated 4 August 2026)
• Drupal.org: Database server requirements (updated 19 May 2026)
• Drupal.org: Drupal 11.0.0 release
• Drupal.org: Drupal 12.0.0 platform requirements announcement (14 January 2026)