Where your site starts decides the work. From Drupal 8, 9 or 10 the site is upgraded in place: the database, the content and the screens your editors use all stay, and the code around them changes, from core and contributed modules to custom code written against removed APIs. From Drupal 7 there is no in-place route, so the content is migrated into a rebuilt Drupal 11 site. Either way, the first thing we produce is a list: every module and every custom call, with what it needs.
Drupal release and support dates From the Drupal core release schedule, September 2026
- Drupal 7 End of life Security support ended on 5 January 2025.
- Drupal 8 End of life Reached end of life in November 2021.
- Drupal 9 End of life Reached end of life on 1 November 2023.
- Drupal 10 Ending Security support ends on 9 December 2026.
- Drupal 11 Current The current major version, and the target for an upgrade today.
- Drupal 12 Next In pre-release testing since 2 September 2026; the stable release is planned for December 2026.
Who this is for
- You run Drupal 10 in production. Security support ends on 9 December 2026 and the upgrade is not yet on anyone's plan.
- You are still on Drupal 8 or 9. The site works, but it has had no security releases since 2021 or 2023, and a security questionnaire or an insurance renewal is usually where that surfaces.
- You are still on Drupal 7. Its security support ended on 5 January 2025. The route to Drupal 11 is a migration rather than an upgrade, and it starts from an audit with the same labels.
- You are already on Drupal 11. You want to know what Drupal 12 will ask of your modules and your hosting before you commit to it.
- You are an agency with client sites on older versions. We run the audit and the upgrade under your name, and the client relationship stays yours: see white-label Drupal development.
Your route to Drupal 11 from Drupal 7, 8, 9 or 10
Drupal does not let a site skip a major version. The Drupal project's upgrade guide gives the example: to go from Drupal 9 to Drupal 11, a site upgrades to Drupal 10 and then to Drupal 11. So the route is set by the version you run today, and the audit starts by confirming it.
| You run | Route | Kind of work |
|---|---|---|
| Drupal 10 | 10.3 or later, then 11 | Upgrade in place |
| Drupal 9 | 9.4 or 9.5, then 10, then 10.3 or later, then 11 | Upgrade in place |
| Drupal 8 | 8.8 or 8.9, then 9, 10 and 11 | Upgrade in place |
| Drupal 7 | A new Drupal 11 site, with the content migrated in | Migration |
| Drupal 11 | The latest 11 minor release, then 12 once it is released | Upgrade in place |
From Drupal 10 to Drupal 11
A Drupal 10 to 11 upgrade is the shortest route, and the one with a deadline. The site is brought to Drupal 10.3 or later first, because Drupal 11 no longer carries the core database updates from before 10.3. Then come PHP 8.3, the contributed modules that need a Drupal 11 release, and the custom code that still calls APIs removed in 11. Actions UI, Activity Tracker, Book, Forum, Statistics and Tour have left core; a site that uses one of them installs its contributed version before the core update.
You get: the same site on Drupal 11, and the deprecation work that also prepares it for Drupal 12.
From Drupal 9 to Drupal 11
Drupal 9 reached end of life on 1 November 2023. Most of the change that people notice comes at the step into Drupal 10: CKEditor 4 and the Seven admin theme left core, so text formats move to CKEditor 5 and the markup in rich text fields is checked against it. PHP moves up with the code: Drupal 10 needs PHP 8.1 or newer, and Drupal 11 needs PHP 8.3.
You get: the same database, content and URLs, taken forward one major version at a time and tested at each step.
From Drupal 8 to Drupal 11
Drupal 8 reached end of life in November 2021, and it still upgrades in place. Everything on the Drupal 9 route applies, with an earlier start. Hosting that still runs PHP 7 moves up in stages, since Drupal 9 needs PHP 7.3 or higher, Drupal 10 PHP 8.1 and Drupal 11 PHP 8.3. The route has more steps, and the audit lists every one of them.
You get: the same site on Drupal 11, without a rebuild.
From Drupal 7 to Drupal 11
A Drupal 7 upgrade is a migration in practice. Drupal 7 security support ended on 5 January 2025, and Drupal 7 and Drupal 11 do not share an architecture, so there is no in-place route: the content moves into a rebuilt site, and old addresses are redirected. Land on Drupal 11 rather than waiting for 12. The Drupal 12 pre-release notes remove the Migrate Drupal modules from core without moving them to a contributed project, and say Drupal 6 and 7 sites can migrate to Drupal 11 and then update to Drupal 12 in the usual way.
You get: a rebuilt Drupal 11 site with your content, on the same upgrade path as every other site from then on. What carries over, the redirect map and the trial migration are set out on Drupal 7 and legacy CMS migration.
What you get from an upgrade
- A module compatibility audit you keep whether or not you hire us for the upgrade
- The route from your version to Drupal 11, with every major version step on it
- A recommendation against every module: Port, Replace, Drop or Decide
- A count of the deprecated API calls in your custom code, produced by static analysis
- The hosting changes each step needs: PHP, database and Composer dependencies
- A fixed price against that list, before any code changes
- The upgraded site on staging, tested, before it goes live
- A note of what Drupal 12 will need from your site, so the next step is planned
Sample Module compatibility report Drupal 9.5 to 11 · example.org
| Module | Installed | Recommendation | Reason |
|---|---|---|---|
member_sync Custom | 1.4 | Port | Deprecated API calls only; the logic is sound. |
ckeditor Drupal 9 core | 9.5 | Replace | CKEditor 4 left core in Drupal 10; text formats move to CKEditor 5 and their markup is checked. |
forum Drupal 9 core | 9.5 | Port | Still in core in Drupal 10 and removed in Drupal 11; the contributed Forum module is installed before the step to 11, so the forums carry on. |
page_counter Contributed | 1.0 | Drop | Analytics already records this and nobody reads the numbers. |
event_booking Contributed | 3.1 | Decide | The Drupal 11 branch changes how refunds work; this is a business call. |
An engineer reads it and replies within one business day.
How an upgrade runs
How an upgrade from Drupal 8, 9 or 10 runs
- Audit Your version, every module, patch and custom call to a removed API, listed with a recommendation. You keep the audit report
- Fixed price Quoted against the route and the module list; it moves only if the scope does. You keep the priced scope
- Build One major version at a time on staging: core and modules updated through Composer, deprecated code rewritten with tests on it. You keep the repository
- Acceptance Your team checks the pages and journeys that matter on staging. You keep the test record
- Go-live and handover Deployed with a rollback ready; URLs, aliases and content unchanged. You keep the Drupal 12 notes
Deprecated code is found with Upgrade Status and Drupal Rector, the tools the Drupal project recommends, and PHPStan at the Drupal deprecation level, so the work is counted rather than estimated by feel. A Drupal 7 site follows the migration order of work instead, with entity mapping and a trial migration you can browse before cutover.
The module compatibility audit comes first
Before anything is quoted, we inventory what you actually run: the core version, contributed modules and their versions, custom modules and what they touch, the theme, the patches applied through Composer, and the integrations that would have to be re-pointed. Every module on the list carries a recommendation, with the reason attached:
- Port A compatible release exists for the version you are moving to, or the work to make one is small and worth doing.
- Replace A maintained contributed module or core now does the same job, and moving to it costs less than carrying yours forward.
- Drop The need has gone. This is the line that most often makes an upgrade cheaper than expected.
- Decide The module is abandoned upstream, and adopting it, replacing it or removing the feature is a business decision rather than a technical one. What each option involves is set out on Drupal module development and porting.
We run the same audit on our own code. We maintain WE Mega Menu, and its release 1.17.0 is published for Drupal 10.3, 11 and 12: deprecated calls found, ported and released in public, with the history on its drupal.org project page.
A huge thank you to the team for a flawless transition to Drupal 11. …
… This was a truly hands-off transition for me; the team handled all the heavy lifting during my busiest time of year. In previous migrations, I was involved daily, but this time I could trust the team to execute perfectly on their own.
Drupal 10 reaches end of life on 9 December 2026
Nothing breaks on the day. What changes is that the next serious vulnerability in core, or in a contributed module that many sites depend on, is fixed for supported versions and not for yours. You hear about it from the security advisory rather than from your own logs, and the remedy becomes an emergency upgrade instead of a planned one.
The commercial consequences often arrive first. Security questionnaires, insurance renewals and supplier due diligence all ask which version you run and whether it is still supported. Drupal 7, 8 and 9 sites are already in that position, and the route out for each is set out above.
Starting early also leaves time to wait for a module maintainer's Drupal 11 release instead of paying to port the module yourself.
An upgrade is not a migration
The two words get used as though they mean the same thing, and treating them as the same thing is how a quote ends up far out. Drupal 8, 9, 10 and 11 share an architecture; Drupal 7 does not.
| What changes | Upgrade | Migration |
|---|---|---|
| Database | Stays; update hooks move it forward | Content is moved into a new database |
| Content types and fields | Unchanged | Rebuilt, then mapped field by field |
| Theme | Kept, deprecated code fixed | Rebuilt for the new version |
| URLs | Unchanged | Mapped, with a redirect for each one that changes |
| Editors | Same site, same screens | A new site to learn |
| Price | Fixed against the module audit | Priced as a project, against the content and module audit |
Both routes start from an audit with the same labels. The migration route is its own service, with a redirect map and a trial migration among its deliverables: Drupal 7 and legacy CMS migration.
Drupal 12 upgrade: one step, or two?
Drupal 12 is in pre-release testing. Its first alpha came out on 2 September 2026, and the Drupal project's schedule plans the stable release for December 2026. The pre-release notes set PHP 8.5 and MariaDB 10.11 as minimums, move to Symfony 8, and take more modules out of core into contributed projects, Contact among them.
A major version cannot be skipped, so every route to Drupal 12 passes through Drupal 11. What you choose is when to take the last step:
- To Drupal 11 now, to 12 later. You reach a supported version with the smallest change, and Drupal 11 does not lapse when 12 is released: the Drupal project supports each major version until two further major versions have come out. This is the route we recommend for any site on Drupal 7, 8, 9 or 10 today.
- Through to Drupal 12 in the same project. Worth considering once Drupal 12 is stable and every contributed module you depend on has a Drupal 12 release. The site passes through Drupal 11 on staging either way, so waiting to start saves nothing.
Already on Drupal 11? Your Drupal 12 upgrade is a single major step, taken from the latest Drupal 11 minor release once Drupal 12.0.0 is out, and the audit checks the published Drupal 12 requirements against your modules and your hosting.
What a Drupal upgrade costs
The audit is scoped and priced on its own, because it is what makes a fixed price possible. The upgrade is then quoted at a fixed price against the route, a defined module list and a defined set of custom code changes, and that price moves only if you change what is in scope. Payment is by milestone, and go-live is one of them.
What it comes to depends on the version you start from and on your custom footprint, so the audit names the size instead of a guess here. The project sizes, from Micro to Strategic, are on the pricing page. A Drupal 7 site is priced as a migration project, and keeping any site patched afterwards sits under maintenance and support.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Can we skip a version and go straight to Drupal 11?
Not from Drupal 8 or 9. The Drupal project does not support skipping a major version, so a Drupal 9 site passes through Drupal 10 on its way to 11. The intermediate versions are worked through on staging, not in front of your users, and how the live site moves across is set in the plan and rehearsed against a copy of its database first. From Drupal 7 the question does not arise, because the content is migrated straight into a new Drupal 11 site.
Can a Drupal 7 site go straight to Drupal 12?
Not with the tools in Drupal core. The Drupal 12 pre-release notes remove the Migrate Drupal modules from core without moving them to a contributed project, and say Drupal 6 and 7 sites can still migrate to Drupal 11 and then update to Drupal 12 in the usual way. So a Drupal 7 migration today lands on Drupal 11, and the move to 12 follows as an ordinary upgrade.
Will our editors have to relearn anything?
Not from Drupal 10: content types, fields, views and editorial screens stay as they are. From Drupal 8 or 9 the text editor changes, and on some sites the admin theme: CKEditor 4 and the Seven admin theme left core in Drupal 10, so text formats move to CKEditor 5, and a site still on Seven moves to a current admin theme or installs Seven's contributed version. The audit lists what that touches. From Drupal 7, editors meet a new site, which is why they review the trial migration before cutover.
Can you upgrade a site you did not build?
Yes. The audit is written for that case: it gives both sides a picture of a codebase neither of us wrote before anyone commits to a price. Agencies send us client sites on the same basis, under their own name when they prefer: see white-label Drupal development.
Will the upgrade affect our search rankings?
An upgrade from Drupal 8, 9 or 10 should not, because URLs, aliases and content stay the same. Where a module replacement changes a path, the redirect is mapped as part of the work and checked before go-live. A migration from Drupal 7 changes more, and a redirect map for every old address is one of its deliverables.
Do we need to move hosting as well?
Only if your current environment cannot run what the target version needs. Drupal 11 needs PHP 8.3 or newer and a supported database, such as MySQL 8.0 or MariaDB 10.6 and later; the Drupal 12 pre-release requires PHP 8.5, and MariaDB 10.11 or newer where MariaDB is the database. The audit checks this first, because a hosting constraint found halfway through an upgrade stalls it.
How long does an upgrade take?
It depends on the version you start from, the modules that need work, the custom code that calls removed APIs, the integrations to re-test and how quickly your team can review staging. The audit puts a figure against each before you commit; a number quoted before seeing your module list would be a guess.
Not covered here? Ask us directly.
Check your modulesAn engineer reads it and replies within one business day.
Migrate & Audit
Related services
Start with the module compatibility audit
Tell us which Drupal version you run. You get the route to Drupal 11, the module list and the findings, whether or not you hire us for the upgrade.
An engineer reads it and replies within one business day.