An upgrade from Drupal 10 to Drupal 11 is a different piece of work from a Drupal 7 migration, and the difference is most of the price. The site stays. The content stays. The configuration stays. What changes is the code around them: core, the contributed modules you have installed, and whatever custom code you have written against APIs that have since been deprecated. Almost all of the cost sits in that last group rather than in Drupal itself, which is why the first thing we produce is not a plan but a list: every contributed and custom module you run, with a recommendation against each one. You own the source code that comes out of it, so nothing here creates a dependency on us that you did not choose.
- Who this is for
- Organisations running Drupal 10 in production with a December date they have not yet planned for, and teams on Drupal 11 that need to know what Drupal 12 will ask of them.
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 thousands of sites depend on, gets a fix for Drupal 11 and Drupal 12 and not for you. You find out about it from the security advisory rather than from your own logs, and the remediation is an emergency upgrade under time pressure instead of a planned one.
For most organisations the commercial consequences arrive before the technical ones. Security questionnaires, cyber insurance renewals and public-sector procurement all ask which version you run and whether it is still supported. An unsupported CMS is a finding, and a finding has to be answered in writing by somebody.
The calendar Drupal has published is tight, and the three dates sit inside a month of each other:
| Date | What happens |
|---|---|
| Week of 9 November 2026 | Drupal 12.0.0 release candidate |
| Week of 7 December 2026 | Drupal 12.0.0 stable |
| 9 December 2026 | Drupal 10 end of life |
That is why upgrade work booked in November is the most expensive way to do this. Contributed module maintainers release their Drupal 12 compatibility in the same weeks, the people who can help are already committed, and you lose the option of waiting for a module to be fixed upstream rather than paying someone to fix it for you.
An upgrade is not a migration
These two words get used as though they mean the same thing, and treating them as the same thing is how an upgrade quote ends up an order of magnitude out.
A Drupal 7 project is a rebuild. Drupal 7 and Drupal 10 do not share an architecture, so the content has to be mapped across with the Migrate API, the theme is written again, and most contributed modules have a different equivalent or none at all. That is our Drupal migration service, and it is priced as a build.
A Drupal 10 to 11 upgrade keeps the site. The database stays where it is. Your content types, fields, views and configuration carry over. Editors log in to the same interface. What has to change is code: core is updated through Composer, contributed modules move to their Drupal 11 releases, and anything that calls a removed API is rewritten. For a site with a small custom footprint and well-maintained contributed modules this is a small piece of work. For a site carrying years of bespoke modules it is a much larger one. The audit is what tells you which one you have.
The module compatibility audit comes first
Before anything is quoted as a project, we inventory what you actually run: 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.
The deliverable is a list. Every module on it carries one of four recommendations, with the reason attached:
- Port: a compatible release exists, or the work to make one is small and worth doing.
- Replace: a maintained contributed module now does the same job, and moving to it costs less than carrying yours forward.
- Drop: the need has gone, or the feature is now in core. This is the line that most often makes an upgrade cheaper than expected.
- Decide: the module is abandoned upstream and the choice between adopting it, replacing it or removing the feature is a business decision, not a technical one.
You keep that audit whether or not you hire us to do the upgrade. It is the document that lets you get a second quote on equal terms, and it is the same deliverable that opens a migration engagement.
Deprecated code, PHP 8.3 and Symfony 7
Drupal 11 raised its platform requirements: PHP 8.3 or newer, Symfony 7, and a supported database version. Most of the work this creates is not in your own code but around it: a hosting environment that has to move up, a Composer dependency that has not been updated in two years and now conflicts, a patch that no longer applies because the file it patched was rewritten.
In custom code, the pattern is almost always deprecated API calls rather than anything architectural. Static analysis finds these before a human reads a line: we run the upgrade status tooling and PHPStan at the Drupal deprecation level across the codebase, so the list of files that need touching is produced mechanically and can be counted, rather than estimated by feel.
Where code has to change, it is changed with test coverage on it. That is the difference between an upgrade you can verify and one you find out about from your editors.
Drupal 12: one step, or two?
Because Drupal 12 becomes stable two days before Drupal 10 goes out of support, everyone upgrading this year has the same question: go to 11 now, or wait and go straight to 12?
The honest answer depends on one thing you can check and one thing you cannot. The thing you can check is your module list: a Drupal 12 release has to exist for every contributed module you depend on, and in the first weeks after a major release some of them will not have one yet. The thing you cannot check is how fast your own team can absorb two upgrades.
In practice there are two sensible routes:
- Upgrade to 11 now, plan 12 for later. This gets you onto a supported version before the deadline with the smallest change set, and Drupal 11 to 12 is a much smaller step than 10 to 11 because the deprecations were already cleared. This is the lower-risk route and it is what we recommend for anything running in production today.
- Wait for 12 and go once. Defensible only if your contributed module list is short and well maintained, and only if you can commit to doing the work in December. If a single module you depend on has no Drupal 12 release, the plan converts back into the first route with less time left.
Drupal 12 platform requirements are published by the Drupal project and we check them against your stack during the audit rather than repeating a guess here. Whichever route you take, the deprecation work done for 11 is not wasted: it is the same work that makes 12 straightforward.
How the price is fixed
The audit is scoped and paid for on its own, because it is the thing that makes an honest fixed price possible. Once it is done, the upgrade is quoted at a fixed cost against a defined module list and a defined set of custom code changes, and that price does not move unless you change what is in scope.
What that costs depends almost entirely on the size of your custom footprint. Our published bands are on the pricing page; an upgrade of a site with a modest custom footprint usually sits at the maintenance end of them rather than the project end. Payment is milestone-based, and go-live is one of the milestones.
Every engagement ships with the full source code and a warranty: one year as standard, extendable up to three by agreement. The warranty policy sets out what it covers.
How long it takes
We do not publish a number here, because a number quoted without seeing your module list is a guess presented as a commitment.
What we can tell you is what drives it: the count of contributed modules that need a version bump, the count that need work, the volume of custom code that calls deprecated APIs, how many third-party integrations have to be re-pointed and re-tested, and how quickly your own team can review a staging site. The audit puts a figure against each of those, and the timeline falls out of it. That estimate is written down before you commit, which is the entire point of doing the audit first.
Work we have delivered on this path
Drupal version work is most of what we have done since 2012, across public sector, education and commerce. Two published case studies:
- ERSRI: a public-sector retirement system platform.
- Apex Embroidery Designs: a commerce platform moved onto a current Drupal.
The rest of the work is in the portfolio. If you want to talk to a reference running the same Drupal version as you, ask and we will arrange it.
Questions we get asked
What actually happens on 9 December 2026?
The Drupal Security Team stops issuing advisories for Drupal 10 core, and contributed module maintainers stop supporting their Drupal 10 branches. Your site keeps running. What you lose is the fix for the next vulnerability, and the ability to answer a security questionnaire with a supported version number.
Should we go to Drupal 11 or wait for Drupal 12?
For anything running in production today, go to 11 now. Drupal 11 to 12 is a much smaller step than 10 to 11 because the deprecation work is already done, and waiting means doing the whole upgrade in the same weeks that Drupal 12 ships and Drupal 10 expires. Waiting is only defensible with a short, well-maintained module list.
Will our editors have to relearn anything?
No. An upgrade from Drupal 10 keeps your content types, fields, views and editorial interface. The changes are in the code underneath. This is the main practical difference between an upgrade and a migration from Drupal 7, where editors do meet a new site.
What about our custom modules?
The audit lists them with a recommendation for each: port, replace with a contributed module, or drop because the need has gone. Static analysis finds the deprecated API calls mechanically, so the volume of work is counted rather than estimated. That decision is yours, made against real information.
One of our contributed modules is abandoned. Now what?
The audit puts a cost against each option: adopt it and maintain it yourself with our help, replace it with a maintained module that covers the same need, or remove the feature because it is no longer worth its upkeep. We have no interest in you paying to carry a module nobody uses.
Can you upgrade a site you did not build?
Yes, and most upgrades are exactly that. The audit exists partly to give both sides an honest picture of a codebase neither of us wrote. Taking over someone else's Drupal is ordinary work for us, not an exception.
Will the upgrade affect our search rankings?
It should not, because URLs, aliases and content do not change in a 10 to 11 upgrade. Where a module replacement changes a path, the redirect is mapped as part of the work and checked before go-live rather than discovered in Search Console afterwards.
What does it cost?
The audit is scoped and priced on its own. The upgrade is then quoted at a fixed price against the module list the audit produced, and the price does not move unless the scope does. Our published bands are on the pricing page; an upgrade with a modest custom footprint usually sits at the maintenance end of them.
Do we need to move hosting as well?
Only if your current environment cannot run PHP 8.3 and a supported database version. The audit checks this first, because a hosting constraint discovered halfway through an upgrade is the most common cause of a schedule slipping.
What do we get if we do not go ahead?
The audit. It is written to be read by someone who is not us: a module inventory, a recommendation against each item, the deprecated-code findings and an estimate. You can take it to another firm and get a comparable quote, which is the point of it being a separate deliverable.
Migrate & Audit
Related services
Start with the module compatibility audit
You get the module list and the findings whether or not you hire us for the upgrade.