Drupal is dying
Not because it is useless. Because the incentives around it push buyers away.
Not because it is useless. Because the incentives around it push buyers away.
Drupal is one of the most capable content management systems ever built. It powers some of the most complex digital experiences in government, higher education, and enterprise. And yet, its market share is declining. New projects increasingly choose something else. The pipeline of new Drupal developers is thinning.
The instinct is to blame the technology. But the technology is not the problem. The ecosystem is.
The agency upsell machine
Drupal’s business model has always been indirect. The software is free. The money is in the services: implementation, customization, hosting, and ongoing support. This is true of most open-source CMSes, but Drupal’s complexity makes the services layer especially lucrative.
A typical Drupal implementation for a mid-size organization runs six figures. A large government project can run into the millions. The agencies that build these systems have a financial incentive to scope them as large as possible, to recommend custom modules over configuration, and to build architectures that require ongoing specialized support.
This is not a conspiracy. It is a market dynamic. The more complex the build, the larger the contract. The larger the contract, the harder it is for the client to switch. The harder it is to switch, the more leverage the agency has on the next contract.
The result is that many organizations’ experience of Drupal is not “powerful and flexible.” It is “expensive and dependent.” And that experience shapes their next buying decision.
The learning curve is a wall
Drupal’s learning curve has always been steep. But “steep” used to be acceptable because the alternatives were limited. If you needed structured content, granular permissions, multilingual support, and an extensible architecture, Drupal was one of the few options that could deliver.
That is no longer the case. WordPress has matured significantly. Headless CMSes like Strapi, Sanity, and Contentful offer structured content modeling without the overhead. Static site generators handle the publishing use case with near-zero operational complexity.
Meanwhile, Drupal’s administrative interface still feels like it was designed for developers, not content editors. The terminology is opaque — “taxonomy,” “paragraph types,” “view modes” — and the editorial workflow requires training that simpler tools do not. Every time a content editor has to ask a developer how to do something that feels basic, Drupal loses a little more credibility with the people who use it daily.
The talent pipeline is drying up
New developers are not learning Drupal. They are learning React, Next.js, Python, and whatever framework is trending on social media this quarter. The Drupal developer pool is aging, and the pipeline of new talent is not keeping up with attrition.
This creates a compounding problem. As the talent pool shrinks, the cost of Drupal developers rises. As costs rise, organizations are even more motivated to choose something else. As fewer organizations choose Drupal, fewer developers see a reason to learn it.
The community is aware of this. Drupal 10 and 11 have made real improvements — adopting Symfony components, modernizing the theming layer, improving the API-first capabilities. But these improvements appeal to existing Drupal developers more than they attract new ones.
Where Drupal still wins
None of this means Drupal is bad software. For certain use cases, it remains the strongest option available:
- Structured data at scale. If your organization manages thousands of content items with complex relationships, taxonomies, and metadata requirements, Drupal’s entity system is genuinely excellent.
- Granular access control. Drupal’s permission system is one of the most sophisticated in any CMS. If you need role-based access at the field level, Drupal handles it natively.
- Government and compliance. Drupal has deep roots in government. FedRAMP-authorized hosting exists. Section 508 compliance tooling is mature. The security team is responsive and well-organized.
- Multilingual content. Drupal’s multilingual system is built into core, not bolted on. For organizations that publish in multiple languages, this matters.
If your organization fits one of these profiles, Drupal may still be the right choice. But you need to go in with open eyes about the ecosystem dynamics.
AI is accelerating the squeeze
The rise of AI-powered content tools is making simpler CMSes even more capable. WordPress plugins that generate structured content, headless CMSes with AI-assisted content modeling, and static site generators with AI-powered build pipelines are all reducing the gap between what Drupal can do and what lighter tools can do.
AI does not replace the need for structured data and governance. But it reduces the need for the complex editorial workflows that have historically been Drupal’s differentiator. If an AI assistant can help a content editor create well-structured, properly tagged, accessibility-compliant content in WordPress, the case for Drupal’s more complex content modeling becomes harder to make.
More importantly, AI tools are lowering the barrier to migration. Automated content analysis, schema mapping, and bulk migration tools make it easier than ever to move off Drupal and onto something simpler. The switching costs that kept organizations locked in are dropping.
What should you actually do?
If your organization is currently on Drupal, here is a practical decision framework:
Stay on Drupal if:
- You are using Drupal’s structured data capabilities heavily (content types, entity references, complex taxonomies)
- You have a reliable, cost-effective support relationship with a Drupal agency or an in-house team
- Your compliance and security requirements align with Drupal’s strengths
- Migration costs outweigh the ongoing maintenance costs
Plan a migration if:
- Your team struggles to make basic content updates without developer help
- Your Drupal maintenance costs are disproportionate to the value you get
- You are on Drupal 7 (end of life has passed — this is a security risk, not just a preference)
- Your content model is simpler than what Drupal was designed for
If you stay, modernize:
- Invest in Drupal’s API-first capabilities (JSON:API, GraphQL) to decouple your front end
- Simplify your content model — most Drupal sites have more content types and fields than they actually need
- Build editorial workflows that reduce developer dependency
- Start treating your Drupal instance as a data platform, not just a website
The real diagnosis
Drupal is not dying because it is bad technology. It is dying because the ecosystem around it — the agencies, the procurement patterns, the talent market, the competitive landscape — has shifted in ways that push buyers toward other options.
The software itself is more capable than ever. But capability has never been the whole picture. The total cost of ownership, the talent availability, the editorial experience, and the competitive alternatives all matter. And on those dimensions, Drupal’s position is weaker than it was five years ago.
Organizations that understand this can still get tremendous value from Drupal. They just need to be intentional about it, rather than defaulting to it because it is what they have always used.