Drupal 12.0.0-beta1 is now available for upgrade testing, and it brings a tighter platform floor and a shorter list of bundled extensions than any Drupal major version before it. For agencies maintaining Drupal sites in production, this is the moment to stop watching and start running checklists. The GA window is close enough that surprises found now are far cheaper than surprises found after launch day.
What shipped in beta 1
The headline requirement change is straightforward: Drupal 12 requires PHP 8.5 at minimum. That is a meaningful jump from the PHP 8.1 floor that Drupal 11 established, and it will catch hosting environments that have been slow to track PHP releases. Managed Drupal hosts tend to stay current, but self-managed VPS setups and some agency-maintained infrastructure are often one or two minor versions behind. Now is the time to check.
Beyond the PHP floor, the release removes a set of core extensions entirely. These are modules that shipped inside Drupal core but have either been superseded by better alternatives, absorbed into other systems, or simply not kept up with the direction the project is taking. The beta announcement flags that teams need to account for a Drupal 11 upgrade step before reaching 12, meaning you cannot jump directly from a Drupal 10 site to Drupal 12. The path is Drupal 10 to 11, verify clean, then 11 to 12.
The beta also raises the bar on the upgrade path itself. Core removals mean that any site relying on the bundled version of a now-removed extension will need a contributed module replacement, a custom module, or a content and configuration migration before the Drupal 12 upgrade can complete cleanly. That is not a switch-and-flip situation; it requires audit time and, in some cases, meaningful refactoring.
The beta period exists specifically to surface compatibility gaps in the contributed module ecosystem. Module maintainers need real-world test runs against beta builds to confirm their code works at PHP 8.5 with the new core shape. Running your site against beta 1 in a staging environment is exactly the kind of signal the community needs, and it is also the earliest warning you will get about blockers on your own stack.
Our take
We have been watching the Drupal 12 timeline closely since the project update bot posts we covered earlier this year, and beta 1 landing more or less on schedule is a good sign for project health. But the PHP 8.5 requirement is the thing that will catch agencies off guard, and we want to be direct about why.
PHP 8.5 is not yet the version most shared and semi-managed hosts are defaulting to. If you have client sites on hosting environments that do not proactively upgrade PHP runtimes, you could hit a situation where the Drupal 12 codebase is ready but the server is not. Hosting compatibility audits need to happen before you start upgrade work, not during it.
The removed core extensions are a second pressure point. Drupal has been trimming the core bundle for years, which is genuinely the right call long-term. Smaller core, better contributed ecosystem, less maintenance burden on the project. But for agencies, "removed from core" means "now a contrib dependency," which means another module to vet, another release cycle to track, and another potential compatibility gap on upgrade day. We will not know the full list of what was removed and what the replacement path looks like until we run the beta against real site configurations, which is exactly what we are doing this week on a staging copy of one of our larger Drupal installs.
The two-step upgrade path (11 first, then 12) is also worth flagging to clients now, before they assume a Drupal 12 upgrade is a single engagement. For sites still on Drupal 10, the realistic project scope is two sequential upgrades with QA cycles between them. That is not a problem, but it is a planning and budget conversation that is better to have in October 2026 than in Q1 2027 when GA is imminent.
One thing we are genuinely watching: how the Drupal AI module family handles the 12 transition. The AI initiative has been moving quickly, and version lock between AI sub-modules, contrib dependencies, and core is exactly the kind of thing that can create upgrade blockers on AI-integrated sites. If you have deployed Drupal AI on a client site, treat it as a priority audit item when you run the beta.
Practical steps for agencies right now
- Audit PHP versions across your hosting fleet. Any environment not already on PHP 8.4 needs a timeline for reaching 8.5 before Drupal 12 GA. Start those conversations with hosts now.
- Clone at least one production site to staging and run the beta upgrade. You do not need to do every site, but running one representative site through the beta will surface the class of issues you will face across the portfolio.
- Identify which core modules your sites rely on that may have been removed. The beta release notes are your checklist. Cross-reference against each site's installed module list.
- Confirm that critical contrib modules have beta 1 compatible releases. If the modules your site depends on have not cut a Drupal 12 compatible release yet, file an issue or reach out to maintainers. The beta period is exactly when this feedback matters.
- Plan for the two-step path. For any client on Drupal 10, scope the 11 upgrade as a prerequisite engagement, not an afterthought bundled into the 12 project.
Originally referenced: Drupal 12.0.0-beta1 Opens Upgrade Testing With PHP 8.5 and Core Removals on The Drop Times.
If you are managing Drupal sites and want help mapping out what a clean path to Drupal 12 looks like for your specific stack, get in touch. We are already running beta compatibility audits for clients and can help you understand the scope before it becomes urgent.
