Drupal 12: What Changes and When to Move

Drupal 12 is scheduled for the week of 7 December 2026, and Drupal 10 reaches end of life on 9 December 2026. Both dates sit on the same page of the Drupal core release schedule, two lines apart, and most people running a Drupal 10 site have noticed neither. The first alpha of the new major was tagged on 2 September 2026, so the shape of the release is now a matter of record rather than speculation.

That collision is the whole story. A major version arriving is not usually urgent for a site owner, because you can sit on the previous major for a year or two while the ecosystem catches up. This time the previous major stops receiving security advisories in the same week the new one ships, which converts a technical event into a deadline with a compliance edge on it.

What follows is the calendar as drupal.org publishes it, what actually changes in the code, what the new platform floors force on your hosting, the three realistic upgrade paths with cost bands, and a plan working backwards from December. The reassuring part arrives early: most of a Drupal major version bump is deletion, not reinvention.

When does Drupal 12 come out, and do I have to move? Drupal 12.0.0 is scheduled for the week of 7 December 2026, released alongside Drupal 11.5.0. Drupal 10 reaches end of life two days later on 9 December 2026, after which no further security advisories are issued for it. A Drupal 11 site faces a small upgrade. A Drupal 10 site has to pass through Drupal 11.4 or later first, so the work is two hops rather than one.

The Two Dates That Decide Your Next Six Months

The release managers publish the whole cycle in advance, and the current one is unusually tidy. Drupal 11.4.0 landed in the week of 29 June 2026, and that release ended security support for both Drupal 11.2.x and Drupal 10.5.x. The 12.0.0-alpha1 tag went out on 2 September 2026. Beta requirements had to be complete by 11 September 2026, with 12.0.0-beta1 and 11.5.0-beta1 in the week of 14 September and release candidates in the week of 9 November.

Then the week of 7 December does three things at once. Drupal 12.0.0 ships, Drupal 11.5.0 ships alongside it, and security support ends for both Drupal 11.3.x and Drupal 10.6.x. Two days later, on 9 December 2026, Drupal 10 as a whole reaches end of life and no further releases of it will be made at all.

Why Drupal 10 and Drupal 12 Land in the Same Week

This is policy, not coincidence. The release process overview states that major versions arrive every two years in even years, and that each major is supported for a minimum of four years, until two further majors have been released. Drupal 10.0.0 came out on 15 December 2022. Drupal 11 arrived in August 2024 and Drupal 12 arrives in December 2026, which is the second further major, and four years have passed. The clock ran out exactly on schedule.

The same policy governs minors. Each minor version is supported for one year, with bug fixes and security fixes for the first six months and security fixes only for the last six. That is why only 10.6.x still receives advisories today, and why 11.3.x loses its coverage the moment 11.5.0 ships.

Drupal 11 does not stop when Drupal 12 starts. Releasing 11.5.0 in the same week begins what the policy calls the Long Term Support phase, in which the previous major keeps an API-matched minor, moves onto an LTS release of Symfony, and receives a maintenance minor every six months with a shrinking scope. Drupal.org does not publish a firm Drupal 11 end of life date, though its own deprecated extensions documentation says Drupal 11 will be supported until mid to late 2028.

How Many Sites Are Still Sitting on Drupal 10

The numbers are public and they are not comfortable. Drupal.org’s core usage statistics for the week beginning 23 August 2026 record 468,877 sites reporting a core version. Of those, 205,568 are on some branch of Drupal 10 and 168,857 are on Drupal 11. Roughly 44 per cent of the reporting installed base is on the version that stops receiving advisories in December.

The sharper number is inside that figure. Only 10.6.x still has security coverage, and 10.6.x accounts for 139,911 of those sites. The remaining 65,657 are on 10.0 through 10.5, which means they are running an unsupported minor today, in September, without waiting for December to arrive.

These counts come from sites that voluntarily report through the Update Status module, so the real population is larger and skews the same way. The practical reading is that a very large number of organisations are going to try to book the same upgrade work in the same quarter, and agency capacity in October and November will be the constraint rather than the code.

What End of Life Actually Means for a Drupal Site

