Drupal development by Webair

Complex sites, kept
simple to run

We build, upgrade and support Drupal sites, with content modeled for how your teams publish and modules kept ready for each new version, so the next upgrade is an update, not a rebuild.

Thanks, we’ll be in touch soon.

{{ heroStatus }}

You’re in good company

A few of the companies we’ve worked with.

When the oldest module sets the pace

Many organizations run large Drupal sites built up over years: Drupal core, contributed modules from Drupal’s community that add features to it, and custom code written for the site alone.

A site can move to the next major version, such as Drupal 11 after Drupal 10, only once the modules it relies on and its own code are ready for it. So one module that’s no longer maintained, or custom code that still uses what Drupal has since removed, can hold back the whole site while its version moves toward its end of life.

Meanwhile, on many of these sites, editors work around a content structure that no longer matches how they publish.

What we build

Drupal sites shaped around your content and the teams who publish it, each change tested on a copy of the site before it reaches the live one.

  • New Drupal sites

    The content modeled first: its content types, the kinds of content it holds, such as a course or an event; their fields, such as a start date; and categories that match how your teams publish.

  • Updates to the current major version

    Every module checked against the next version first, and custom code moved off what Drupal has marked as deprecated, meaning due for removal, so the update itself is a smaller step.

  • Moves from Drupal 7

    A new site on current Drupal with your content migrated into it, as drupal.org’s upgrade guide sets out, and every old address redirected to its new page, as Google’s guidance on site moves recommends.

  • Editorial workflows and permissions

    Roles, each a set of permissions, for who drafts, who reviews and who publishes, and a workflow, the steps from draft to published, so a change waits for review while the live page stays as it is.

  • Sites in more than one language

    Content, settings and interface text translated with Drupal core’s own multilingual tools, each translation kept with the page it belongs to.

  • Custom modules and themes

    Modules for what your site alone needs, and themes, which set how it looks, built on Drupal’s APIs and coding standards, never as changes to Drupal core itself.

  • Connections to your CRM, sign-in and other systems

    Form entries sent on, content shared through Drupal’s APIs with the platforms your business runs on, and staff signing in with the accounts they already have.

  • Drupal CMS and Drupal Canvas, where they fit

    Pages your marketing team builds from your site’s components in Drupal Canvas, the visual page builder in Drupal CMS, a product built on Drupal core.

  • A site that stays quick, accessible and patched

    The causes of slow pages found and fixed where they matter most, pages built to WCAG 2.2 at level AA, and security releases tried on a copy of the site before they go live.

Content entered once, used everywhere

In Drupal, content is stored as structured entries, not as finished pages. Each content type has its own fields, so a course has its mode, its schedule and its start date, each entered in a field of its own.

The site then builds any list it needs from the same entries, such as a course finder or a department’s page, and other systems can read them through an API that’s part of Drupal core and keeps to the site’s permissions. A change to one entry shows wherever it’s listed.

So editors fill in fields instead of laying out pages, and every site we build starts with its content model.

Courses

Each course is entered once. Every list on the site is built from the same entries.

{{ stStatus }}

Where you start decides the work

On Drupal 10 or 11, each major version arrives with the same public API as the last minor version, or feature release, before it, without the code Drupal marked as deprecated along the way. So once a site’s modules and custom code no longer use that code, the move is an update of the same site, in place.

On Drupal 7 there’s no update: the site is rebuilt on current Drupal, and its content migrated into it.

Drupal publishes when support for each version ends. Drupal 10’s support ends on December 9, 2026, the week Drupal 12 is scheduled for release, and Drupal 7’s ended on January 5, 2025. Each major version also raises the PHP it needs: Drupal 11 needs PHP 8.3 or later and Drupal 12 will need PHP 8.5, and Drupal drops PHP versions that PHP itself no longer supports, so the plan follows both.

So the work begins by finding which modules and which custom code stand between the site and the next version.

Start with a review of your site

The review covers the site’s version, and where it stands on Drupal’s schedule; its contributed and custom modules, which are ready for the next version, which are no longer maintained and which Drupal core could now replace; its content model, from content types and fields to the lists built from them; its roles and workflows, who drafts, who reviews and who publishes; its languages, its connections to other systems and its sign-in; its speed and its accessibility basics; and how it’s deployed, updated and tested.

On Drupal 7, starting a new site, or moving to another platform? We model the content first, then build one content type, migrate its content and release it early, so your team works with the new site before the rest of it is built.

Either way, you get a written review and a proposal for the first step.

