Your executive director asks what the website line item is for next year, and the honest answer is that you do not entirely know. The site was built on Drupal, it works, and the last real conversation about it was the launch. Then somebody forwards a security bulletin with a date in it, and the question stops being about next year's budget and becomes a question about the next eleven weeks.
Drupal 10 reaches end of life on December 9, 2026. After that date it receives no security coverage from the Drupal Security Team. This is the hardest deadline on any association website calendar this quarter, and unlike most compliance dates it is not subject to interpretation, extension or legal challenge.
One note on sourcing. The date is published on Drupal.org's core release schedule and has been fixed for a long time. Nothing below is a prediction.
The Week It Happens Is Unusually Crowded
Four things land inside four days, which is worth knowing before you plan any work around them.
- Week of December 7, Drupal 12.0.0 and Drupal 11.5.0 are both scheduled to ship.
- December 9, Drupal 10 end of life. No further security releases.
- December 9, WordPress 7.2 is targeted for release the same day, which matters to any organization running both.
The practical consequence is a scheduling one. That is the wrong week to deploy anything unrelated, and the wrong week to have your only Drupal developer on holiday. If you do nothing else with this post, put a change freeze on the week of December 7.
What End of Life Actually Means
Your site does not stop working on December 9. It will run exactly as it did on the 8th. Saying otherwise is the kind of manufactured urgency that makes people stop listening to security advice.
What stops is the flow of fixes. When a vulnerability is found in Drupal core after that date, there will be no patch for 10. The exposure does not arrive on the deadline. It accumulates afterwards, and it accumulates faster than most people expect. Patchstack's analysis of 2025 found that roughly half of high-impact vulnerabilities were exploited within twenty-four hours of disclosure.
For an association there is a second-order problem. If your site takes dues, event registrations or donations, an unsupported content management system is handling cardholder data. That is a conversation with your payment processor and potentially your insurer, not just a technical preference. It is also the sentence that tends to move a board when a version number does not.
The Decision Tree
There are three real options and one that only looks like an option. Which one applies depends almost entirely on your contributed module list, not on the size of your site.
- Drupal 10 to Drupal 11.5. For most associations this is the answer. Drupal 11 is an incremental step from 10 rather than the rebuild that 7-to-8 was: your content structure, your custom theme and most contributed modules carry forward. The work is usually measured in weeks, and the bulk of it is auditing modules rather than rewriting anything.
- Drupal 10 to Drupal 12. Newer, but it requires PHP 8.5, which means your hosting environment has to be ready first. Twelve also ships the same week Drupal 10 dies, meaning contributed module compatibility will be thinly tested at exactly the moment you would be relying on it.
- Replatform entirely. Sometimes right, if the site is genuinely at the end of its useful life, if the original build was poor, or if Drupal was the wrong fit to begin with. This is a six-to-twelve month project for an association site with AMS integration, so if you are choosing it now, you are choosing to spend some months on an unsupported version. That can be an acceptable, deliberate trade.
- Do nothing and hope. Not a strategy, but worth naming because it is what usually happens. The cost of it is not visible until the day it is very visible.
Our Honest Recommendation
Plan for 11.5, not 12. Drupal 12 has already moved on the schedule more than once, and being an early adopter of a major version is a choice that suits software companies more than it suits associations. Eleven is supported, stable, has a mature module ecosystem today, and gets you off the end-of-life branch. You can move to 12 later, from a supported position, on your own timeline.
The exception is if you are already replatforming. If the budget is approved and the project starts in January anyway, do not spend money on an interim 11.5 migration first. Mitigate the risk for the gap instead, tighten access, reduce the attack surface, and make sure somebody is watching advisories.
What to Do This Month
Three things, in order, and the first one is the only one that requires a decision.
- Confirm what you are actually running. Drupal 9 sites still exist and have been unsupported since November 2023, if that is you, this is more urgent than the post you are reading. The admin status report gives you the version in about fifteen seconds.
- Get a module compatibility list. Upgrade Status, run against your site, tells you which contributed modules already have an 11-compatible release, which have a patch, and which are abandoned. This list is the entire project scope. Everything else is negotiation.
- Put a number in the 2027 budget now. Most associations set next year's discretionary spend between September and November. A migration that is a line item in October is a project. The same migration in February is an emergency, and emergencies cost more.
What a Migration Actually Involves
The word migration does a lot of unhelpful work in vendor conversations, so it is worth being concrete about where the hours go on a Drupal 10 to 11 move.
- Module audit and remediation. Usually more than half the work. Every contributed module is either compatible already, compatible with a patch, replaceable, or abandoned. The abandoned ones are where the real decisions live, and every association site has two or three.
- Deprecated code in your custom theme and modules. Automated tooling finds most of it. If your site was built well and kept current, this part is small. If it was built once in 2019 and never touched, it is not.
- The integration layer. This is the part that is specific to associations and the part generic migration quotes tend to miss. If your site talks to iMIS, Nimble AMS, Fonteva, Impexium, Personify or Aptify, that connection has to be retested end to end, member authentication, dues payment, event registration, directory sync. Not because Drupal 11 breaks it, but because nobody finds out it broke until a member calls.
- Content and configuration verification. Comparatively cheap on a 10-to-11 move, since content structure carries forward. This is the step most often skipped and most often regretted.
The honest range. For a typical association site with one AMS integration and a moderate module list, this is weeks rather than months, and the number is driven almost entirely by that module audit. Anyone quoting you a price before they have seen your module list is quoting a guess.
Who Is Already Fine
If you are already on Drupal 11, none of this applies to you, 11.5 is a routine minor update. If you are on WordPress, the December date that matters to you is a release rather than an ending. And if your Drupal site is a small brochure site with no logins, no payments and no member data, the risk is real but modest, and waiting until Q1 is a defensible decision rather than a negligent one.
What is not defensible is not knowing which of those situations you are in.
Explore our partnership plans and see which level fits your organization.