End of life is not a switch that breaks the site. Your Drupal 10 install will keep serving pages on 10 December exactly as it did on 8 December. What changes is that the Drupal Security Team stops publishing advisories and patches for that code, so from that date every newly discovered vulnerability in Drupal 10 core is permanent.

The second effect is slower and does more damage. Contributed module security coverage depends on the module having a stable release on a supported core branch, so as maintainers drop Drupal 10 compatibility, the modules on your site quietly leave the advisory process too. You do not get a notification when this happens. The module simply stops appearing in security releases, and the available updates report on your own site keeps looking green.

The third effect is that the exit gets more expensive the longer you wait. A Drupal 10 site upgraded in November is upgraded against a maintained core branch with a working update path. The same site upgraded in the following June is a recovery project, because the contributed modules it depends on have had six more months to move on without it.

Cyber Essentials, Insurance and Contract Clauses

This is where an unsupported CMS stops being an engineering concern. The NCSC’s Cyber Essentials requirements for IT infrastructure v3.3, dated April 2026, states that all software on in-scope devices must be licensed and supported, and must be removed from devices when it becomes unsupported, or removed from scope by using a defined subset that prevents all traffic to or from the internet. The control applies to servers, IaaS, PaaS and SaaS, so a Drupal install on a server in scope is squarely covered.

A public-facing Drupal 10 site cannot be firewalled off the internet, so after 9 December 2026 the two available answers are to upgrade it or to accept that it fails that control. If your organisation holds Cyber Essentials or Cyber Essentials Plus and renews it annually, that is a question you will be asked in writing on your next assessment.

Be careful about what you claim beyond that. Whether a specific cyber insurance policy or client contract is affected depends entirely on its wording, and the clauses that matter are usually the ones requiring supported software or vendor-supported versions rather than anything naming Drupal. Read your own policy and your own master services agreements before December rather than after an incident, because that is the cheap time to find out.

What Is Actually Different in Drupal 12

Very little, and that is the honest and useful answer. The 12.0.0-alpha1 release notes put it plainly: 12.0.x will be nearly identical to 11.5.x except that deprecated code is removed including entire deprecated modules, dependencies are updated to new major versions, and system requirements are raised. For every other change, the notes tell you to read the 11.5.x branch.

There are a handful of genuine behaviour changes worth knowing. The default password hashing algorithm switches to argon2id, with bcrypt available through kernel parameters where argon2 is unavailable. The core robots.txt now blocks search result pages carrying query parameters, which stops search engines crawling infinite faceted combinations, and sites with a customised robots.txt need to add those disallow rules by hand. HTMX, which core already ships, moves from version 2 to version 4 for beta1.

One more is easy to miss. Hosting Drupal directly on Windows in a production environment is deprecated in Drupal 12, on the grounds that there is no automated Windows test environment and few developers testing on it. Windows remains supported for local development. If you run production on Windows, that is a hosting decision to make in the next few months rather than a code change.

The Extensions That Leave Core

Drupal has spent years moving narrow modules out of core into contributed projects, and Drupal 12 continues that. The alpha1 notes list Ban, Contact, Field Layout, History, Settings Tray, Shortcut and Telephone as removed, along with the Stable 9 theme. The Text with Summary field plugin has also moved to its own contributed module. Ban was deprecated back in 11.3, Contact, Field Layout, History and Telephone in 11.4, and Settings Tray, Shortcut and Text with Summary in 11.5.

Two of those will surprise people. Shortcut and Settings Tray are administrative features that a great many editorial teams use daily without ever thinking of them as optional, and Settings Tray in particular underpins the in-place block configuration that content editors rely on.

The mechanics of handling this matter more than the list. The correct move is to add the contributed version to your Composer requirements before you upgrade, not to uninstall the module. Uninstalling destroys the extension’s configuration, and Drupal’s module discovery looks in core last, so once the contributed project is present Drupal simply uses it. Note also that Drush can bypass the warnings on update.php about missing extensions, so the failure surfaces afterwards as errors on the status report.

Losing Migrate Drupal Is the Change That Bites Hardest

