Drupal 10 End of Life: Upgrade to 11, Wait for 12, or Replatform

Drupal 10 End of Life: Upgrade to 11, Wait for 12, or Replatform

Drupal 10 reaches end of life on December 9, 2026. After that date, the Drupal Security Team stops issuing security advisories and patches for Drupal 10 core and contributed modules. Your site keeps running — nothing shuts down — but every vulnerability discovered from December 10 onward stays open until you upgrade.

The planning implication matters more than the date itself: there is no direct upgrade path from Drupal 10 to Drupal 12. Drupal 12 ships the week of December 7, 2026, and every Drupal 10 site must pass through Drupal 11.3 or later before it can reach Drupal 12. You cannot skip the stepping stone. For most production teams, that means upgrading to Drupal 11 now rather than waiting for Drupal 12.

This guide covers the exact timeline, the minor-version trap most teams miss, the upgrade path constraint that shapes every plan, and how to choose between upgrading to Drupal 11 now, staging a move to Drupal 12, or replatforming entirely.

Disclosure: This post is published by ClonePartner, a data migration vendor. The upgrade sections reflect our honest reading of drupal.org documentation and community timelines. The replatforming section covers a service we offer; we have labeled it clearly.

For broader context on every major software deadline in this window, see our 2026 EOL calendar and our CMS and DXP end-of-support calendar.

What Does Drupal 10 End of Life Actually Mean?

Drupal 10 end of life is the date the Drupal community permanently stops maintaining Drupal 10 — no security advisories, no core patches, no contributed module security releases for the Drupal 10 branch. The drupal.org core release schedule states it plainly: Drupal 10 will reach end of life on December 9, 2026, the same week Drupal 12 is released, and no new releases of Drupal 10 will be made after that date.

Three things stop on December 9:

• Core security releases for any Drupal 10 branch
• Contributed module security releases targeting Drupal 10
• Compliance coverage — auditors will flag any Drupal 10 site as running unsupported software

Your Drupal 10 site will not go offline on December 10. It will continue to serve pages, process forms, and query the database. But any new vulnerabilities discovered in Drupal core, Symfony components, or third-party dependencies will remain unpatched, leaving your site exposed to automated exploits targeting known CVEs in unsupported software.

What "compliance failure" means operationally: Under SOC 2 Type II, running unsupported software typically surfaces as a finding in the Availability and Security categories, which can prevent certification renewal or trigger a qualified opinion. PCI-DSS Requirement 6.3.3 explicitly mandates that all software components are protected from known vulnerabilities — running EOL software violates this requirement and can result in a failed Report on Compliance (ROC). HIPAA's Security Rule (45 CFR § 164.306) requires covered entities to protect against reasonably anticipated threats, and running unpatched software after a published EOL date is treated as a foreseeable risk in most auditor frameworks. Government procurement under FedRAMP and StateRAMP frameworks requires an Authority to Operate (ATO), which can be suspended or revoked when a software component reaches EOL without an approved remediation plan.

Acquia's published position: Per Acquia's published FAQ, Acquia will end support for Drupal 10.x on its products and services on December 9, 2026. Acquia Cloud Platform and Site Factory customers running Drupal 10 after that date lose platform support alongside community support. Acquia will not automatically upgrade your application code — you are responsible for updating your repository, resolving Composer conflicts, and deploying the Drupal 11 codebase.

Pantheon and Platform.sh have not published a specific Drupal 10 EOL date as of this writing, but both platforms have historically aligned their deprecation timelines with the Drupal community's published EOL dates. Verify your current hosting provider's published position directly.

Which Drupal 10 Minor Version Are You On? It Matters Now.

The December 9 headline hides a sharper edge: older Drupal 10 minor releases have already lost security coverage. Your exact minor version determines whether you're protected today or already running unpatched.

Under Drupal's release policy, each minor version receives bug and security fixes for the first six months after release and security-only coverage for the following six months — a twelve-month total support window per minor. (drupal.org release process overview)

If you are on 10.5.x or earlier, you are already running without a security net. Upgrading to 10.6.x buys you coverage through December 9, but it does not remove the need to reach Drupal 11 — it only keeps the lights on while you plan.

Check your version now — in Drupal's admin UI, go to Administration → Reports → Status report, or run from the command line:

drush status | grep 'Drupal version'
composer why-not drupal/core ^11

