Hire Drupal developers

Drupal is the content platform for complex, structured, regulated sites, and its developers are scarcer and more expensive than WordPress developers for good reasons.

What Drupal actually is

Drupal is an open-source content management framework written in PHP, built on Symfony components since its major rearchitecture. It sits at the complex end of the content management market: structured content with rich relationships, granular permissions, multilingual sites, and the kind of editorial workflow that regulated organisations require.

Where it differs most from WordPress is that content structure is a first-class design activity. You define content types, fields, taxonomies and the relationships between them, and the system generates the editing experience and the query capability from that model. That is more work upfront and it produces a system that handles genuinely complex content without fighting it.

Commercially, Drupal's strongholds are government, higher education, healthcare and large organisations with many sites and strict requirements. Accessibility, multilingual capability and granular permissions are treated as core concerns rather than as plugins. The hiring pool is considerably smaller than WordPress's and skews senior, which is both a cost and a quality signal.

The part that separates seniors from mid-levels

The entity and field system is the foundation. Almost everything in Drupal is an entity with fields attached, and understanding this abstraction is what lets someone model content properly rather than approximating it. Developers who model content well produce sites that editors can use and that can answer queries nobody anticipated. Those who do not produce sites where every new requirement means another content type.

Configuration management is the second area and it is where Drupal is genuinely ahead of most content systems. Configuration lives in files that can be version-controlled, reviewed and deployed, separately from content. That means a change to a content type or a view can move through environments like code. Developers who have run this properly talk about configuration splits between environments; those who have not make changes in production and try to remember them.

The third is the module ecosystem and the discipline around it. Drupal's contributed modules are generally of higher quality than the WordPress equivalent, partly because of a stronger review culture. But every module is an upgrade dependency, and major version transitions have historically been where Drupal sites get stranded. Knowing which modules are actively maintained and which will block an upgrade is genuinely valuable knowledge.

Where Drupal is used

The label “Drupal developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Government

National and local government sites, where accessibility, multilingual support and security are requirements rather than preferences.

Higher education

University sites and multi-site networks with many departments and devolved editing.

Healthcare and non-profit

Organisations with complex content, compliance obligations and limited budgets, where open source matters.

Large publishers

Editorial workflow with approval chains, scheduled publishing and structured content.

Multilingual sites

Translation workflow built into the core system rather than added on, which is a genuine differentiator.

Decoupled implementations

Drupal as a structured content back end with a separate front end, well supported by its API-first work.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Drupal versions are still supported

Drupal publishes support windows per major version, and because its main markets are government and healthcare, running past end of life is usually a compliance problem rather than a technical preference.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 3 are still maintained and 5 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Drupal alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

PHP and Symfony

The foundation since the modern rearchitecture. Symfony familiarity transfers directly.

Composer

Dependency management for core and modules. Central to how modern Drupal is assembled.

Drush

Command-line management, essential for deployment and automation.

Configuration management

Version-controlled configuration deployed between environments.

Views

Query and listing building through configuration rather than code, one of the platform's strengths.

Twig

The templating layer, shared with Symfony.

MySQL or PostgreSQL

The data store, with the entity system layered over it.

A deployment pipeline

Configuration import and database updates on deploy, which is not optional here.

Related skills that frequently appear on the same specification: PHP, WordPress, JavaScript, SQL, MySQL.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Content modelling

The defining Drupal skill and what the platform exists for.

• Strong answer: Designs entities, fields and relationships around how content will be used and queried, not around current page designs.
• Warning sign: Creates a content type per page template.

Configuration management

Where Drupal offers a genuine advantage that many teams fail to use.

• Strong answer: Configuration in version control, deployed through a pipeline, with environment splits handled properly.
• Warning sign: Makes configuration changes in production.

Module selection and upgrade risk

Modules are what strand sites on old versions.

• Strong answer: Evaluates maintenance status, keeps the count deliberate, and checks upgrade compatibility before adopting.
• Warning sign: Installs modules freely without considering the upgrade path.

Custom module development

Separates site builders from developers.

• Strong answer: Writes modules using the service container and plugin system properly, following the framework's conventions.
• Warning sign: Solves everything through configuration, or writes procedural code that bypasses the architecture.

Caching and performance

Drupal's cache system is powerful and easy to defeat accidentally.

• Strong answer: Understands cache tags and contexts, knows what invalidates what, and has diagnosed a page that would not cache.
• Warning sign: Disables caching to make something work.

