Drupal vs WordPress in 2026: an honest comparison

Every Drupal vs WordPress comparison you can find was written by someone with a stake in the answer. Acquia is the Drupal company. Pantheon and WP Engine sell hosting for both and would rather you picked the one with the bigger bill. Gravity Forms sells a WordPress plugin. We sell neither platform, no hosting, no licences. What we do is break-fix and monthly maintenance on both, which means we see what each one costs after the launch party. That’s a different picture from the feature tables.

What lands in our ticket queue

WordPress tickets are frequent and small. A plugin auto-updated overnight and took the checkout with it. Someone installed a nulled theme and now the site serves pharma spam to Google but not to the owner. The host bumped PHP and a 2019 plugin fataled. Most of these are a one to three hour job, which is why our WordPress restoration work starts at $240 instead of a day rate.

Drupal tickets are rare and heavy. A Composer dependency deadlock where two modules want incompatible versions of the same library. A contributed module that was never ported and has no maintainer left. A site sitting three minor versions behind because nobody on the client side knew there was a release cadence to follow. When one of these arrives it is not a one hour job. Half a day is optimistic. Two days is common.

There’s a pattern under the WordPress ones worth naming. Almost none of the compromises we clean up came through WordPress core. They came through an abandoned plugin, a theme bought once and never updated, or an admin account with a password that appears in every credential dump since 2019. Core is patched fast and, since 4.7, patches itself for minor releases. The attack surface is everything bolted onto it, which is a maintenance problem rather than a software one.

The honest summary has nothing to do with which platform is more secure. WordPress breaks often and cheaply. Drupal breaks rarely and expensively. Which of those you’d rather budget for says more about how your business handles surprise than about anything in the code.

The upgrade tax nobody prices

Both platforms are free. Both have an extension ecosystem. Every comparison covers that ground. What almost nobody puts a number on is the major-version jump, and that is where the money actually goes.

On WordPress, major versions barely register. You click update, or your host does it for you at 3am, and the site keeps working. There have been exceptions. The block editor shipped in 5.0 and broke a lot of custom meta boxes. But a site built in 2020 will still run on current WordPress with no structural work.

Drupal signs you up for something else. The 7-to-8 jump was a rebuild rather than an upgrade, because the whole framework moved to Symfony. The project learned from that, and 8 to 9 to 10 to 11 are far gentler, with tooling like Upgrade Status and Rector doing real work for you. Gentler still means a scheduled project with a test plan, not a Tuesday afternoon. And Drupal 7 reached end of life in January 2025, so anyone still on it has a migration project rather than a pending upgrade. We wrote up what the modern jump actually involves in our notes on the Drupal 9 to 10 upgrade, and the sites that arrive already broken go through Drupal Rescue.

Price the upgrade tax before you pick the platform. A CMS that costs nothing to licence and a five-figure project every four years is not free.

Three years of running cost, from the invoice side

That last row decides more projects than any technical argument does. A WordPress site is a liquid asset. If your developer vanishes, the next one starts Monday. A Drupal site is illiquid. The people who can safely touch it are fewer, they charge more, and they are usually booked out. We have inherited Drupal sites where the previous agency held the only working copy of the config sync workflow, and reconstructing it cost more than a year of maintenance would have.

What each one asks of the server

This is the part the agency comparisons skip, because agencies don’t hold the SSH keys. We do, and the two platforms are not remotely equal tenants.

WordPress runs on anything. Shared hosting with 512MB and a modern PHP will serve a brochure site indefinitely. A page cache does most of the work, which is why LiteSpeed or Nginx microcaching in front of a modest box handles traffic that looks alarming on paper. When we move a WordPress site off shared hosting it is usually because of the neighbours, not the software.