The Drupal version field tells you exactly where you stand. The composer why-not command surfaces dependency blockers before you attempt the major-version move. If your team only says "we're on Drupal 10," you do not yet know whether the site is supported. (drupal.org upgrade status module)

Can You Upgrade Directly From Drupal 10 to Drupal 12?

No. Drupal's upgrade policy requires moving through each major version in sequence. The drupal.org upgrade process overview is explicit: a major version cannot be skipped during an upgrade. Drupal 12 removes all configuration, database schema, and entity/field update hooks added before Drupal 11.3.0, which means Drupal 10 sites must upgrade to Drupal 11.3.0 or higher before upgrading to Drupal 12. (drupal.org)

This is the constraint that shapes every 2026 plan:

1. Drupal 10 → Drupal 11.3+ (required first step)
2. Drupal 11.3+ → Drupal 12 (optional second step, available after December 7, 2026)

Landing on Drupal 11.0, 11.1, or 11.2 is not enough. Those versions are dead ends with no forward path to Drupal 12 — Drupal 12 has removed all update hooks prior to 11.3.0. If you're on Drupal 10.6.x, core blocks upgrading to anything below 11.3 anyway, so the floor is the same from both directions.

Why the stepping stone exists — the Symfony dimension: Drupal 10 is built on Symfony 6.4, which itself reaches end of security fixes in November 2027. Drupal 11 moves to Symfony 7.x. Symfony 7.0 removed a significant number of deprecated components and method signatures that were still present in Symfony 6.4. One concrete example: the HttpKernel event system removed several legacy listener interfaces and made RequestEvent, ResponseEvent, and related classes final in certain contexts — custom code or contributed modules that extended these classes directly rather than implementing their interfaces will fail on Symfony 7. The Symfony\Component\HttpFoundation\Request::createFromGlobals() behavior was also changed, and several Form component internals were removed entirely. Because Drupal 12 is built on Symfony 7, any code still relying on Symfony 6.4 internals — not the Drupal public API layer — must be cleaned up during the Drupal 11 upgrade, not after. Drupal's deprecation-then-removal model gives you the Drupal 10→11 step to surface and fix those issues. Skipping it removes that safety net. (drupal.org release policy)

The 11.3 floor is non-negotiable. A Drupal 10 site that upgrades to Drupal 11.1 has met the EOL deadline but still cannot reach Drupal 12. Target 11.3 or later from day one. Better yet, land on 11.4 — it's the current stable feature release with security support through June 2027.

What Does Drupal 12 Require?

Drupal 12 raises the minimum runtime and infrastructure requirements significantly beyond Drupal 11. These are confirmed from the Drupal 12.0.0-beta1 release notes and drupal.org platform requirements:

PHP 8.5 is the hard gate. Most managed hosting providers (Acquia, Pantheon, Platform.sh) will add PHP 8.5 support in time for the release, but self-hosted environments running distribution-packaged PHP need to verify Argon2 support is compiled in — Argon2id becomes the default password hashing algorithm in Drupal 12.

A useful nuance: Drupal 11.3 and 11.4 already support PHP 8.5, so you can modernize the runtime on Drupal 11 first and keep the eventual Drupal 12 move smaller.

Modules and themes leaving core in Drupal 12: The beta1 release notes list nine modules — Ban, Contact, Field Layout, History, Search, Settings Tray, Shortcut, Telephone, Toolbar — and three themes — Claro, Olivero, Stable 9 — moving to contributed projects. If your site uses any of them, install the contributed replacement in Drupal 11.3+ before running the Drupal 12 code upgrade. Drupal advises requiring the contributed replacement rather than uninstalling, to avoid configuration or data loss. (drupal.org beta1 release notes)

Drupal 12.0.x is nearly identical to Drupal 11.5.x except deprecated code is removed and dependencies are updated to newer major versions. That's why the real work is getting Drupal-11-clean now, not hoping the Drupal 12 install step will be simple.

How Long Does a Drupal 10 to 11 Upgrade Take?

The honest answer: it depends on your custom code surface and contributed module inventory. The ranges below reflect the technical upgrade work only — core, contrib modules, and custom code — broken into component phases. They do not include a site redesign, content restructuring, or platform migration.

Phase-by-phase time breakdown:

Our estimated range: 2–8 weeks for a well-maintained site with active contrib modules and modest custom code. Sites with abandoned contributed modules, deep Drupal-internal API usage in custom code, or infrastructure running below the PHP 8.3 minimum stretch to 8–16 weeks. These estimates are based on the phase breakdown above, not agency self-reporting.

