What End of Life Actually Means
End of life does not mean your site stops working. On December 10, 2026, your Drupal 10 website will load exactly the same as it did the day before. Members will still log in. Content will still publish. Forms will still submit. Nothing breaks overnight. What changes is what happens behind the scenes: the Drupal security team stops issuing patches for Drupal 10. No more security advisories. No more bug fixes. No more updates to core modules.
This matters because web security is not a one-time achievement. It is ongoing maintenance. New vulnerabilities are discovered in PHP libraries, in database layers, in authentication modules. When Drupal 10 is supported, the security team patches those vulnerabilities within days. After end of life, they do not. Your site stays frozen in its last patched state while the threat landscape keeps moving.
For associations handling member data — names, emails, payment information, committee rosters, certification records — this is not a theoretical risk. Unpatched CMS platforms are one of the most common entry points for data breaches. An association running iMIS or Nimble AMS integration through a Drupal site that has not been patched in six months is carrying real exposure.
Why December 2026 and Not Later
The end-of-life date is tied to Drupal's dependency on Symfony. Drupal 10 runs on Symfony 6.4 (a long-term support release). Drupal 11, released in August 2024, moved to Symfony 7. The Drupal project has committed to a two-year major release cycle, and with Drupal 12 planned for mid-2026, Drupal 10 reaches end of life in the December 2026 minor release window. The December 9, 2026 date is now official policy — it is not going to shift.
Symfony 6.4 LTS support continues through November 2027, so the underlying framework does not become a security risk immediately. But the Drupal-specific security layer — core patches, module updates, and security advisories — ends on that December date regardless of Symfony's timeline.
The Timeline Is Already Tight
December 2026 is roughly seven months away. Association website projects — the kind that involve AMS integration, member portals, event registration workflows, and content migration — take six to twelve months from scoping to launch. Factor in the time for internal alignment (board approval, budget cycle, vendor selection), and you are looking at a timeline that may already extend past the deadline.
If your organization has not started planning, you are behind. If you started planning in early 2026, you are on pace but cannot afford delays. If you are reading this in Q3 or Q4 2026, you are likely launching after end of life — which means running an unpatched site during your busiest period. Annual conference registration, membership renewal season, legislative advocacy campaigns — whatever drives your highest traffic and most sensitive transactions will be running on expired infrastructure.
The practical planning window is now. Not next quarter. Now.
What the Drupal 10 to 11 Upgrade Involves
The good news: Drupal 10 to 11 is not a rebuild. Unlike the Drupal 7 to 8 migration — which was effectively a complete rewrite — the Drupal 10 to 11 path is a version upgrade. The underlying architecture (Symfony framework, Twig templating, configuration management) remains consistent. Your custom themes, contributed modules, and content structure carry forward.
The bad news: not a rebuild does not mean press a button. There are real technical steps involved, and some of them will surface problems you did not know you had.
PHP version requirements: Drupal 11 requires PHP 8.3 or higher. Many association hosting environments are still running PHP 8.1 or 8.2. Your hosting provider may need to upgrade, and that upgrade may affect other applications sharing the same server. If your hosting is managed (Pantheon, Acquia, Platform.sh), this is typically handled for you. If you are on shared or self-managed hosting, this is a separate project.
Deprecated API removal: Drupal 11 removes APIs and functions that were deprecated in Drupal 10. If your custom modules or theme use deprecated functions, they will break on Drupal 11 — not with a warning, but with a fatal error. The Upgrade Status module (drupal.org/project/upgrade_status) scans your codebase and identifies exactly what needs to change. Run it now, not two months before your deadline.
Contributed module compatibility: Every contributed module your site uses needs a Drupal 11-compatible release. Most major modules (Webform, Paragraphs, Pathauto, Metatag, Token) already have Drupal 11 releases. But niche modules — especially AMS integration modules, SAML authentication modules, or custom API connectors — may lag. Check compatibility now. If a critical module does not have a Drupal 11 release and the maintainer is inactive, you are looking at a fork or a replacement, which adds scope and cost.
CKEditor upgrade path removal: CKEditor 4 was already removed from Drupal core in Drupal 10. However, Drupal 10 still included an automated upgrade path to migrate CKEditor 4 configurations to CKEditor 5. Drupal 11 removes that upgrade path entirely. If your site still has CKEditor 4 artifacts in its configuration (possible if you upgraded from Drupal 9 and did not fully complete the CKEditor migration), you need to finish that migration on Drupal 10 before upgrading to 11.
Symfony 7 adoption: Drupal 11 moves from Symfony 6.4 to Symfony 7. For most sites, this is invisible — the Drupal API abstracts the underlying framework. But custom modules that interact directly with Symfony components (HTTP kernel, event dispatcher, dependency injection) may need adjustment. This is especially relevant for associations with custom middleware handling AMS API calls, where the HTTP client layer has changed.
AMS Integration Complexity
For associations running AMS integrations — iMIS, Fonteva, Nimble AMS, MemberSuite — the upgrade adds a layer of risk that generic Drupal upgrade guides do not address. Your AMS integration module connects your website to member data: authentication, profile sync, event registration, renewal workflows. That module has to work on Drupal 11.
If your integration uses a vendor-supported module (like the official iMIS Drupal integration), contact the vendor now and ask for their Drupal 11 compatibility status. Get it in writing. If they do not have a compatible release yet, that is a planning risk you need to account for — you may need to build or commission a custom integration layer.
If your integration is custom-built (a common scenario for associations that outgrew their vendor out-of-the-box connector), you need a developer to audit the codebase against Drupal 11 API changes. Custom integrations built on Drupal 10 deprecated APIs will fail. Custom integrations that rely on specific Symfony 6 behaviors may need adjustment for Symfony 7.
Test the integration in a staging environment before upgrading production. This is not optional. Member authentication, profile sync, and event registration all need to work on Drupal 11 before you switch. A broken integration on production means members cannot log in, renewal workflows fail silently, and your events team loses registration data.
What Happens If You Do Nothing
Some associations will do nothing. They will run Drupal 10 past end of life. The site will still work. Members will still log in. And for a while, nothing visibly bad will happen.
Here is what happens eventually:
- Security vulnerabilities accumulate. New PHP vulnerabilities, new SQL injection vectors, new authentication bypass techniques — none of them get patched.
- Hosting providers start dropping support. Pantheon and Acquia will eventually stop supporting Drupal 10 environments. When they do, you are forced into an emergency migration under time pressure.
- Contributed modules stop releasing Drupal 10 updates. Module maintainers focus on Drupal 11 and 12. Your modules fall behind. Security issues in contributed modules go unpatched.
- Cyber insurance and compliance audits flag the risk. If your association carries cyber liability insurance, your insurer may ask about your CMS version. Running an end-of-life CMS is a material risk that can affect coverage.
- The upgrade gets harder over time. The longer you wait past December 2026, the more deprecated code accumulates in your codebase, and the more expensive the eventual upgrade becomes.
Doing nothing is a decision. It is just not a free one.
Budgeting for the Upgrade
The cost of a Drupal 10 to 11 upgrade depends entirely on complexity. A straightforward site — standard hosting, no custom modules, no AMS integration — might cost $5,000 to $15,000 for a qualified Drupal developer or agency to handle. A complex site with custom integration layers, custom modules, multiple contributed modules requiring patches, and residual CKEditor 4 configurations could run $25,000 to $60,000 or more.
Those numbers feel steep until you compare them to the alternative. An emergency migration — forced by a hosting provider dropping Drupal 10 support or a security breach exploiting an unpatched vulnerability — will cost more. Emergency projects run 30 to 50 percent higher than planned ones because you lose the ability to negotiate, to stage work in phases, and to test thoroughly.
Budget timing matters for associations. Most associations operate on fiscal-year budgets approved by a board six to twelve months in advance. If the Drupal 11 upgrade is not already in your current budget, you may need to request an emergency allocation or defer to the next fiscal year — which may put you past the December 2026 deadline. That means the conversation needs to happen at your next board meeting, framed as risk mitigation: the cost of upgrading versus the cost of a data breach, an emergency migration, or losing cyber insurance coverage.
When This Is Easier Than You Think
Not every Drupal 10 site needs a six-month upgrade project. If your site is relatively straightforward — a few hundred pages of content, a handful of contributed modules, standard theming, no custom AMS integration — the Drupal 10 to 11 upgrade can be completed in four to six weeks by an experienced team. The Upgrade Status module will tell you quickly whether your site falls into the straightforward category or the complex one.
Associations with simple sites, standard hosting (Pantheon or Acquia), and no custom integration work often find that the upgrade is more of a maintenance task than a capital project. Run the Upgrade Status scan, check your module compatibility, and you may find that the path forward is shorter than expected.
What You Walk Away With
If your association site is running Drupal 10, we can run a compatibility assessment — Upgrade Status scan, contributed module audit, AMS integration risk review, and PHP environment check. You will get a report that tells you exactly what needs to change, how long the upgrade will take, and what it will cost. With December 2026 approaching, the window for a planned, orderly upgrade is closing. That assessment is the foundation for a budget request your board can act on now — not next quarter.