Skip to main content

Drupal Competitors & Alternatives: Drupal Market Position in 2019

Believe it or not, these are common questions I’m asked by my clients.

"Who are Drupal’s competitors?"

"What does Drupal’s competition look like, in 2019?"

And these specific questions, at least to me, don't really make much sense. What do you mean — “Drupal’s competitors?

Drupal isn’t a commercial product or service, so I’m often a little perplexed by this choice of words. But after many conversations, I’ve come to realize what this question really means. Or rather, what you’re trying to ask!

“What are the alternatives to Drupal?”

And most likely, what you’re actually trying to ask is something more along the lines of:

“What alternatives to Drupal exist in 2019, and are reliable, secure, and feature-rich?”

Obviously, there are a few questions to ask at this point. Namely:

  1. What are the reasons you are looking for an alternative? ...and:
  2. What problems is Drupal causing you currently, that are pushing you to explore possible alternatives, or rather, “Drupal competitors”?

Okay, so now we have it narrowed down to a few key points. I feel that this is the best way to look at this question—by dissecting it.

It’s important to understand exactly what clients are asking, and why they’re asking it. And of course, if this question is being probed, this hints to me that there are some (probably several) reasons that users are perhaps disgruntled.

In this post, I’m going to:

  1. Attempt to understand the nature of these questions a little better,
  2. Try to diagnose exactly what kind of issues users may currently be having with Drupal, and:
  3. Understand why users might be exploring the possibility of a Drupal alternative, rather than trying to fix the issues they’re having with Drupal.

So let’s get straight into it.

Drupal Competitors & Alternatives: in 2019

As we all know, Drupal is a CMS heavyweight.

It’s a market leader.

And that’s a position Drupal’s held for the best part of the last 15-20 years (Drupal is over 18 years old by now). The CMS has a reputation, and not by any small means.

Drupal’s positioning in the content management market is significant, and holds a lot of weight. In fact, I’d say that over the years the CMS has actually detached itself progressively further from the traditional notion of a content management system.

If you look at all the other content management solutions currently available today, nothing compares.

Let me say that again.

No other CMS compares to Drupal.

I’ve been working with Drupal, and other content management systems (equally, by the way — I don’t think I hold an inherent Drupal bias) for over a decade. I feel as though I’ve developed quite a weighty level of experience, especially having worked with such a diverse range of clients.

I’ve worked with content management systems nearly every day, for the most part of the last decade.

In fact, once I jumped into the world of content management systems, my entire outlook on web development changed.

The simple things became so much easier, and meant I could really begin devoting my efforts toward working with more complex functionality and backend code. So far, so good.

Back to my point: I genuinely believe that Drupal is superior in functionality (and nearly everything else) to other CMS’s. Hold up, don’t shoot me just yet (maybe later, after you’ve heard what I have to say).

Let me explain.

Other popular (and open source) content management systems, the likes of WordPress or Joomla for example, do their jobs extremely well. I think that today, WordPress is an amazing piece of software.

And Joomla’s equally as good. But Drupal... stands out. And since it stands out to such a degree, I think it’s fair to say it holds a superior position when compared to its competition.

Just kidding.

Actually, I don’t believe that content management systems can be compared so easily. I don’t really buy the whole “WP vs Joomla vs Drupal vs everything else” thing.

I think each of these CMS’s were designed to meet the needs of a specific target audience, and that even today, they each continue to do so.

So what exactly am I saying?

I’m saying that in my opinion, Drupal is no longer a CMS.

If we’re using WordPress as a baseline example of what a CMS is, or generally “should be”, then Drupal really cannot be described as a CMS.

A better way to describe Drupal, particularly today, would be as a CMF.

What’s a CMF?

CMF stands for Content Management Framework.

Drupal, when compared to a CMS like WordPress, does not compare much in functionality. Drupal’s far, far superior.

Note that I’m only taking into account the bare, native state of each CMS. I’m not comparing the “potential end result” by use of a myriad of extensions and plugins.