The version bump itself is the easy part. Drupal 11.0 shares the same public APIs as late Drupal 10.3 releases, with the main difference being that deprecated code is stripped out. The work is in getting your custom modules, themes, and contributed dependencies clean of those deprecations before you make the jump.

What Are the Common Blockers in a Drupal 10 to 11 Upgrade?

Abandoned contributed modules

The single most common stall point. As of mid-2026, approximately 75–80% of the top 200 contributed modules on drupal.org have a Drupal 11-compatible release available. The remaining 20–25% represent the real risk surface — modules with low maintainer activity, narrow install bases, or dependencies on packages that haven't moved to Drupal 11 yet.

A module with no active maintainer and no Drupal 11 release has four outcomes: find a maintained alternative, port the module yourself by running Rector against it, sponsor a maintainer through the Drupal Association, or drop the feature. The closer you push to December, the smaller the pool of available Drupal talent to help with module porting or replacements.

Custom code using deprecated APIs

Drupal Rector handles the majority of mechanical deprecation fixes — specifically, method renames, class moves, and service container changes that follow predictable patterns. What Rector does not handle:

• Custom code that extends or overrides Drupal internal classes not exposed through the public API (e.g., directly extending DatabaseBackend rather than implementing CacheBackendInterface)
• Hook implementations relying on removed hook signatures where the replacement uses a different argument structure
• Theme preprocess functions referencing removed render element properties
• Custom code using \Drupal::service() calls for internal services that were removed or renamed without a stable public replacement
• JavaScript behaviors tied to removed core libraries (e.g., anything depending on removed jQuery UI components)

The Upgrade Status report gives you the full list of flagged deprecations, but its scanner is static-analysis-based — it catches calls to deprecated functions and classes in your code, but misses dynamic patterns like string-based service lookups, runtime-evaluated class instantiation, or anything in twig templates that calls removed filters or functions. Treat Upgrade Status output as a minimum scope, not a complete scope.

PHP and database version gaps

Drupal 11 requires PHP 8.3 minimum. Drupal 12 requires PHP 8.5. If your hosting environment is pinned to PHP 8.1 or 8.2, you need a runtime upgrade before the Drupal upgrade. On managed platforms (Acquia, Pantheon), this is usually a configuration change. On self-hosted infrastructure, it may require an OS-level upgrade — Ubuntu 20.04 LTS ships PHP 7.4 by default; Ubuntu 22.04 ships PHP 8.1; PHP 8.3 requires either the ondrej/php PPA or Ubuntu 24.04. Plan this as a distinct prerequisite with its own testing cycle.

Database hard minimums for Drupal 11: MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+, SQLite 3.45+ (with the json1 extension). For Drupal 12: MariaDB 10.11+, PostgreSQL 18+. If your current database sits below the Drupal 11 minimums, the database upgrade is a prerequisite project with its own downtime window and regression testing.

Symfony 7.x internals

Drupal 10 is built on Symfony 6.4, which reaches end of security fixes in November 2027. Drupal 11 moves to Symfony 7.x. Custom code or contributed modules that relied on Symfony 6.4 internals rather than the Drupal API layer — particularly in the HttpKernel, EventDispatcher, and Form components where significant interface changes occurred — will need attention during the upgrade. The Drupal 11 upgrade is the correct time to fix these; they will not be automatically carried forward.

The Three Real Options for Drupal 10 Site Owners

Option 1: Upgrade to Drupal 11 now

Best for: Teams committed to staying on Drupal with a site that's in active use.

This is the default, lowest-risk path. Get to Drupal 11.3 or later before December 9. Once there, Drupal 11 is supported until November 2028 (based on Drupal's major version support policy of approximately two years post-release, with Drupal 11.0 released November 2024 and Drupal 12 EOL-ing Drupal 11 upon its successor's release — verify the precise date at drupal.org/about/core/policies). Upgrading to Drupal 12 from 11.3+ is a routine major version step, not a crisis.

Steps:

