Drupal 10 EOL is December 9, 2026. What happens if you wait?

What does Drupal 10 end of life actually mean?

End of life does not mean a Drupal 10 website switches off at midnight. It means the safety net changes. Drupal's official release schedule says Drupal 10 reaches end of life on December 9, 2026 and that no new Drupal 10 releases will be made after that date.

A site may continue to render, accept forms, and publish content. But every month after EOL increases the distance between the site and the supported ecosystem around it. New vulnerabilities may not receive Drupal 10 fixes. Hosting platforms continue moving. PHP and database support windows change. Composer packages release new versions. Module maintainers shift their focus to current Drupal branches.

That is why EOL is not a single engineering ticket. It is a business-continuity decision involving security, compliance, infrastructure, release management, content operations, search visibility, and the roadmap for AI-enabled experiences.

What will the business miss—or risk—if modernization is delayed?

The visible website is only the top layer. The underlying cost appears in risk reviews, release friction, delayed campaigns, fragile integrations, and the growing effort required to make every future change.

• Security coverage becomes harder to defend. Unsupported core, abandoned dependencies, or modules outside current security coverage increase the effort needed to assess and respond to vulnerabilities.
• Compliance evidence weakens. Auditors and internal risk teams may ask why a customer-facing system is running outside its normal support lifecycle, especially where privacy, accessibility, payment, health, or public-sector obligations apply.
• Infrastructure choices narrow. Older PHP, database, operating-system, and hosting combinations become harder to maintain while cloud and managed-platform baselines keep advancing.
• Delivery becomes less predictable. Composer conflicts, deprecated APIs, custom patches, removed core extensions, and unsupported contributed modules turn routine releases into dependency negotiations.
• Performance work costs more. It is harder to improve caching, front-end payload, database behavior, and Core Web Vitals when teams must preserve fragile themes and integration workarounds.
• Marketing velocity stalls. Content and campaign teams miss modern visual building, governed components, reusable templates, and simpler landing-page operations.
• AI and discoverability programs start on weak foundations. Semantic search, governed translation, AEO, GEO, and AI-assisted workflows all depend on structured, current, permission-aware content.

The biggest financial risk is often not a single security incident. It is losing control of the timing. A planned modernization can be sequenced around releases and campaigns. A forced upgrade is usually scoped around whichever dependency, incident, or hosting deadline broke first.

Should Drupal 10 sites upgrade to Drupal 11 or wait for Drupal 12?

The practical answer is: upgrade through Drupal 11 and prepare for Drupal 12. Drupal's official upgrade guide says major versions cannot be skipped. A Drupal 10 site must become Drupal 11 compatible and move to Drupal 11 before it can move to Drupal 12.

As of August 11, 2026, Drupal 12 is scheduled for the week of December 7, 2026. That timing overlaps with Drupal 10 EOL. Waiting for the release does not eliminate the preparation work; it compresses compatibility analysis, infrastructure remediation, module decisions, testing, and release planning into a narrower and riskier window.

Infrastructure is part of the upgrade path. Drupal 11 requires PHP 8.3 or later. Drupal's announced Drupal 12 requirements include PHP 8.5, MySQL 8.0, MariaDB 10.11, PostgreSQL 18, or SQLite 3.45, depending on the database backend. The right target architecture depends on your release window, hosting platform, module estate, and appetite for a second major upgrade.

A Drupal EOL readiness assessment should cover six workstreams

A version check is useful, but it is not a migration roadmap. A decision-ready assessment should tell business and technical owners what blocks the upgrade, what can be remediated in place, what should be replaced, what should be deferred, and what value can be unlocked while the platform is already changing.

1. Platform and hosting

Check PHP, database, web server, operating system, container image, hosting service, CDN, cache, file storage, cron, queues, search, backups, disaster recovery, and parity across development, test, staging, and production.

2. Composer and dependencies

Map core constraints, direct and transitive packages, Drush, plugins, abandoned libraries, patches, lock-file health, private repositories, build commands, and whether the same artifact can be reproduced reliably across environments.

3. Contributed modules

For every project, document the supported release, Drupal 11 and Drupal 12 path, maintainership, security coverage, replacement options, patch dependencies, and a clear remove, replace, retain, or contribute decision. Compatibility alone is not enough if the module is strategically wrong or expensive to operate.

4. Custom code and themes

Scan deprecated APIs, removed core extensions, custom modules, event subscribers, plugins, Twig, themes, JavaScript behavior, front-end build tooling, accessibility, coding standards, and automated test coverage. Fix compatibility on the current site before attempting the major upgrade.

5. Security, compliance, and performance

Review security advisories, access and role models, secrets, headers, logging, backups, recovery, caching, database hotspots, Core Web Vitals, third-party scripts, privacy, accessibility, release rollback, and the evidence required by internal governance or external auditors.