WordPress makes it easy to create websites.

Drupal, on the other hand, makes it easy to manually create a solution to manage your website.

A simple breakdown might look like this:

Many WordPress sites work the same way, or at least, similarly in the backend. In order to extend WordPress you’ll most definitely be utilizing a combination of plugins and custom code.

But no two Drupal websites work the same way. For every Drupal-powered website, a developer (or site architect, or content manager, etc), will have to learn the workings of the site over and over.

And that is a truly beautiful thing, and one of the biggest strengths Drupal has to offer.

Drupal is not an easy, quick-to-deploy, cookie cutter solution to creating your next website.

Drupal is a tool that allows you to create highly intuitive, complex, and intricate websites or applications, often requiring a longer amount of time and a bigger budget.

Drupal isn’t really for small personal blog sites (great article on this here). But it’s great for larger, enterprise-level websites, perhaps corporate sites or high-traffic news publishers. These types of sites require a highly tailored architecture.

For sure, use WordPress for small simple sites and blogging. But for a large scale web-based project, Drupal’s often a great fit.

I think that now is a good time to bring up Joomla. It’s often seen as a midway point between WordPress and Drupal, and in many ways it is. But still, even as a Joomla expert, I don’t think it offers quite the level of flexibility and raw power that Drupal does.

Some really great posts on Joomla for further reading:

In other words, sites built using Joomla probably won’t be as cookie-cutter as those running WordPress, but equally wont be quite as unique (under the hood) as Drupal apps.

I’ve sidetracked. I’m sorry. But this is all relevant! It leads me straight back to my point, which is:

Drupal doesn’t qualify as a CMS when compared to the likes of WordPress, Joomla, and other similar codebases. Drupal is much, much more! And hence, my suggestion that Drupal qualifies far more as a content management framework, rather than a system.

Drupal’s not really a set-in-stone system. A better way to view it is as a framework for creating your specific “system”.

I think that once we establish this particular point, understanding things instantly gets a lot easier.

So, “Drupal competitors”?

At this point in the article, I can definitely say that if your site is something like a personal weekly blog, move away from Drupal and straight to WordPress!

It might be the single-most fulfilling decision you make. If you’re the owner of a small personal blog. If this is something you’ve been grappling with, treat this as your professional seal of approval to migrate your personal blog from Drupal to something simpler.

But that still doesn’t answer the main question. Not really. Not yet.

The big question is:

Why are larger, more complex sites and applications thinking about Drupal alternatives?

That’s really the juicy element to the question. Sure, small websites need to be easy to maintain and simple to update. I’m the first to advocate for that. But bigger websites... full-fledged applications of scale?

Clearly, WordPress isn’t going to cut it.

I know, I know. You’re keen for me to delve deeper into this part. So I will, right now:

The reasons you might be looking for an alternative to Drupal

Okay, so I feel that it’s only polite for me to insert a little disclaimer at this point in the blog post: from here on out, things are going to get a bit more (quite more) technical, analytical, and lengthy.

The thoughts I’m exploring from here on out are aimed a little more at developers, business owners, and those currently overseeing the use of Drupal for larger projects. Obviously, this demands that I get a little more into the raw nitty-gritty.

If you’re still interested, keep reading. If not, grab a coffee and skim through the rest! I’m sure there’s at least something you’ll find helpful.

So let’s analyze this a little more, digging a bit deeper. First, I’m going to analyze a few reasons why current users of Drupal might be looking for alternatives.

Essentially, it boils down to something very simple. There isn’t really much secret about the reasoning behind the seeking of an alternative. For these users, there is quite simply a need that isn’t being met.

That’s the only reason people seek an alternative, or in this case, a “competitor” to something. They have a need, and probably one that they feel is rather important, that they feel isn’t being met by their current application of choice: Drupal.

Houston, we have a problem.

I, however, with the help of a little analysis and research, have found some solutions.