The Migrate Drupal and Migrate Drupal UI modules are removed in Drupal 12 and, unlike the rest, they are not being moved to a contributed project. Drupal 12 keeps the Migrate API and the destination plugins for modern Drupal, but it does not keep the source plugins for Drupal 6 and Drupal 7.

Read that again if you own a Drupal 7 site. The tooling that reads a legacy Drupal database and writes it into a modern one exists in Drupal 11 and does not exist in Drupal 12. Drupal.org’s guidance is explicit: sites on Drupal 6 or Drupal 7 that intend to use the migration API should continue to migrate to Drupal 11, and then use the ordinary update process to move from Drupal 11 to Drupal 12.

That turns a vague intention into a hard sequencing constraint. A Drupal 7 rebuild that lands after Drupal 11 goes out of support has to either build its own source plugins, restore an older core to run the migration in a throwaway environment, or export and re-import the content by other means. All three are more expensive than doing the migration into Drupal 11 while Drupal 11 is a current, maintained target. Our guide to Drupal migration costs, options and deadlines covers the shape of that work in detail.

The New Dependency Floors

A major version is where Drupal is allowed to raise its platform requirements, and Drupal 12 uses that allowance across the board. These floors are the part of the upgrade you cannot negotiate with, because they are enforced at install time.

PHP 8.5, and nothing older

Drupal 12 requires PHP 8.5. The PHP requirements table shows Drupal 12.0 supporting PHP 8.5 and refusing everything below it, while Drupal 11.3 and 11.4 accept 8.3, 8.4 and 8.5. That overlap is your migration route: move the site to PHP 8.5 while still on Drupal 11.4, confirm it behaves, then change Drupal.

The floor is generous rather than punishing. PHP 8.5 was released on 20 November 2025, and php.net’s supported versions page puts its active support to 31 December 2027 and security support to 31 December 2029. Landing on it buys three years before this conversation happens again.

Databases and Symfony

The database server requirements for Drupal 12 are MySQL 8.0 or later, MariaDB 10.11 or later, PostgreSQL 18 or later, and SQLite 3.45 with the json1 extension. PostgreSQL sites should treat that floor as the one to verify carefully, because the alpha1 release notes say PostgreSQL 19 while the requirements page and the installer code both say 18. Check it again at beta1 before you book database work.

Underneath, Symfony moves from 7.4 to 8.1 and Guzzle from 7 to 8. Support is dropped for several older library majors including doctrine/lexer 2, egulias/email-validator 3 and guzzlehttp/psr7 2. Custom code that type hints Symfony classes directly is where this shows up.

What the floors force on your hosting

The MariaDB jump is the one that catches shared and managed hosts. Drupal 11 accepts MariaDB 10.6, whose community maintenance ended on 6 July 2026 according to the MariaDB maintenance policy, so a Drupal 11 site can currently sit on an unsupported database engine quite legitimately. Drupal 12 lifts the floor to 10.11, which is maintained until 16 February 2028. If your host cannot offer PHP 8.5 and MariaDB 10.11 today, the hosting move has to happen before the Drupal move, and that reordering is what turns a two-week job into a two-month one. Our note on what actually runs Drupal well covers the platform side.

Why the Deprecation Model Makes Drupal 12 Tractable

Here is the mechanism most site owners have never had explained, and it is the reason Drupal majors are no longer frightening. The continuous upgrades policy commits core to a simple promise: the next major release has the same public API as the last minor release of the previous major. New APIs are added in minors, old ones are marked deprecated in minors, and the deletion happens only at the major boundary.

The practical consequence is worth stating in plain terms. If your custom code and your contributed modules run on Drupal 11.5 with no deprecation warnings, they run on Drupal 12. The upgrade stops being a rewrite and becomes a dependency bump plus a database update, because everything that would have broken was already reported to you months earlier as a warning you could have fixed at leisure.

This is also why the release notes tell you to update to 11.4 or later first, and strongly recommend 11.5. The database update path from releases prior to 11.4.0 has been removed from Drupal 12 outright, so a site on 11.3 or earlier has no route into 12 until it moves up the 11 branch first. That is not advice, it is a missing code path.

The Tools That Report Deprecations