Drupal asks for more before it behaves. A realistic PHP memory limit starts around 256MB and goes up from there. Composer has to run somewhere, either on the box or in a build step, so “upload the files by FTP” stops being a deployment method. Once you have logged-in users, the internal page cache does much less for you and you want Redis or Memcached behind it, which is another service to run, monitor and patch. Drush is the equivalent of WP-CLI and it is excellent, but it is one more thing the next developer has to know.

Both platforms also ship a cron implementation that fires on page requests, and on both it should be switched off and replaced with a real system cron entry. We do that on every box we take over, WordPress or Drupal, because a queue that only runs when someone visits the site is a queue that stops during the exact quiet hours you scheduled the backup for.

The consequence is a budget one. A $6 VPS runs WordPress properly. The same box runs Drupal in the sense that the pages load eventually. If you’re pricing a Drupal build, price the hosting it needs alongside it, and read our notes on moving from shared hosting to a VPS before you assume the cheap plan will stretch.

Where Drupal earns it

Drupal is worth its overhead when your content is genuinely structured, and it is the wrong tool when it isn’t. The cases where it pays:

• Multilingual sites. This is the clearest win. Translation lives in Drupal core, field by field, with its own workflow. On WordPress you’re running WPML or Polylang, which are good plugins doing a job the platform was not designed for. Launch in four languages and Drupal saves you real pain.
• Relational content models. Once you need entities that reference other entities, and Views to query across them, WordPress starts billing you in ACF configuration and slow meta queries.
• Field-level permissions. Drupal lets you say “this role edits this field on this content type.” WordPress needs a plugin for that, and the plugin needs maintaining.
• Editorial workflow. Revision states and moderation are core behaviour rather than an add-on.
• Procurement rules. Some public sector and university tenders name Drupal outright. Not a technical reason, but a real one.

Two or more of those describing your project means the overhead pays for itself. None of them means you are buying a truck to carry a laptop. Drupal’s security reputation is deserved, by the way. The security team is stricter and the contrib review process is real. But the sites we harden through Drupal security work get compromised through the same doors as everyone else’s: an unpatched module, a weak admin password, a stale server.

When we tell people to stay put

We get asked to move sites between the two more often than we agree to do it. Worth saying why out loud, because nobody selling migrations will.

Moving content between WordPress and Drupal is not a file transfer. Our fixed-price Migration Pack is $450 because a host-to-host move is a known quantity: same CMS, same database, new box. A cross-platform move is a different animal. You are rebuilding the content model, then the theme, then replacing every module or plugin with a counterpart that behaves differently, and then producing a redirect map so you don’t hand your rankings back to Google. That is a rebuild with a migration’s paperwork attached.

The test we apply is simple. If the reason for moving is that the current platform is annoying, stay. If the reason is that you cannot do the thing the business needs on this platform and you have genuinely tried, move. Annoyance is cheap to fix. Structural limits are not.

Drupal 7 is the one case where we don’t argue. It’s an unsupported codebase with no security coverage. Something has to happen, and the only open question is whether it goes to modern Drupal or to WordPress.

Starting from zero

With no existing site and a decision to make today, our default is WordPress. The software is plainly worse at structured content. It wins anyway, because your bench is bigger, your incidents are cheaper and your platform risk is lower. WordPress runs roughly 43% of the web. Drupal sits under 1%. That gap is a hiring pool.

Pick Drupal if you hit two or more of the conditions above, and pick it with your eyes open. Budget the upgrade cycle from day one, and make sure the config export lives in your repository rather than in your agency’s head.

What we won’t do is tell you that it depends on your needs and leave you there. It depends on four questions: how many languages you publish in, how relational your content really is, who maintains the site in year three, and what happens the day that person leaves.

What we’d say on a call

We run both. Our WordPress support work is the busier side by volume. Our Drupal support work is the one where a single ticket can save a site that has been quietly unsupported for two years. If you already have a site and you’re wondering whether to move it, send us the URL and the version number. Ten minutes of looking tells you more than another comparison table, including, quite often, that you should leave it exactly where it is.