First, let’s identify some key reasons that current Drupal users might be experiencing frustration.

  • They feel that their overheads for maintaining Drupal are too high
  • They don’t feel as though they are getting an adequate return on investment in using Drupal
  • They struggle to find and source Drupal specialists
  • They feel as though there is a discrepancy between the power and flexibility required for their project and the solution Drupal is currently providing them.

I think this list sums up the core reasons that current Drupal users may potentially experience frustration, if they’re looking for an exit. Of course, it’s not this way for the majority, or else we’d be seeing a massive decline in Drupal adoption. And, as we already know, that’s not the case in 2019.

In respect to sourcing Drupal specialists and developers who are proficient in the CMS, holding both adequate experience and development prowess, I personally see this as a non-issue.

I’ve been working with Drupal for a long time. And in all my time, I don’t believe I’ve ever seen any credible evidence that there is a shortage of talented architects and developers within Drupal’s ecosystem.

I have heard plenty of others talk about this, though. But here are my personal thoughts:

Sure, many organizations struggle to source them — I’m very aware that this is a difficulty. But as far as I’m concerned, this doesn’t mean there is a lack of them.

The top Drupal specialists are already in high places. And personally, I don’t think that dramatically increasing the number of low-level to mediocre developers in the space really solves the problem.

We’re talking enterprise level projects here; not small business. The decision makers and project managers in these organizations need to be able to differentiate the minority, and subsequently scout them.

I think that, in this regard, the Drupal ecosystem is quite different than the likes of “competing” content management systems, where developers holding a lack of credentials and competence is ripe.

Really, I can’t imagine how many WordPress developers promote themselves as “enterprise experts” and don’t have much experience beyond the development a small business WordPress blog.

The solution to this problem? I think it’s really quite simple. I’d encourage decision makers to perform deeper research, analyze results, and see real evidence of competence in developers they’re looking to scout.

Then we have the possibility that Drupal isn’t meeting a functional need.

And to that, I say it could be a problem relating to the nature of content management systems in general, and their suitability to your specific use case.

As far as CMSs go, Drupal’s pretty darn powerful. Drupal 8 was completely re-written, using the Symfony framework, no less. In terms of raw power, as a content management system (or framework), Drupal clearly takes the cake, and everybody knows that.

If it isn’t meeting a technical need, I find it far-fetched to assume that any of Drupal’s “competing” softwares (cue WordPress, for instance), is going to handle this any better.

If there genuinely is a grave limitation, or working around this limitation would require a relatively significant investment, it might be time to consider whether a CMS is the desired solution for your app at all.