Questions worth asking

  1. Which version should we be on?

    One that Drupal still supports with security releases: today, Drupal 11 on a current minor version, which Drupal plans to support until mid to late 2028, or Drupal 10’s last, 10.6, until its end of life. Drupal publishes these dates on its release schedule, and the review checks your site against them.

  2. What happens when Drupal 10 reaches its end of life?

    Drupal 10 reaches its end of life on December 9, 2026, and Drupal says no new releases of Drupal 10 will be made after that date, so a problem found later won’t be fixed for it. Moving to Drupal 11 is an update of the same site once its modules and custom code are ready, and the review shows how much stands in the way.

  3. We’re still on Drupal 7. What are our options?

    Drupal 7’s support ended on January 5, 2025. You can rebuild on current Drupal, with your content migrated into a new site, or move to another platform. Drupal 11 keeps core’s tools for migrating a Drupal 7 site, and Drupal 12’s pre-releases remove them, so the content moves into Drupal 11 and the site updates from there. If neither can happen yet, the Drupal Association runs an Extended Security Support Provider Program, through which you can buy security support for Drupal 7 from vendors it has vetted. The review helps you weigh the three.

  4. Should we wait for Drupal 12?

    Drupal 12 is in beta, scheduled for release in the week of December 7, 2026. Drupal says it will be nearly the same as Drupal 11.5, without the code marked as deprecated, and its release notes so far ask sites to update to a recent Drupal 11 release first. So the way to Drupal 12 runs through Drupal 11, and a site that’s ready for 11 usually has less to do for 12.

  5. Should we stay on Drupal, or move to another platform?

    It depends on the site. Drupal suits sites with a lot of structured content, many editors or several languages; a smaller site that a marketing team runs may suit WordPress or Webflow better. We’ll recommend the simplest option that fits, and our teams for each can make the move.

    WordPress DevelopmentDevelopment for Webflow

  6. What is Drupal CMS, and is it right for us?

    Drupal CMS is a product built on Drupal core, ready to start from, with Drupal Canvas, a visual page builder, a library of components and site templates for particular kinds of site. It can suit a new site whose team wants to build pages visually; a large site with a content model of its own may use less of it. The review says which.

  7. Can our marketing team build pages on their own?

    With Drupal Canvas, yes: your team builds pages from your site’s own components and sees each change as it’s made, within the permissions their role gives them. Drupal CMS’s guide says its workflows don’t yet cover Canvas pages, so who may publish them is set by role.

  8. Can you take over our existing Drupal site?

    Yes. We start from a copy of the site, read how it’s built, from its content types to its custom modules, and note who has access, in which role. The review then says what to change and in what order, and nothing changes on the live site until you’ve agreed to it.

  9. Can it connect to our other systems?

    Yes. We connect Drupal to the platforms your business runs on, from CRM and ERP to finance and your own software, so content, form entries and accounts stay in step, and each connection is documented.

    Systems & API Integration

  10. Our site is slow. Can you make it faster?

    Usually, once the cause is found. We trace each slow page to it, whether that’s caching, heavy images, slow queries or a module doing more than it should, and fix what matters most, measuring each fix.

    Performance & Optimization

  11. Is our site accessible?

    The review checks it against the current standard, WCAG 2.2, at level AA, unless you need another. Fixes go into the theme and its components first, so each one reaches every page that uses them.

    Accessibility

  12. How do you keep it secure?

    Drupal publishes security releases in a window it usually sets for the third Wednesday of each month. We try each one on a copy of the site before it goes live, keep each person’s role to what they need, and review custom code before it’s added. Drupal’s security team publishes advisories for core and for the contributed modules its advisory policy covers, and a module’s page on drupal.org says when it isn’t covered, so the review checks yours. Our security work adds threat modeling, code review and checks in every build.

    Application Security

  13. Who hosts it?

    We can host it, or it can stay with the hosting you have. Either way, hosting and the platform beneath your software are a service of their own.

    Cloud, DevOps & Security

  14. What does it cost?

    It depends on the site: its size, its modules and custom code, and whether it’s being built, updated or rebuilt. You get a written proposal before any work starts: the scope, the price or rate, and how you pay.

    Pricing

  15. Can your developers work inside our own team?

    Yes. Tell us what your site needs, and we’ll introduce Drupal developers matched to it within 48 hours, working in your time zone. You meet them and decide who joins.

Drupal is a registered trademark of Dries Buytaert. Webair isn’t affiliated with or endorsed by Dries Buytaert or the Drupal Association.

Let’s build it better

Tell us which version your site runs on and how your teams publish. A short call is enough to see what stands between your site and the next version.

Thanks, we’ll be in touch soon.

{{ ctaStatus }}