Major version upgrades

Historically where Drupal sites have been stranded.

• Strong answer: Has taken a site across a major version, and can describe module compatibility as the real constraint.
• Warning sign: Has only worked on sites that were never upgraded.

Accessibility

A core concern for Drupal's main markets rather than an afterthought.

• Strong answer: Treats it as part of building, knows the standards their sector requires, and has tested with assistive technology.
• Warning sign: Regards accessibility as a post-launch audit.

Warning signs in a Drupal codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

A content type per template

• What you see: Dozens of content types mirroring page designs rather than content structure.
• What it costs: Unmaintainable editing experience, and no ability to query across content that is conceptually the same.
• The fix: Model content by what it is, not by how it currently looks. Use view modes for presentation variation.

Configuration changes in production

• What you see: Content types and views edited on the live site.
• What it costs: Environments drift, the next deployment overwrites the change, and nobody knows what was altered.
• The fix: Change in development, export configuration, deploy through the pipeline. This is what the system is built for.

Hacking core or contributed modules

• What you see: Direct edits to core or module files.
• What it costs: Updates revert the change or are avoided, leaving the site unpatched.
• The fix: Use hooks, plugins or a patch managed through Composer so it is applied reproducibly.

Disabling caching to fix a bug

• What you see: Cache layers turned off because content was not updating.
• What it costs: Performance collapses, and the underlying cache metadata problem remains.
• The fix: Fix the cache tags and contexts. The system is telling you the dependencies are declared wrongly.

Unmaintained module dependencies

• What you see: Modules with no release for the current major version.
• What it costs: The site cannot be upgraded, which eventually means running without security support.
• The fix: Audit module maintenance status regularly and replace or take ownership of abandoned ones before an upgrade forces the issue.

Running an unsupported version

• What you see: A site on a Drupal version past end of life.
• What it costs: No security patches on a platform whose main markets are government and healthcare.
• The fix: Plan the upgrade as a funded project. Modern Drupal upgrades are far easier than the older major transitions were.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Drupal developer.

Junior

Builds sites through configuration and theming. Needs review on content modelling and on anything custom.

Mid-level

Writes custom modules, models content properly, and manages configuration deployment.

Senior

Owns content architecture, the module strategy, caching and performance, and the upgrade path.

Staff

Owns multi-site platform architecture, governance across teams, the accessibility and security posture, and the decision to stay on or move off Drupal.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New site build

• Usual team: One to two developers plus a designer.
• What governs it: Content modelling is the critical early work and determines how the site ages.

Major version upgrade

• Usual team: One to two developers.
• What governs it: Scoped by module compatibility and by whether core was ever hacked.

Multi-site platform

• Usual team: Two developers.
• What governs it: Shared configuration and governance are the hard parts, not the individual sites.

Decoupled implementation

• Usual team: One Drupal developer plus a front-end developer.
• What governs it: Two skill sets. Editorial preview is usually the underestimated piece.

Accessibility remediation

• Usual team: One developer with genuine accessibility experience.
• What governs it: Common in Drupal's markets, where it is frequently a compliance obligation.

Migration work you may actually be hiring for

A large share of Drupal work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An older Drupal major version to current

• Why teams do it: Security support and access to maintained modules.
• What to watch: Module compatibility is the constraint. Inventory contributed modules and check each for a current release before planning, because an abandoned module in the critical path is the thing that stalls these projects.

Configuration changed in production to version-controlled configuration

• Why teams do it: Reviewable, reproducible changes and environments that do not drift.
• What to watch: Export the current state first and reconcile the differences between environments, which is usually an uncomfortable exercise. Freeze production configuration changes once the pipeline exists.

Hacked core or modules to patches managed through Composer

• Why teams do it: Updates that apply cleanly instead of reverting local changes.
• What to watch: Identify every modification first, which on an old site is genuine archaeology. Contribute the fix upstream where it is general, since that removes the patch entirely.

Traditional Drupal to decoupled

• Why teams do it: A front end the theme layer cannot deliver, or several channels from one content source.
• What to watch: Editorial preview is the capability teams miss most. Solve it before committing, because Drupal's editors typically rely on it more than WordPress editors do.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Drupal developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Drupal version the site runs and whether it remains supported.
• Whether configuration is in version control and deployed through a pipeline.
• Whether core or contributed modules have been modified directly.
• How complex the content model is, since this is what distinguishes Drupal work.
• Whether multilingual or accessibility compliance is in scope, as both are core Drupal strengths and common requirements.
• Whether the site is decoupled or may become so.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Drupal work is counted by the US Bureau of Labor Statistics under Web Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Drupal developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 70,190 people in this occupation, with a median annual wage of $92,650.