Two projects do the work, and both are currently maintained. Upgrade Status is the site-wide scanner. You install it on the site you are upgrading from, not the one you are upgrading to, because the deprecated APIs have to exist for it to find calls to them. It checks whether your environment meets the next major’s system requirements, cross-references your contributed projects against available updates, runs PHPStan for deprecated PHP API use, and reads Twig templates, info.yml files, composer.json and deprecated configuration keys. Release 5.0.0-alpha3, from 2 July 2026, declares compatibility with Drupal 10.4, 11 and 12.

It also categorises what it finds, which is the part that saves money. Problems are sorted into those a machine can fix and those a person has to, so you can cost the manual half before committing to a date. It runs under Drush as upgrade_status:analyze, and its Code Climate JSON output plugs into GitLab CI.

Drupal Rector is the other half. It rewrites the mechanically fixable deprecations in your custom modules and themes, with a --dry-run flag to preview the diff first. Version 1.1.2 was released on 7 August 2026. Between the two, a competent developer can produce a defensible readiness report for a mid-sized site in two to three days.

Path One: Drupal 11 to Drupal 12

If you are on Drupal 11.4 or 11.5 with current contributed modules, this is a small piece of work. The official upgrade guide is mostly Composer commands: require the version 12 metapackages with --no-update, drop any explicit drupal/core requirement, run composer update --dry-run, then run it for real and apply database updates with drush updatedb.

The real work sits either side of that. Beforehand, run Upgrade Status, add contributed replacements for any removed core extension you actually use, and confirm your host offers PHP 8.5. Afterwards, expect every core scaffold file to have changed, including .htaccess, so any customisation you made to those has to be reapplied deliberately rather than merged blindly.

When a dependency refuses to resolve, composer why-not drupal/core ^12 names the blocker. Allowing two majors of a module in composer.json, for instance "^6.1 || ^7.0", is the standard way to bridge a project mid-transition. If you need a module that has a working patch but no tagged release, the Drupal Lenient Composer endpoint exists for exactly that and is still maintained.

Path Two: Drupal 10 to Drupal 12 Is Two Hops

There is no direct Drupal 10 to Drupal 12 upgrade. The Upgrade Status documentation says so explicitly, and the removal of the pre-11.4 database update path is what enforces it. You go from Drupal 10.6 to Drupal 11.4 or 11.5, verify the site, and then go from there to Drupal 12.

Planned properly, that is not twice the work. The Drupal 10 to Drupal 11 hop carries almost all of the risk, because that is where the contributed module compatibility problems live and where custom code meets removed APIs. The second hop is the small one described above. Teams that try to compress both into a single change window usually end up unable to tell which of the two broke something.

The sequencing that works is to do the Drupal 11 hop now, run the site on 11.4 or 11.5 for several weeks so real editorial and traffic behaviour surfaces anything odd, and take Drupal 12 in the new year once contributed modules have tagged stable releases against it. Doing the first hop before December is what matters, because it is the hop that takes you off unsupported code.

Path Three: Drupal 7 or 8 Is a Rebuild, Not an Upgrade

Anything older than Drupal 9 is a different exercise. Drupal 7 reached end of life on 5 January 2025 and Drupal 6 in February 2016. Neither upgrades in place at all, because they predate the modern architecture entirely. They are migrated, which means a new site is built on current Drupal and the content is moved into it with the Migrate API. A Drupal 8 site technically does have an in-place route, but it runs through four consecutive majors and every contributed module has to survive each one, so it is normally cheaper to treat it as a rebuild too.

The cost is dominated by everything that is not content. The theme is rebuilt, custom modules are rewritten against an entirely different API, and integrations are reconnected. In our experience the content migration itself is usually the smaller half of the budget, which is the opposite of what most owners expect when they ask for a quote, and it is the reason we scope these as website development projects rather than upgrades.

For these sites the December deadline works differently but still bites, because of the Migrate Drupal removal. Your target has to be Drupal 11, not Drupal 12, and Drupal 11 is supported until mid to late 2028 according to drupal.org’s own documentation. That gives a Drupal 7 owner a genuine window, but it is a window with a hard end, and starting a six-month rebuild in 2028 to hit a 2028 target is not a plan.

