Drupal to WordPress Migration: When Downgrading Is Right

Nobody in the Drupal world calls it a downgrade out loud, but that is the word in the room whenever a Drupal site moves to WordPress. It is the wrong word. A platform is not better or worse in the abstract; it is better or worse for a set of requirements, and requirements change. The organisation that needed Drupal in 2017 — four editorial teams, three languages, a legal review step on every page — is sometimes the organisation that has two marketers and a blog in 2026, paying enterprise-grade maintenance for a site nobody edits in an enterprise way.

We build on both. That matters here, because most articles on this question are written by whichever side wants the migration budget. Read the rest as an attempt to be fair to the platform you are leaving.

The size of the two worlds

WordPress powers roughly two in five of all websites and well over half of every site that uses a CMS at all. Drupal is under one per cent of the web. Those numbers say nothing about which is the better tool for a given job, and a great deal about hiring, plugin availability and what your next agency will already know.

The practical consequence: a WordPress developer is easier to find, cheaper, and replaceable. A Drupal developer is a specialist, and specialist is the polite word for scarce. If your platform decision comes down to “who will maintain this after the current team leaves,” that gap decides it more often than any feature does.

When moving to WordPress is the right call

Your content is pages and posts, not a model. Drupal earns its complexity when content is structured: products with forty typed fields, events with recurrence rules, research with citations and versions. If your site is articles, service pages and a contact form, that structure is scaffolding around nothing.

Nobody uses the workflow. Open your instance and count: how many editorial roles exist, how many workflows have more than a draft-and-publish step, how many revisions were ever reverted. If the answers are one, none and never, you are maintaining a governance system for a team that does not need governing.

Marketing owns the site. When the people changing the site daily are marketers rather than developers, WordPress’s editing model and its enormous plugin ecosystem win on speed of change. Landing pages, forms, A/B tests and campaign integrations are hours in WordPress and tickets in Drupal.

The maintenance bill is the biggest line. Drupal’s security cadence is excellent and it is not free: someone has to apply it, test it and know what they broke. If the retainer that keeps the site patched costs more than the site earns, that is the decision, made for you. Our piece on what Drupal maintenance actually costs gives the range.

When it is a mistake

You have real multilingual requirements. Not “we also have a French page” — many locales, shared content models, translation workflows. Drupal does this in core; WordPress does it with plugins that each make different assumptions, and the migration will find every one of them.

Structured content feeds other systems. If an app, a partner API or a second site consumes your content, Drupal’s entity model and JSON:API are doing work you will have to rebuild.

Permissions and audit matter. Government, education, regulated industries: field-level permissions, immutable revision history and an audit trail are why those sectors chose Drupal, and they still hold. Our comparison for government and higher-ed covers this in depth.

The site is large. Tens of thousands of nodes with taxonomies and references do move to WordPress, but the flattening is real work and the URL discipline has to be perfect. The reverse journey, WordPress to Drupal, is the one people usually take at that scale, and for a reason.

What the migration actually involves

Every Drupal to WordPress migration is the same shape: a rich content model being flattened into a simpler one, and the whole job is deciding what to keep, what to merge and what to let go.

Content types become post types. Article and page map cleanly. Custom types become custom post types, or collapse into pages with a category, depending on whether anything still needs their fields.

Fields become meta or blocks. Drupal’s typed fields land either as post meta — Advanced Custom Fields is the standard route — or as Gutenberg blocks when the field was really a layout element. Paragraphs are the hard case: a page built from twelve paragraph types has to be rebuilt block by block, and it is a rewrite disguised as a migration.

Taxonomy is the easy part. Vocabularies become taxonomies, terms become terms. Hierarchy survives. Term references become term assignments.

Users and roles need a decision. Drupal’s granular roles compress into WordPress’s five. Decide who becomes an editor and who becomes an author before the migration, not after.

Media has to be moved, not linked. Files in sites/default/files must land in the WordPress uploads tree with every reference in every body rewritten. Missed references are the most common post-launch bug we are asked to fix.

Views become queries. There is no Views in WordPress. Every listing, feed and filtered page becomes a template with a query, or a plugin, and each one is a small development task. Count them before you quote.

URLs are non-negotiable. Pathauto patterns in Drupal produce URLs that WordPress will not generate on its own. Either configure permalinks and slugs to reproduce them exactly, or map every old URL to its new one with a 301. There is no third option, and getting this wrong is how a migration loses rankings. We have moved more than 50,000 pages between platforms without losing a ranking, and the entire trick is the URL map.

What you lose, honestly

Configuration management: Drupal’s exportable config has no real equivalent, and environment-to-environment deployment gets more manual. Revision workflows: WordPress keeps revisions, but moderation states, scheduled transitions and per-role publishing are plugin territory. Entity references as a first-class idea: relationships between content become meta fields and convention. Field-level permissions: gone. If any of those was load-bearing, revisit the section above.

What it costs and how long it takes

Less than the reverse direction, usually, because you are simplifying. The content move is the smaller part; the rebuild of listings, layouts and integrations is the larger, and the URL map plus testing is the part that cannot be rushed. A content-led site of a few hundred pages is weeks. A site with custom types, Paragraphs and Views is months, and the honest estimate comes from counting the Views and the paragraph types, not the pages. Our migration cost breakdown applies in both directions.

The test before you decide

Do the audit before the arithmetic. Count the editors who logged in last quarter, the workflows with more than one step, the content types with more than one instance, and the Views. If those numbers are small, WordPress is not a downgrade; it is the platform you actually run. If they are large, the migration will cost you the things Drupal was quietly doing, and you will notice them about a month after launch.

Gspikes builds and maintains both platforms, and we have told organisations to stay on Drupal when the audit said so. If you want an honest read on which platform your requirements actually need, send us the site and we will tell you. More on how we work on our Drupal development page, the same decision in the other direction in our WordPress to Drupal guide, and the numbers in what a website costs a small business.