1. Update to Drupal 10.6.x if you're on an older minor (prerequisite for Drupal 11)
2. Install Upgrade Status and run it against your full codebase — treat the output as your project scope, but know it is a minimum scope, not a complete one
3. Run Drupal Rector against all custom modules and themes — run in dry-run mode first, review every diff before committing
4. Triage every contributed module: run composer outdated drupal/* to find Drupal 11-ready releases, then update, replace, port, or drop each dependency
5. Update composer.json to require drupal/core-recommended:^11.3 and run composer update
6. Run drush updatedb and drush cache:rebuild
7. Test thoroughly on staging — forms, integrations, cron jobs, search indexing, caching layers — before deploying to production with a maintenance window

Target 11.4, not just 11.3. Drupal 11.4 is the current stable feature release, the recommended target for new site development, and it provides security support through approximately June 2027. That's a better place to pause, stabilize, and decide how aggressive you want to be with Drupal 12. (drupal.org)

Run the readiness scan twice: Use Upgrade Status on Drupal 10 for Drupal 11 readiness, then run it again after you land on Drupal 11 for Drupal 12 readiness. That is how Drupal's tooling is designed to be used. (drupal.org)

The trade-off: You commit to the continuous upgrade cycle. You'll spend engineering cycles now on the Drupal 11 upgrade, and again in 2027 for Drupal 12.

Option 2: Upgrade to Drupal 11, then Drupal 12

Best for: Teams that want the latest major version but recognize the stepping-stone requirement.

The timeline is tight. Drupal 12.0.0 ships the week of December 7, 2026 — and as of October 2026, it is still in beta. Drupal's own release notes say beta releases are for compatibility testing and are not intended for production. (drupal.org)

A realistic plan: reach Drupal 11.3+ before December 9, run on Drupal 11.4 or 11.5 through Q1 2027, then move to Drupal 12.1 or 12.2 once the release stabilizes and contributed modules catch up. After a major Drupal release, the contributed module ecosystem has historically taken a few months to reach broad compatibility, though Drupal publishes no figure for this — Drupal 9's module ecosystem didn't reach ~80% top-100 module compatibility until roughly 3 months post-release.

Don't treat Drupal 12 as the December deadline — treat Drupal 11.3+ as the December deadline, and Drupal 12 as a Q1/Q2 2027 project.

Waiting for Drupal 12 as your first move is a timing trap. You still have to go through Drupal 11.3 anyway — there's no shortcut — and you'd be doing both the 10→11 and the 11→12 upgrades in the same compressed window, while also managing the nine modules and three themes moving out of core and the PHP 8.5 runtime requirement. For an enterprise application, executing two major version upgrades and deploying them to production in a matter of days is operationally reckless.

Wait for Drupal 12 as your immediate target only if all four of these are true:

• You are already on 10.6.x and the codebase is effectively 11.4-ready
• Your hosting, CI, and QA environments are ready for PHP 8.5
• You are comfortable testing against beta or RC builds now and upgrading close to or just after GA
• You have audited every core extension and theme that moves out of core in Drupal 12 and installed contributed replacements

Option 3: Replatform to a different CMS

Note: ClonePartner provides data migration services for replatforming projects. The analysis below reflects our genuine assessment of when replatforming is and isn't the right call.

Best for: Teams where the site's complexity no longer justifies Drupal, or where a major redesign is already planned.

Drupal 10 EOL is a legitimate forcing function to evaluate whether Drupal is still the right platform. Replatform when the real problem is platform fit — editorial model, operating model, integration direction, or the long-term cost of custom Drupal code — not just because Drupal 10 is aging.

Replatforming is usually the better call when one or more of these are true:

• The custom module and theme portfolio has become a permanent maintenance tax with no internal team to sustain it
• The site behaves more like a marketing CMS than a structured Drupal application (taxonomy-light, low-complexity content model, primarily editorial workflows)
• The business wants vendor-managed upgrades and a smaller PHP operations footprint
• Several parallel site programs make a common headless or SaaS destination more valuable than another Drupal major update

Keep the timelines completely separate. A Drupal 10→11 upgrade is application modernization inside the same CMS, typically 2–16 weeks depending on complexity. A move from Drupal to another platform is a full replatform program — content-model mapping, URL redirect chains, template rebuilding, integration rewiring, SEO preservation work, and acceptance testing — typically 3–9 months for production sites. Do not let the December 9 date compress a replatform into an upgrade timeline. The two projects are not interchangeable.

The data migration layer is what most teams underestimate. Drupal stores content in a normalized relational schema: nodes split across node and node_field_data tables, field values in individual node__field_* and node_revision__field_* tables for every field on every content type, taxonomy terms in taxonomy_term_field_data with hierarchical parent relationships in taxonomy_term_hierarchy, Paragraph entities in their own typed tables, media entities in media and media__field_* tables, path aliases in path_alias, and user data spread across users, users_field_data, and profile field tables. This schema doesn't map 1:1 to any other CMS's data model. A scripted, API-driven extraction — pulling content through Drupal's JSON:API or REST endpoints, or directly from the database with field mapping — preserves structure and relationships far better than CSV exports or manual content entry.

Common exit destinations include headless CMSes (Contentful, Sanity, Strapi) for teams moving to a decoupled front-end architecture, and lighter monolithic CMSes (WordPress, Craft CMS) for marketing teams that need simpler editorial workflows without Drupal's structured-data overhead.

Extended security support (the stopgap)

If you cannot upgrade or replatform by December 2026, commercial extended support may be available. Tag1 Consulting has historically offered extended security coverage for EOL Drupal versions (they maintained extended support for Drupal 7 post-EOL). This is strictly a temporary measure — it buys time but does not fix the underlying technical debt. Your PHP version will eventually reach its own EOL, and the Symfony 6.4 EOL in November 2027 compounds the risk. Use this path only if a migration or upgrade is actively underway but delayed.

A Phased Timeline for the Upgrade

Here's a realistic phased plan. If you haven't started, the window is narrow but workable for sites with moderate complexity.

Now (immediately):

• Verify your exact Drupal 10 minor version. If you're below 10.6, update to 10.6.x first
• Install Upgrade Status and run a full scan — this output is your minimum project scope
• Run composer outdated drupal/* to see which contrib modules have Drupal 11-ready releases

Weeks 1–2:

• Run Drupal Rector against all custom modules and themes. Review and commit the diffs. Manually audit for patterns Rector cannot catch (see the blockers section above)
• Update every contrib module that has a Drupal 11-compatible release
• Triage modules that don't: replace, port, or drop

Weeks 3–5:

• Perform the core upgrade to Drupal 11.3+ on a staging environment
• Run full regression testing — forms, integrations, cron jobs, search indexing, caching layers
• Verify PHP 8.3+ compatibility across the stack
• Run Upgrade Status again on Drupal 11 for Drupal 12 readiness — start this scan early so you know what the next move costs

Weeks 6–8:

• Deploy to production with a maintenance window
• Monitor logs and error reporting for 48–72 hours post-deploy
• Document any remaining Drupal 12 readiness gaps identified in the second Upgrade Status scan

If you cannot complete the upgrade before December 9, put compensating controls in place: a web application firewall (WAF), heightened monitoring, and a documented remediation plan to finish in January. Running Drupal 10.6 past EOL for a few weeks with controls is safer than rushing a bad deploy. This is a risk-management decision that requires documented approval from your security and compliance stakeholders.

What Happens After December 9 If You Do Nothing?

Your Drupal 10 site doesn't stop working. But the risk profile changes immediately:

• Unpatched vulnerabilities accumulate. Every Drupal security advisory published after December 9 that affects Drupal 10 core or its dependencies stays open on your site indefinitely.
• Contributed modules stop getting Drupal 10 branches. Module maintainers drop support for EOL versions — many already have for earlier minor versions.
• Hosting pressure builds. Managed hosts like Acquia and Pantheon will eventually deprecate Drupal 10 environments. When they do, the upgrade becomes an emergency with a deadline you didn't choose and no flexibility.
• Compliance failures. SOC 2 Type II auditors will flag it as a finding; PCI-DSS Requirement 6.3.3 treats it as a violation of the vulnerability management mandate; FedRAMP/StateRAMP ATOs can be suspended.
• Symfony 6.4 EOL in November 2027 compounds the exposure — your underlying framework loses security coverage less than a year after Drupal 10's EOL.

The risk isn't downtime. It's silent exposure that compounds every month you wait.

Making the Decision

For the majority of Drupal 10 sites, upgrading to Drupal 11.3+ before December 9 is the right call. It's the lowest-risk path, it buys approximately two years of additional support, and it leaves the door open to Drupal 12 whenever your team is ready.

Replatforming is valid, but it's a different project with a different timeline. Don't let the December 9 EOL date be the sole reason you leave Drupal — and don't let it be the reason you stay on an unsupported version while planning a long replatform.

If Drupal remains the right fit, allocate engineering budget now to reach Drupal 11. Update your server infrastructure, fix your deprecations, and secure your platform. If the continuous upgrade cycle has become a liability, use the remaining months to evaluate alternatives deliberately — but scope the data migration and application rebuild as separate workstreams with separate timelines and separate budgets.