Your website can be running Drupal 11 and still be approaching the end of security support for its particular release. A change announced this week makes that distinction more important for anyone responsible for keeping a Drupal site maintained.The transition affects releases differently. These are the dates to use when reviewing your current position:Those are reasonable questions to settle before the next release cycle. They help both the client and the development team estimate the work honestly.That is also a good reason to look at the maintenance agreement. Does it make room for moving between minor releases, or does everyone assume that work will be discussed later?
What the shorter window means
The Drupal Security Team cites the growing volume of security reports associated with AI tools and the pressure that creates on its available resources. Maintaining fixes across older branches adds work. Drupal estimates the change will reduce core security backport work by 30%, while also improving alignment with Symfony’s release schedule. Read the Security Team’s explanation (opens in a new tab).“Security updates included” can leave important questions unanswered. Does the agreement include the minor-version update needed to keep receiving those fixes? Who handles a module compatibility problem? Who tests the editorial workflow and authorizes deployment?Before closing the next maintenance ticket, ask for the deployed version and its next support deadline. Put that date where the people approving the work will see it. It is a small change to the handover, but it gives everyone a clearer starting point for the next update.
Why Drupal is making this change
Choose the checks around what your site actually does. An online application portal and a small publishing site will need different attention. Include the people who use the administrative interface; they may notice a broken editorial step that a homepage review would miss.The useful maintenance conversation starts with a few specifics: the deployed version, its support deadline, the intended target release, and anything preventing the move. Ask for those details in a short written plan that the website owner and development team can both understand.
The dates worth putting in your plan
I’d also ask the team to record blockers as soon as they appear. If a contributed module, custom integration, or dependency constraint holds up the target release, write down the next action and give it an owner. Discovering that problem early gives you a chance to resolve it without an approaching support deadline deciding the schedule for you. Read our guide to finding and fixing Composer conflicts.
| Your Drupal release | Security support deadline | Planning consideration |
|---|---|---|
| Drupal 10 | December 9, 2026 | Confirm the major-upgrade path and who owns delivery. |
| Drupal 11.3 | December 2026 | Arrange the move to a supported minor release. |
| Drupal 11.4 | April 21, 2027 | Reserve testing and deployment time ahead of that date. |
For organizations with several Drupal sites, keep one shared record of versions and deadlines. Add the person responsible for each site and the next planned maintenance date. That makes it easier to spot a site that has fallen out of the normal update routine.In its November 2 announcement, Drupal said ordinary minor releases will receive eight months of security coverage beginning in 2027, down from twelve. Major versions will continue to receive at least four years of support. Read Drupal’s security support announcement (opens in a new tab).That puts a practical responsibility on the people maintaining sites: leave enough room to test and move forward. A shorter support window makes an unresolved upgrade blocker harder to carry from one planning cycle into the next.
Make the next update easier to approve
Drupal’s update guidance recommends reviewing release notes, checking module and theme compatibility, backing up the site, applying database updates, and checking the result after deployment. These steps need time alongside the code update itself. Read Drupal’s guide to updating core with Composer (opens in a new tab).The official core release schedule also lists Drupal 12.0 and 11.5 for the week of December 7, 2026. Those are planned releases as of this article’s review date. See Drupal’s core release schedule (opens in a new tab).Then give the testing work a place in the calendar. A staging environment is useful only when someone has time to use it. Before the update, agree on the workflows that must keep working: signing in, publishing and approving content, submitting a form, completing a payment, or passing information to another system.Drupal 11 remains supported until December 2028, provided sites move onto supported minor releases. That gives existing Drupal 11 sites room to plan their next major upgrade around compatibility and business needs.The distinction can get lost in a budget meeting. A team may have recently paid for a major upgrade and reasonably expect the site to remain supported for years. Keeping it supported still involves moving through the releases within that major version.
Read the maintenance agreement closely
For planning purposes, think of the eight months as the release’s lifetime. It is not an allowance to wait eight months before installing a security fix. Urgent advisories still need prompt assessment and action.For a website owner, the immediate task is to find out which release the site uses and put its support deadline on the calendar. “We’re on Drupal 11” is a starting point. The next number matters too.If your Drupal maintenance plan needs a review, talk to Dynamosys about your current release, dependencies, and upgrade schedule. We can start with the site you have and the work needed to keep it supported.For teams still on Drupal 10, the December deadline deserves attention now. Waiting for a future major release to become available adds uncertainty to an already short schedule.A useful budget discussion separates routine patching, planned minor-version updates, and larger major-version upgrades. Each needs an owner and an agreed way to approve the work. Reserve capacity for urgent security fixes even when a planned update is already underway.A minor version is a release such as Drupal 11.3 or 11.4. Under the new policy, an ordinary minor release gets six months of bug fixes, followed by two months of security-only coverage. The final minor release within a major version is an exception: it keeps six months of each.