The spread matters more than the midpoint. The 90th percentile is about 3.4 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Drupal developer can sit at $48,100 and $162,290 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Drupal frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Web Developers, the gap between the highest and lowest of the 27 metro areas covered here is a factor of about 2.3. San Jose sits at the top with a median of $166,670; Portland sits at the bottom with $73,920. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, Washington, D.C., Seattle, Portland each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

A small and senior hiring pool. Expect to pay accordingly and expect few juniors. Symfony developers transfer reasonably well.

Site builder presented as developer. Configuration skill and module development are different. Ask what they have written.

Sites stranded on old versions. Establish the current version before hiring, because an unsupported site is a different job.

WordPress experience assumed to transfer. Shared language, very different architecture. Drupal's entity system and configuration management have no WordPress equivalent.

Hiring Drupal developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Drupal developer who will be available.

• New York, NY $104,820 median
• Seattle, WA $130,440 median
• San Jose, CA $166,670 median
• Washington, D.C. $134,350 median
• San Francisco, CA $152,450 median
• Dallas-Fort Worth, TX $96,740 median
• Los Angeles, CA $107,290 median
• Boston, MA $108,520 median
• Chicago, IL $96,870 median
• Atlanta, GA $93,590 median
• Austin, TX $84,960 median
• Phoenix, AZ $76,230 median
• Philadelphia, PA $94,570 median
• Minneapolis-St. Paul, MN $106,890 median
• Denver, CO $92,060 median
• Detroit, MI $108,550 median
• Houston, TX $89,040 median
• Charlotte, NC $101,980 median
• San Diego, CA $98,300 median
• Salt Lake City, UT $88,770 median
• Miami, FL
• Portland, OR $73,920 median
• Baltimore, MD $107,590 median
• Tampa, FL $78,910 median
• Orlando, FL $83,820 median
• Raleigh, NC $82,250 median
• Kansas City, MO $89,420 median
• Pittsburgh, PA $82,560 median

Frequently asked questions

Drupal or WordPress?

Drupal when content is genuinely structured and relational, when you need granular permissions or serious multilingual support, or when accessibility and security requirements are strict. WordPress when the content is largely pages and posts and you want the larger, cheaper hiring pool. Drupal is more capable and more expensive to build and staff; using it for a brochure site is paying for capability you will not use.

Why are Drupal developers more expensive?

A smaller pool and a steeper learning curve. The architecture takes real time to learn, fewer people start with it, and the organisations using it tend to have requirements that need experienced people. That combination sustains higher rates, and it is unlikely to change.

How difficult are Drupal upgrades now?

Considerably easier than the older major transitions, which were effectively rebuilds and stranded many sites. Modern Drupal major upgrades are designed to be incremental, with deprecation warnings and tooling to identify what needs changing. The constraint, as with most platforms, is contributed module compatibility rather than core.

Is Drupal declining?

Its share of the general content management market is smaller than WordPress's and its position in government, education and large enterprise is stable. It remains the right answer for a specific set of requirements. The relevant risk is the size of the hiring pool rather than the platform's viability.

Can a WordPress developer work on Drupal?

With real ramp time. Both are PHP and both are content systems, and the architectures have almost nothing in common. Drupal's entity system, configuration management and Symfony foundation are all unfamiliar. A Symfony developer usually transfers to Drupal more readily than a WordPress developer does.

Why will our Drupal page not cache?

Usually cache metadata declared incorrectly, so the system believes the content varies by something it does not, or the page is marked uncacheable by a block or module. Drupal's cache system is precise and tells you what it depends on if you look. Turning caching off is the wrong response and unfortunately a common one.

Should we go decoupled with Drupal?

Drupal supports it well, with a genuine API-first approach. The question is the same as for any content system: you gain front-end freedom and you lose preview, immediacy and some of the editorial experience. For an organisation whose editors are a primary user group, which describes most Drupal deployments, that trade deserves careful thought.

What should we check before hiring for an existing Drupal site?

The version and whether it is supported, whether core or modules have been hacked, whether configuration is in version control, and which contributed modules have no maintained release. Those four answers tell you whether you are hiring for development or for remediation, and they change the brief substantially.