What Each Path Costs in the UK

These are house estimates from our own delivery, not published rates, and the spread inside each band is driven almost entirely by contributed module health rather than by site size. UK agencies bill roughly £600 to £900 a day for this work. A Drupal 11 to 12 upgrade on a maintained site is three to eight days including testing, which lands around £2,000 to £6,000. Where the same site has stale contributed modules, allow two to four weeks and £6,000 to £12,000.

A Drupal 10 site costs both hops. Well maintained, the Drupal 10 to 11 hop is £6,000 to £15,000 and the Drupal 12 hop adds £2,000 to £6,000, so £8,000 to £21,000 in total across four to eight weeks. Neglected, the first hop alone runs £15,000 to £35,000 and the total lands between £17,000 and £41,000. A Drupal 7 rebuild is three to six months and commonly £40,000 to £120,000, higher for large or heavily customised sites.

The Contributed Module Audit That Sets Your Date

Upgrade projects rarely die on core. They die on the fourteenth module in the list, the one nobody remembers installing, which has no release compatible with the next major and a maintainer who last commented in 2023. Do this audit before you commit to a date, because it is the audit that produces the date.

Run Upgrade Status and export the report, then sort your modules into four buckets. The first is projects with a stable release supporting the target major, which cost nothing. The second is projects with a patch or a development release in the issue queue, which cost a small amount of integration work and carry the risk that the patch never lands. The third is projects with an open issue and no patch, which need somebody to write one. The fourth is projects with no activity at all.

The fourth bucket sets your timeline, and its size is knowable today rather than in November. A site with thirty contributed modules and nothing in bucket four is a straightforward job. The same site with four modules in bucket four is a different engagement with a different budget, and the difference between those two quotes is a day of scanning.

What to Do About an Abandoned Module

There are four honest options and the right one depends on what the module does. Remove it, if the feature it provides is no longer used, which is more often true than teams expect after several years of editorial drift. Replace it with a maintained project that does the same job, accepting the configuration migration that comes with that.

Take over maintenance, which is a real option in Drupal and less daunting than it sounds. Drupal.org has a documented process for becoming the maintainer of an unsupported project, and for a small module that your business depends on, adopting it can be cheaper than replacing it. The cost is ongoing rather than one-off, so account for it honestly.

Or reimplement the behaviour in a custom module scoped to what you actually use. A contributed module solves the general case for everybody, while you usually need one narrow slice of it. Reimplementing that slice against current APIs is frequently a two-day job against a two-week port, and it removes the dependency permanently. Our guidance on hiring a Drupal developer covers how to vet somebody for exactly this kind of judgement.

A Timeline Working Backwards From 9 December 2026

Start from the end date and the plan writes itself. By late September, run Upgrade Status against Drupal 12 on a copy of production and get the four buckets on paper. That is a two to three day exercise and it is the only artefact that lets you cost anything else honestly.

By mid October, confirm your hosting can deliver PHP 8.5 and the database floors, and start the move if it cannot. Also decide the contributed module questions, because every one of them has a lead time attached. By early November, have the Drupal 11.4 or 11.5 upgrade complete on a Drupal 10 site, with the site running on the new branch in production.

By early December you are watching the 12.0.0 release rather than reacting to it. If you are on Drupal 11 at that point, take Drupal 12 in January or February 2027, once contributed projects have tagged stable releases against it. There is no prize for upgrading in release week, and Drupal 11.5 will still be supported. The prize is for not being on Drupal 10 when the advisories stop.

What It Costs to Do Nothing

The direct cost is that every Drupal core vulnerability disclosed after 9 December 2026 stays open on your site permanently. Drupal’s advisory history includes remote code execution issues serious enough to be exploited within hours of publication, and an unpatched CMS on a public IP is found by automated scanning, not by a targeted attacker who chose you.

The indirect costs arrive sooner and are usually larger. Failing the supported-software control on a Cyber Essentials assessment can affect eligibility for contracts that require the certification, which in UK public sector procurement is common. Contributed modules stop shipping fixes for your branch. And the upgrade itself gets more expensive every month, because the gap between your codebase and the maintained ecosystem widens without anybody touching anything.