Of course, this is entirely dependent on the situation and use case, but I can’t rule out that it could indeed be a case of Drupal — or any CMS — is under-qualified (a great post that explores this more: When to Use a CMS and When Not To.

While it’s my personal belief that Drupal (particularly in versions subsequent to D8) can be configured and extended in such a way that it’s able to perform for the majority of complex web-based solutions, there’s a point at which the cost of this could indeed become irrational.

But of course, this is again entirely dependent on the use case, and that is something that can only be determined on a case-by-case analysis.

But that still leaves us with a couple other potential issues that larger businesses face with Drupal. And these are a little more financial.

Drupal: From a ROI Perspective

For many, the return on investment that Drupal provides is absolutely paramount.

In fact, here at Cocoon, we work heavily with Drupal, both internally and to power the sites and applications of many of our clients.

For us, seeing a great return on investment from Drupal development (and related areas) is really important. In fact, we provide Drupal solutions to thousands of businesses.

Quite honestly, we’d be the perfect candidate if somebody were to conduct a study of ROI and the use of Drupal.

But obviously, we already monitor this ourselves, and our continued, and broad use of the CMS speaks volumes. But just because it works well for us and our clients, doesn’t mean it necessarily would for everybody.

ROI is important for nearly everybody in the chain, because it affects every area of an organization, whether directly or indirectly:

  • Business owners
  • Executive board
  • Shareholders and investors
  • Human Resources
  • Financial and accounting departments
  • Employees
  • Audience

Of course, the biggest impact is felt and recognized higher up the chain, faster than down below.

But it doesn’t really matter where you look, it’s going to have an impact everywhere in a business.

The efficiency of any digital solution that a business employs is linked to ROI, and ROI is linked to every other area of the business. If you have finances leaking in one area, everywhere else will feel an impact by the perceived “domino effect”.

But that’s just basic business. Of course, it gets a lot more complicated than that.

Having worked with Drupal (and the CMS’s competition) for so long, I’d say I’m quite experienced in assessing the return that Drupal is providing an organization.

It’s one of the key factors to consider, particularly for larger businesses. As a specialist Drupal agency, we have to make this consideration every time we onboard a project.

Not for us, per se, but in the interests of each client, specifically.

Whether they’re using Drupal or an alternative solution, it’s often our responsibility to determine the efficiency of the current solution, and analyze whether this provides the great possible return for the business, while taking other important factors into account.

We wouldn’t want to compromise efficiency, stability, or user experience for the sole purpose of financials, for example.

But a holistic approach that takes everything into account respectively is certainly required. So that’s what we do.

Personally, from my experience (and I have a lot of it!) Drupal on its own is capable of providing a return far superior to anything else that comes close to the CMS, in terms of functionality and stability.

Particularly for businesses that require a PHP based framework or solution, Drupal’s most often the best placed candidate. But then again, I’ve been witness to some shocking results achieved with Drupal, which I really don’t believe provided the business with a healthy return.

At least, not one that I personally found satisfactory or desirable. But usually, there’s a trend that these kind of solutions follow. They use Drupal wrong.

Not that you can inherently use the framework “incorrectly”, but the methods that they were using in Drupal were most certainly not the right ones, when viewed at purely from a ROI perspective.

In fact, these solutions weren’t even providing a satisfactory result for the end user of the service. Quite honestly, I have no idea who the solutions were supposed to be providing value for.

But the way I looked at it, I couldn’t see any conceivable value being added to either the business, its staff, or its audience. And when that’s the case, it’s quite unlikely that you’re going to see a healthy return anywhere in that part of the solution.

In fact, it can drag everything down with it.

The result?

Drupal appears to be providing a vastly negative return on investment, and it’s felt by everyone. Not cool.

But fundamentally, Drupal itself is not at fault here. Rather, somebody has got themselves into a pickle at some point during architecting or engineering of the solution.

And that leads to leakage, which inevitably leads to poor performance, both technically and, more chronically, financially.

This is often where it’s my job to step in. In fact, that’s what I do as a day job. I assess the performance of Drupal solutions in order to help businesses identify where they’re losing power, and cash.

So, what have we learned?:

Drupal Performance, Cost & Return

Drupal is often not itself a cause of performance issues! But there’s quite probably something that’s been engineered or built “into”, or “on top” of Drupal, which is responsible for poor financial performance.

Poorly built (and maintained) solutions can wreak havoc with the checkbook. Trust me on that one, I’ve seen it many times.

Again of course, this particular analysis won’t always be the case. There are indeed occasions where a software is “forced” into behaving a certain way, and in spite of its power and flexibility, there are indeed certain situations and environments where Drupal is simply not the best fit.

Usually, though, this will indicate that a content management system in general is not technology-sufficient for the solution… which means that there have probably been mistakes in planning which date right back to the inception of the project.

A CMS is not always the most suitable solution! Content management systems don’t fix all problems.

They’re fundamentally designed to manage content, as is advertised on the tin, so to speak.

In my time I’ve experienced many colleagues who are so fluent in content management systems, and have learned that they can be twisted and bent into behaving in certain ways, in order to “get the job done”, regardless of the complexity of a project, but it’s just not always a case.

If anything, this view point is a little foolish, or perhaps, ignorant. Almost, biting off more than can be chewed.

Drupal is indeed a powerful force, and one to be reckoned with, at that, with the latest iterations of the CMS able to function very proficiently as a decoupled/headless solution, and RESTful services now a standard feature of Drupal 8 (and beyond).

But—if maintaining headless Drupal costs an organization more than it would to build, develop and maintain a custom, fitting RESTful solution, and there is no inherent need to run Drupal — and particularly if Drupal does not already form part of the organization’s infrastructure (for other use cases), its use should seriously be considered.

As they say (and I’m sure you’ve heard it many times), don’t try to kill a mosquito with cannon.

And this applies in reverse, too. Don’t attempt to destroy a cannon with a mosquito.

Or, possibly better put, don’t compare apples with oranges, and know the tools in your arsenal.

Now, let’s explore some of the potential reasons why users who aren’t currently using Drupal may be looking for alternatives (or “competitors”):

Obviously, users in this category either have previous experience using Drupal, or they’re aware of the capabilities of the CMS. They know Drupal is powerful, but there’s something they are hesitant about.

For users such as this, there’s some kind of barrier preventing them from immediately identifying Drupal as the desired solution, and pushing them to explore direct competitors.

We know this. For a fact.


Because they’re asking for a Drupal competitor (or alternative). Not a “powerful application framework”, but a direct “alternative to Drupal”. It’s clear, by the choice of wording, that they are already acutely aware that Drupal can solve their potential problem, but there is something holding them back.

Something, somewhere is causing them to push down a little on the brakes. But why? What exactly is the issue? Let’s explore this by delving deeper.

Ultimately, Drupal’s press is bad.

That was a little harsh (sorry Drupal).

What I mean to say, is that the general hubbub around the software, for the best part of the last eight (or so) years, has been largely skeptical.

The worldwide development community has long seen Drupal as a software which is out of their reach. A bit like imposter syndrome, many developers, both software and web developers, perceive Drupal as a tool that’s too complex for them to work with effectively. Some great relevant articles are:

And it’s true, Drupal isn’t anywhere near “competitors” (I hate using this term), in terms of feature availability and potential use cases — Drupal is far superiorly positioned.

Drupal is an enterprise CMS.

It works as a platform to build powerful, diverse web applications. It’s not "just PHP”, for goodness sake—that’s absurd.

From a personal perspective, I think that there is an ingrained belief that developers often pull out when arguing against Drupal — they perceive that the framework is “clunky”, “bulky”, “heavy”, “bloated”.

They think that it’s difficult. Not just to work with, but to maintain.

I’ll be honest, and I’ll try to be non-biased. I get what they’re saying.

But as of Drupal 8, and beyond, the software has been rewritten on the Symfony framework, which is a great alternative to, say, Laravel.

A lot of people in software still see Drupal as a regressive PHP software. The thing is, it’s neither of these things.

I’m not afraid to shy away from the fact that this was very much the case in Drupal 6, and perhaps even in Drupal 7, but from the release of Drupal 8 in 2015, Drupal has shifted incredibly in both of these regards.

Today, Drupal is more progressive than ever.

Many companies are integrating artificial intelligence into Drupal. Some are using it as the backend to powerful mobile apps. Businesses are using it to deliver intricate enterprise solutions to global audiences.

In fact, there’s never been a time like now for Drupal. More companies than ever are building their businesses directly around the providing of Drupal related products and services. Just look at organizations like Pantheon.

They’re a (fairly new) integrated hosting platform, specifically for Drupal. They launched in 2010.

Or look at Rackspace, who is an industry leader in enterprise-class hosting and application solutions, who offer services specifically for enterprises using Drupal.

Things are very different now.

The codebase is refined, not that it was too bad to begin with. But it’s better.

Another common concern I’ve encountered is regarding the viability of Drupal support over the longer term… whether or not the software makes for a good, stable long-term investment, or not.

There’s no doubt, Drupal is a niche area, especially when it’s up for competition against powerful frameworks like Laravel and software such as Mura CMS (which is again, more of a framework than a CMS, built on CFML).

In fact, I have written a good article on this here, you might find it a little eye opening.

Verdict: State of Drupal & Drupal Competitors

I’ve never liked “CMS comparison” discussions. I don’t think they make any sense.

And I think in 2019, it’s high time we stopped having them.

Software that doesn’t work for people will die out, as part of the natural process of the development lifecycle, and due to the increasingly prevalent shifts toward progressive web applications.

Forum CMS phpBB is Dead: a Case Study

Take phpBB, for example. In its heyday, it was one of the most powerful applications for building internet forums, bulletin boards and communiy discussion websites.

Today though, with such a rise in businesses opting to use social media and direct marketing to reach clients, discussion forums as a whole have dwindled (and died) in the eyes of so many. Or rather, everyone.

The growth of community discussion sites like Reddit, Quora, and StackExchange further fueled the slow, and inevitable death of the online bulletin board.

A great post that covers this topic in more depth: Are Internet Forums Dead in 2019?

phpBB3 was a great software, and still very much is, but its use been plummeting since 2013. And it's still falling.

I mean, just take a look, courtesy of Built With:

My personal prediction is that it will continue to fall. In fact, users of phpBB's community are worried about this themselves, and have seen it coming for years:

But this hasn't happened to Drupal.

And for what it's worth, the web development community has been crying over non-existent spilled milk for years, citing the impending "doom" of Drupal

Drupal, as a matter of fact, is one of the only content management systems that has shown initiative in adapting to support the significant movements within the web, software and application development industries.

Did you know that the world's leading blogging CMS, WordPress, is not SEO-friendly out-the-box? It's shocking.

WordPress SEO: a Case Study

With something so basic as SEO, you'd expect WordPress to outperform standard, static HTML, and you'd certainly expect it to be out-performing Joomla in terms of SEO.

Native SEO, from a CMS perspective, is something you'd expect out of the box. But for WordPress, you'd expect this to be even more so the case.

In 2019, both Joomla and Drupal outperform WordPress in terms of SEO. Not that native CMS SEO has much relevance to the development of enterprise-level solutions using Drupal, but this simply hammers home the point I'm trying to make:

Drupal is the most progressive web-based content management framework/system/tool that exists today.

RESTful services directly out-the-box, multisite configuration, decoupled Drupal, and configuration synchronization — these are all built-in tools, available natively in Drupal 8. That's hugely progressive.

As for WordPress, developers should be ashamed by the fact that it fails against both HTML and Joomla in terms of native SEO support.

WordPress is a blogging CMS, and blogging is synonymous with SEO. They go hand in hand. Pretty much directly. And it can't even nail this?

I think this simple fact just hammers home the message I'm trying to communicate: Drupal's market positioning is strong.

And I firmly believe (though I'm open to being proven wrong), that in the next few years, we'll start seeing an even greater increase in the adoption of Drupal 8 and 9 into corporate and enterprise infrastructure.

But as for this little case study, here's some absolute gold I found on WordPress's native SEO incapabilities:

ITD actually performed a study, with the sole aim of comparing Joomla and WordPress SEO, and here are their findings (I've skipped ahead a little bit in the video for your convenience):

Wrapping Up: There is no Drupal Competition

In conclusion, though, it's clear that Drupal is trying hard, and it’s paying off. With some of the world’s top organizations utilizing Drupal in 2019, I think it’s safe to say that the state of Drupal is on track to improve.

Not that it necessarily needs to (just yet), but I’m confident that with the impending release of Drupal 9, the software will continue on the right track. And that track is supporting the future of enterprise.

Let’s dedicate 2019 to new understandings, progressive development, and celebrating the state of Drupal.


— “Drupal competitors”: A nonsensical choice of words.
— “Drupal alternatives”: It’s about time you stopped looking.

Cheers, Drupal. Let’s continue working together.

Does your business use Drupal? Let me know why (or why not) in the comments.

Leave a comment