6. Content and growth readiness

Evaluate content models, workflow, localization, components, structured data, SEO, AEO, GEO, search, analytics, editorial governance, and appropriate AI use cases. An EOL program should protect current operations and clarify what the platform needs to do next.

Drupal's Upgrade Status project is a strong technical input because it checks next-major requirements and scans projects for compatibility issues. But tool output still needs business interpretation. A module can be technically compatible and still be unmaintained, overly customized, or misaligned with the future content experience.

Still on Drupal 7? This is now a rescue and migration program

Drupal 7 community support ended on January 5, 2025. Drupal.org states that Drupal 7 no longer receives community security or compatibility updates, and that Drupal 7 core and contributed projects no longer receive normal releases on Drupal.org.

For an unsupported legacy site, the first goal is not to pretend the migration can happen instantly. The first goal is controlled risk reduction while the migration is planned and delivered.

• Stabilize the current site. Confirm hosting, backups, recovery, monitoring, administrative access, exposed services, and critical security controls.
• Reduce the attack and compliance surface. Remove unused modules and accounts, close abandoned features, document exceptions, and establish a vulnerability-response path.
• Inventory the migration. Map content types, fields, files, users, URL aliases, redirects, multilingual data, custom modules, integrations, SEO equity, and business-critical workflows.
• Choose the right destination. For many organizations that means modern Drupal. For others, the assessment may show that a different architecture better fits the operating model.
• Use extended support intentionally. Qualified commercial Drupal 7 extended support can buy time, but it should support a dated migration plan rather than become the permanent strategy.

Drupal CMS 2.0 turns mandatory work into marketer enablement

A core upgrade can remain a back-office technical project, or it can become the point where the business improves how digital work ships. Drupal CMS 2.0 launched in January 2026 on Drupal core 11.3 with Drupal Canvas as its default visual editing experience, a component system, site templates, recipe-based integrations, and optional AI tools.

That does not mean every enterprise Drupal site should replace its established distribution with Drupal CMS wholesale. It means the modernization program should evaluate the capabilities deliberately:

• Drupal Canvas for browser-based visual page building and governed component composition.
• Reusable templates and components so marketing teams can launch pages faster without bypassing brand, accessibility, security, and analytics controls.
• Recipes to package repeatable configuration and reduce one-off setup work.
• Optional AI assistance for appropriate page-building, content, taxonomy, alt-text, and administrative workflows, with provider, data, permission, review, and audit rules in place.

The right question is not “Can marketers build anything?” It is “Can marketers ship the right things quickly inside a system the organization can govern?”

Modern Drupal can become the governed foundation for AI, AEO, and GEO

AI enablement should not be bolted onto an unhealthy content platform. Translation, semantic or retrieval-augmented search, content generation, answer-engine optimization, and generative-engine optimization all depend on the same foundation: structured content, trusted source ownership, predictable rendering, access control, metadata parity, and an editorial process that can review what the machine produces.

• Governed translation and localization. Define which content can be machine-assisted, where human review is mandatory, how terminology is controlled, and how source and translation freshness stay aligned.
• Semantic and RAG search. Clean the corpus, permissions, taxonomy, chunking, embeddings, retrieval rules, citations, analytics, and fallback experience before adding an answer layer.
• AEO and GEO content cleanup. Align visible copy, headings, entities, structured data, internal links, author and review signals, canonicals, sitemaps, and concise answer blocks so machines can reuse facts without guessing.
• Editorial control. Put approvals, audit trails, provider choices, prompt standards, brand rules, privacy boundaries, and outcome measurement around AI-assisted work.

This is where lifecycle work becomes growth infrastructure. The same cleanup that makes Drupal easier to upgrade also makes content easier to discover, reuse, govern, and safely activate through AI.

Practical modernization stages

Why CXOntology is a strong fit for Drupal EOL and modernization

The hard part is rarely changing a version number. It is connecting platform engineering, business continuity, content operations, search visibility, and future capability without turning the upgrade into an open-ended transformation program.

• Assessment before prescription. We baseline the platform, dependencies, custom code, security, performance, operations, discovery, and AI readiness before setting scope or sequencing.
• One accountable delivery pod. Drupal engineering, DevOps, QA, performance, security, content, analytics, and AI work against one roadmap with a named lead and visible decisions.
• Lifecycle plus growth. We treat the required upgrade as an opportunity to improve marketer velocity, components, Core Web Vitals, structured content, SEO, AEO, GEO, and AI enablement.
• Modernize, then keep it healthy. The outcome is not only a successful cutover. It is an operable platform with monitoring, release discipline, security updates, documentation, and a forward upgrade runway.

You get a blocker inventory, remediation plan, target architecture, release strategy, evidence from upgrade rehearsals, and a prioritized modernization backlog, not a generic recommendation to “upgrade Drupal.”