Approximate reading time: 8 minutes. Last updated September 21, 2026.
One of our teams is a few years into a five-year engagement helping the U.S. Courts move close to 300 public-facing websites off Drupal 7 — the main federal judiciary sites, the individual circuit and district court sites, the internal intranet, all of it. That project exists because Drupal 7 reached end of life in January 2025, and an agency running dozens of sites on it, or in the courts' case hundreds, does not get to upgrade over a long weekend. The assessment contract was awarded in 2022. The execution work is still going in 2026.
We bring that up because Drupal 12 is scheduled to land the week of December 7, 2026, and the conversations we are already having with agency partners have a familiar shape: we know it's coming, what do we actually need to do.
As an agency that specializes in federal agency CMS migrations, we know that the technical upgrade is rarely the part that eats the calendar. The code work takes weeks, sometimes months, but what takes quarters or even years is everything wrapped around it — the funding action, security authorization paperwork, accessibility re-test, and sign-off from stakeholders that all have opinions about the homepage.
Here we'll outline what is changing, the deadlines, and what a contracting officer or program manager should be doing between now and the spring.
Two dates, and only one of them is a cliff
Drupal 12.0.0 releases the week of December 7, 2026. Alpha1 came out September 2, beta1 followed the week of September 14, and a release candidate is due the week of November 9. The version is real and close.
Drupal 10 reaches end of life on December 9, 2026 — two days after Drupal 12 ships. After that date, no new Drupal 10 releases will be made, including security releases. That is the cliff.
The date that is not a cliff is Drupal 11. Drupal 11.5.0 ships the same week as Drupal 12 and Drupal 11 keeps receiving support. If your site is on a current Drupal 11, Drupal 12 is a planning item, not an emergency. What does age out in the December window is security support for Drupal 11.3.x, the same way Drupal 11.2.x aged out in June.
So the population that needs to move with urgency is narrower than the headline suggests, and it is worth knowing which group you are in before anyone writes a requirements document:
| If your site is on | Your situation | What has to happen |
|---|---|---|
| Drupal 7 | Unsupported since January 2025 | Closer to a rebuild than an upgrade. Budget accordingly. |
| Drupal 8 or 9 | Long unsupported | Migrate to Drupal 11 now. Drupal 12 is not the near-term question. |
| Drupal 10.x | Loses all support December 9, 2026 | Get to Drupal 11 before December. This is the group with a real deadline. |
| Drupal 11.0–11.3 | Supported, but 11.3 security support ends in the December window | Move to 11.4 or 11.5. Routine minor updates. |
| Drupal 11.4 or later | Comfortable | You are already on the Drupal 12 upgrade path. Plan it into FY27. |
The upgrade path trap
This is the detail that changes agency planning more than any feature in the release, and it is the one most likely to surprise a program manager who has budgeted for "one upgrade."
You cannot go from Drupal 10 to Drupal 12. Per the Drupal 12.0.0-alpha1 release notes, sites running 11.3.x or earlier must first update to 11.4.0 or later before updating to Drupal 12, and the recommendation is to be on 11.5.0 or higher before making the jump.
For an agency on Drupal 10 today, that is two moves, not one: get to Drupal 11.4+ first, then evaluate Drupal 12 on your own schedule. The first move is the one with a support deadline attached. The second one can wait until the contributed modules your site depends on have caught up, which historically takes a few months after a major release.
Anyone who tells you they can take a Drupal 10 site straight to Drupal 12 is describing a rebuild, or has not read the release notes.
The technical changes, which are the easy part
Platform requirements go up. Drupal 12 requires PHP 8.5, MySQL 8.0, MariaDB 10.11, or PostgreSQL 19, and SQLite 3.45 with the json1 extension. Two things follow from that for a federal site. First, PHP 8.5 is recent enough that your hosting platform has to support it before you can move, so if you are on Acquia Cloud, Pantheon, cloud.gov, or an agency-managed environment, that availability is a dependency you do not control and should confirm in writing now. Second, a database version bump on an authorized system is its own change-control conversation, separate from the CMS.
Password hashing moves to Argon2id. Drupal 12 defaults to Argon2id instead of bcrypt, with bcrypt still available if your environment cannot support it. Argon2id is memory-hard, which makes it meaningfully more expensive to attack with GPU clusters. Existing password hashes convert as users log in, which means dormant accounts keep their old hashes until someone signs in — worth knowing if you have an assessor who asks.
Seven modules and a theme leave core. Ban, Contact, Field Layout, History, Settings Tray, Shortcut, and Telephone move out to contributed projects, along with the Stable 9 theme. Sites have to either uninstall them or install the contributed versions before upgrading.
That list deserves a closer read than it usually gets, because three of those are load-bearing on government sites:
- Contact. We have seen more than one agency site quietly running an official public comment form, a FOIA-adjacent intake, or a "contact the program office" form on core Contact. "The module isn't there by default anymore" is exactly the kind of thing nobody notices until launch day.
- Telephone. This is a field type. If your content model uses it anywhere — office directories, regional contacts, press office listings — you need the contributed module in place before the upgrade or those fields break.
- Settings Tray and Shortcut. Neither is public-facing, both are things your content editors use every day. Removing them without a replacement is how you generate a wave of help desk tickets in week one and lose the goodwill you need for the rest of the project.
The deprecation cleanup is largely automated. Run the Upgrade Status module against your custom code to get an inventory, and let Drupal Rector handle the mechanical fixes. Drupal's Project Update Bot now automatically covers more than 80% of the deprecated API uses introduced in the release. That is time you would rather spend on the remaining 20%, where custom integrations and the one-off modules a previous vendor left behind tend to live.
Where the time actually goes on a federal site
Government sites carry weight that a marketing site does not, and that weight is exactly why "just start earlier" is easier said than done.
A major version bump on an authorized system is a change that has to be assessed. Depending on your agency's posture and your system's categorization, that is a security impact analysis and an update to your continuous monitoring artifacts at minimum, and a longer conversation with your authorizing official if the platform, database, or hosting boundary changes along with it. None of that is Drupal work. All of it sits on the critical path, and it does not compress just because the code is ready.
The same is true of accessibility. When we worked on the ED.gov redesign — which started life as a Challenge.gov design competition in 2020, years before the actual Drupal 7-to-10 migration happened — a substantial share of the timeline was Section 508 conformance and building a design system multiple teams across the Department could maintain after we left. A major upgrade touches themes, forms, and admin interfaces, which means it touches the exact surfaces a 508 review looks at. Our advice is to treat the version bump as the forcing function for the accessibility audit you were due for anyway, rather than scheduling them as two separate efforts that each need their own approval.
And then there is the part that is nobody's favorite: getting a dozen program offices to agree on anything. That has never been a technical problem and it is not going to start being one in December.
The procurement read, which is the part most posts skip
If you are the contracting officer or program manager who owns this, the useful questions are not about PHP versions.
Funding timing. Drupal 12 arrives in the first quarter of FY2027, and Drupal 10's support cliff falls in that same window. FY2026 funds expire September 30. If you have expiring money and a Drupal 10 site, a scoped current-state assessment is a small, fast-to-award action that turns an unknown into a defensible requirements document — and it is far easier to get a modification or task order through in the spring when you can attach findings to it.
Modification or new competition. Most agencies we work with can handle the Drupal 11 step as in-scope O&M under an existing vehicle, since it is a supported-version update rather than new capability. A Drupal 7 or 8 site is a different animal and usually needs its own action. The distinction is worth settling with your CO early, because getting it wrong is what turns a three-month effort into a nine-month one.
What to ask your current vendor in writing this quarter. Four questions, and the answers should be specific:
- What exact Drupal version and PHP version is the site running today, in production?
- What does Upgrade Status report against our custom code and contributed modules, and how many of those findings does Drupal Rector resolve automatically?
- Do we use Contact, Telephone, Settings Tray, Shortcut, Ban, History, or Field Layout anywhere, and what is the replacement plan for each?
- Does our hosting platform support PHP 8.5 and the required database versions, and on what date?
A vendor who can answer all four in a week is on top of it. A vendor who needs a month to find out is telling you something useful, too.
Independent Government Cost Estimate (IGCE). Build the estimate around the whole path. The realistic line items are assessment, the 11.4+ update, contributed module remediation, accessibility testing and remediation, security documentation updates, content freeze and editor retraining, and only then the Drupal 12 evaluation. Teams that estimate only the middle item are the ones who come back for more money in the summer.
What we would do in the next 90 days
Run the inventory. Confirm your exact version, your PHP version, and your hosting platform's roadmap. Run Upgrade Status against custom code while you have runway rather than under pressure. Audit for the seven departing modules. Get whoever owns your ATO and your 508 sign-off into the conversation at the start of the process instead of the end, because that is usually the actual critical path. And if you are on Drupal 10, schedule the move to Drupal 11.4 or later for a date with real slack in front of December 9.
Drupal is not a platform federal agencies are walking away from. By our own scan of the .gov space, it runs sites at 13 of the 15 cabinet-level departments. But that installed base was built at different times, by different vendors, under different contracts, which is precisely why version deadlines land unevenly across an agency's portfolio. Some offices will have a calm year. Some will end up doing emergency modernization under real time pressure. We have done both kinds of engagement. The calm ones are better for everyone, including us.
We keep our own house in order for the same reason we tell clients to plan early — agileana.com runs on Drupal 11 today, and we would rather take a version bump on our own schedule than an emergency one.
Find out where you actually stand
If your agency is trying to work out whether you are closer to "comfortable runway" or closer to "the U.S. Courts in 2022," that is a short conversation and a scoped assessment.
Reach out to Agileana for a straight read on your site: what version you are really on, what is riding on modules that are about to leave core, what your hosting platform will and will not support, and how much runway you have before December 9. We would rather have that conversation with you this fall than in the middle of an emergency contract next winter.
Agileana is a Service-Disabled Veteran-Owned Small Business specializing in Drupal for federal agencies and mission-driven organizations, holding GSA MAS, NASA SEWP VI, and agency-specific BPAs with the U.S. Courts, NARA, and DOT.