A Drupal module is where behaviour specific to you lives, and it is also where upgrades break. Our Drupal module development starts with that second case: we port contributed modules to Drupal 11 and 12, and patch or replace modules whose maintainers have moved on, so an upgrade is not held up by a dependency nobody owns. Where nothing contributed does the job, we write the module. WE Mega Menu, the mega menu module we maintain on drupal.org, runs on Drupal 10.3, 11 and 12 from release 8.x-1.17.
Who this is for
- An upgrade is blocked by a contributed module. It has no Drupal 11 release, the issue queue holds a patch nobody has committed, and Drupal 10 security support ends on 9 December 2026.
- Your custom modules fail on Drupal 11. They call APIs that Drupal 10 deprecated and Drupal 11 removed, and the team that wrote them has gone.
- A module you depend on has been abandoned. The maintainer no longer answers, bug reports sit unread, and every core release makes the module harder to keep.
- You need behaviour nothing contributed provides. An integration with an internal system, or a rule only your organisation has, written once and owned by you.
- An agency needs a module under its own name. Written or ported by us, released as yours, through white-label development.
Modules written as part of a whole new site are covered on custom Drupal development. This page is for the module as the piece of work.
What you get
- The module in your repository, or a release on drupal.org when it is contributed
- Code that passes Drupal coding standards and static analysis for deprecated APIs
- Automated tests for the behaviour you rely on, run on every change
- For a port, a release that declares the Drupal versions it supports and installs with Composer
- An update path tested from the release you run today, so existing configuration and data survive
- A README and a change log written for the next developer
Sample Module release checklist Signed off before a release is tagged
Code
- No calls to deprecated APIs Upgrade Status and PHPStan report clean
- Drupal coding standards pass
core_version_requirementcovers every target version
Tests
- Kernel and functional tests pass on each supported core version
- Update hooks run on a copy of your data From the release you run today
- Configuration schema validates
Release
- Release notes list every change
- Composer installs it on a clean site
- Release tagged and the issue queue updated
An engineer reads it and replies within one business day.
How Drupal module development runs
How Drupal module work runs
- Audit The module, its issue queue, its deprecated calls and where your site uses it. Output: the audit
- Prototype The hardest change working on a copy of your site, at no charge. Output: the prototype
- Fixed price Priced against the audit and the behaviour agreed in writing. You keep the scope
- Build Written or ported with tests, reviewed in your repository or in the drupal.org issue queue. You keep the repository
- Acceptance Tested on a copy of your site on each target Drupal version. You keep the test record
- Warranty Defects in what we built are ours to fix, one year by default and up to three. You keep the release
Porting a module to Drupal 11 and 12
Since Drupal 8, each major version removes the APIs the previous one deprecated, and changes little else. Porting a module is mostly finding those calls and replacing them, which is why the work can be counted before it is priced: Upgrade Status and Drupal Rector find, and often fix, the mechanical part, and what remains is the part that needs judgement. Drupal 11 also requires PHP 8.3 and moves to Symfony 7, so a module's own dependencies are checked along with its code.
Drupal release and support dates
- Drupal 7 End of life Community support ended on 5 January 2025.
- Drupal 10 Ending Security support ends on 9 December 2026.
- Drupal 11 Current The current major version, and the target for a port today.
- Drupal 12 Next Stable release planned for the week of 7 December 2026.
WE Mega Menu went through this itself. Release 8.x-1.16 ran on Drupal 9.4 and 10; release 8.x-1.17 runs on Drupal 10.3, 11 and 12 from one codebase. Its release history, from drupal.org, is set out under the modules we maintain below.
Abandoned modules: adopt, patch or replace
When the maintainer of a module your site depends on has moved on, the choice is between adopting it, patching it and replacing it. Which one is right depends on how many other sites use the module and how long you need it.
| Question | Adopt it | Keep a patch | Replace it |
|---|---|---|---|
| What happens | Your organisation applies to maintain it through drupal.org's process for unsupported projects, we help with the code, and fixes are released for every site that uses it | The fix lives as a patch in your repository, applied by Composer on every build | The feature moves to a maintained module, or to core |
| When it fits | Many sites use it, and you want it kept alive in public | A short-term bridge while the upgrade lands | A maintained module already covers the same need |
| Cost over time | Maintenance time, shared with every site that uses it | Grows with each core release until someone ports the module | A one-off move of configuration and content |
| Security coverage | Returns once a stable release is covered by the Drupal Security Team | None: the patched code is yours to watch | That of the replacement |
The module compatibility audit on the Drupal 10 to 11 and 12 upgrade page marks a module like this Decide, because which column fits is a business decision as much as a technical one.
Modules we maintain on drupal.org
Our current modules are on drupal.org, each with its release history and issue queue:
- WE Mega Menu. A drag-and-drop mega menu builder, with its usage published on drupal.org; release 8.x-1.17 runs on Drupal 10.3, 11 and 12.
- Component Builder. A drag-and-drop page builder; release 3.1.0 runs on Drupal 10 and 11.
WE Mega Menu has been carried across each major version since Drupal 8. These are the releases on drupal.org where the Drupal versions it supports changed:
| Release | Released | Works with Drupal |
|---|---|---|
8.x-1.17 | 22 September 2026 | 10.3, 11 and 12 |
8.x-1.14 | 15 August 2023 | 9.4 and 10 |
8.x-1.11 | 18 June 2020 | 8 and 9 |
8.x-1.0 | 30 March 2018 | 8 |
Our older modules have releases for earlier Drupal versions; the open-source page lists the version each one targets. Most of the Drupal code we write never appears there: it lives in client repositories and belongs to the client, such as the web application we built from scratch for CreAct.
What module work costs
A module is priced from the audit: for a port, the deprecated calls and dependencies it finds; for a new module, the behaviour written down and agreed. Either is quoted at a fixed price before the work starts. Longer engagements are priced from the Back-end and Integration Engineer rate on the pricing page, and keeping a patched or adopted module current afterwards sits under maintenance and support.
A port that is part of a site upgrade is usually quoted inside the upgrade itself, so the modules and the site move together.
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
Who owns a module you write for us?
You do, from the first commit, as with everything we build (why you own the source code). It goes on drupal.org only if you decide it should; it is then licensed GPL like all Drupal code, and you choose who is listed as maintainer.
Can you port a module we did not write?
Yes; most ports are of code someone else wrote. For a contributed module we work in its issue queue, so the fix reaches every site that uses it. If the maintainer does not respond, the patch is applied to your site through Composer until it is committed or the project is adopted.
Will the ported module keep our configuration and data?
That is what the update path is for. Changes to stored configuration or database tables are written as update hooks and run on a copy of your data before release, starting from the version you run today, so the upgrade is rehearsed rather than hoped for.
Can one release support Drupal 10, 11 and 12 at once?
Often, yes. A release can declare several major versions when the APIs it uses exist in all of them, as WE Mega Menu 8.x-1.17 does for Drupal 10.3, 11 and 12. When an API changed in a way that cannot be bridged, the module gets a new major branch and the old one is kept for sites that have not moved.
What if the module has a security problem?
Security issues in contributed modules are reported privately to the Drupal Security Team, not in the public issue queue, and fixed before they are disclosed. We follow that process for the modules we maintain. A problem found in a module that is not covered, or not maintained, is fixed on your site first and reported through the same private channel.
Can you take over a custom module our last agency wrote?
Yes. We start by reading it: whether it has tests, whether it meets coding standards, which of its calls the next Drupal version removes, and where your site depends on it. You get that as the audit, with a fixed price for bringing it up to date, before we change a line.
Not covered here? Ask us directly.
Describe the moduleAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Custom Web Application Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Headless and Decoupled Drupal
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Tell us which module, and what it has to do
Name the module, or describe the behaviour you need, and the Drupal version you are moving to. We will say whether to write, port, patch or replace it before we quote.
An engineer reads it and replies within one business day.