There is a quieter cost too. A site nobody is allowed to upgrade tends to become a site nobody is allowed to change, and feature work stops because every change has to be built against an API that is going away. That is how a five-year-old Drupal site turns into a rebuild rather than an upgrade. If you are weighing that decision, our Drupal development guide is a better starting point than a quote.

Two Legitimate Reasons to Wait

Waiting is defensible in two situations, and only if you wait deliberately. The first is that you are already on Drupal 11.4 or 11.5. Those branches are supported, they are the designated launchpad for Drupal 12, and there is no advantage in taking a brand new major in its first weeks while contributed projects are still tagging releases. Waiting until the first quarter of 2027 is the professional choice, not the lazy one.

The second is a Drupal 7 site with a funded rebuild already scheduled. Migrating Drupal 7 into Drupal 11 and then immediately into Drupal 12 is wasted motion. Land on Drupal 11, run it, and take Drupal 12 as ordinary maintenance later.

What is not defensible is sitting on Drupal 10 without a booked plan. If that is you, the minimum acceptable position by the end of September is a scan report, a named target branch, and a date in a calendar. Everything else can move. If you want that assessment done by somebody who has run it before, our software development team does version audits as a fixed-scope piece of work.

Where to Start

Run the scan first. Nearly every bad Drupal upgrade quote in existence was produced without one, which is why so many of them are wrong in both directions. Two to three days of Upgrade Status and Drupal Rector output tells you which of the five cost bands above you are actually in, and that single number changes the conversation with your board more than any amount of general advice about major versions.

Mecanik runs those audits and the upgrades that follow, on Drupal 10 sites facing December and on Drupal 11 sites planning a calmer move in 2027. Custom module work, integrations and the deprecation clean-up sit with our software development practice, while a rebuild or a hosting move belongs with website development. If security posture is the reason this landed on your desk, start with our note on Drupal security advisories and real risk, and if organic traffic is the worry during a version move, the Drupal SEO setup piece covers what to protect.

Frequently Asked Questions

When is Drupal 12 released and when does Drupal 10 reach end of life? Drupal 12.0.0 is scheduled for the week of 7 December 2026, released alongside Drupal 11.5.0, and Drupal 10 reaches end of life on 9 December 2026. Both dates are published on the Drupal core release schedule. In the same week, security support ends for the 11.3.x and 10.6.x minor branches. Drupal 12.0.0-alpha1 was tagged on 2 September 2026.

Can I upgrade directly from Drupal 10 to Drupal 12? No. The database update path from releases prior to Drupal 11.4.0 has been removed from Drupal 12, so a Drupal 10 site has to move to Drupal 11.4 or later first and then to Drupal 12. Drupal.org recommends 11.5.0 or higher before the major move. Plan it as two hops, with the Drupal 10 to 11 hop carrying nearly all the risk and cost.

What are the Drupal 12 system requirements? Drupal 12 requires PHP 8.5 and drops support for PHP 8.4 and earlier. The database floors are MySQL 8.0, MariaDB 10.11, PostgreSQL 18 and SQLite 3.45 with the json1 extension. Symfony moves to 8.1 and Guzzle to 8.0. Hosting Drupal directly on Windows in production is deprecated, though Windows remains supported for local development.

What is actually new in Drupal 12 compared to Drupal 11.5? Almost nothing, by design. The alpha1 release notes state that 12.0.x is nearly identical to 11.5.x apart from removed deprecated code, updated dependency majors and raised system requirements. The behaviour changes worth noting are argon2id as the default password hashing algorithm, HTMX moving to version 4, and a core robots.txt that blocks search result pages with query parameters.

How much does a Drupal 12 upgrade cost in the UK? On a maintained Drupal 11 site, three to eight days of work at typical UK agency rates of £600 to £900 a day, so roughly £2,000 to £6,000. A Drupal 10 site pays for both hops, landing between £8,000 and £21,000 when well maintained and £17,000 to £41,000 when neglected. A Drupal 7 rebuild is three to six months and commonly £40,000 to £120,000. These are house estimates, not published rates.