WordPress to Drupal Migration: The Honest Guide

We build on both platforms, which means we have no particular stake in where you land. That is the only reason this guide is worth reading: most articles with this title are written by Drupal shops, and they all reach the same conclusion.

Ours does not. The honest answer for the large majority of WordPress sites is that they should stay on WordPress. What follows is how to tell whether yours is one of the exceptions, and what the move actually costs if it is.

Most WordPress sites should not migrate

WordPress runs a very large share of the web because for a very large share of the web it is the correct tool. If your site is a marketing site with pages, a blog, a contact form and a handful of integrations, Drupal will not make it faster, cheaper or better. It will make it more expensive to maintain and harder to hire for.

The bad reasons we hear most often: “WordPress isn’t enterprise”, “we got hacked”, and “our site is slow”. None of those survive contact with the facts. Enterprise is a procurement word, not a technical one. Almost every WordPress compromise we have investigated came in through an abandoned plugin or an unpatched host, both of which have exact equivalents in the Drupal world. And slowness is nearly always hosting, bloated page builders, or unoptimised images — all of which you can fix on Monday without changing CMS.

Migrate for those reasons and you will spend a five-figure sum to arrive at the same problems in an unfamiliar codebase.

The four situations where Drupal genuinely wins

Complex, related content. When your content is not “posts and pages” but a graph — courses that belong to departments that have staff who teach other courses — Drupal’s entity and field system models that natively. In WordPress you reach for custom post types plus a field plugin, and end up maintaining a content model that lives half in code and half in a plugin’s interface.

Serious editorial workflow. Moderation states, revisions with real diffs, per-role permissions on individual fields. Drupal ships this. WordPress bolts it on.

Multilingual as a first-class requirement. Not a translated menu — genuinely different content per language, translated taxonomies, per-language workflow. Drupal core does this. On WordPress it is a paid plugin your entire site then depends on.

Governance and audit requirements. Public sector, higher education, healthcare, finance. Where you must demonstrate who changed what, when, and who approved it, Drupal’s permission granularity is the difference between a compliant site and a spreadsheet of promises.

If you did not recognise your organisation in at least one of those, stop here. You have your answer.

What actually moves, and what gets rebuilt

The word “migration” makes people picture content flowing from one box into another. Some of it does. Most of the effort is not that.

Content moves reasonably well. Posts, pages, taxonomy terms, users and media are what Drupal’s Migrate API is for, and there are established source plugins for WordPress. Given a clean export, the raw content is rarely the hard part.

Everything around the content gets rebuilt. Your theme does not port; it is rewritten. Your page-builder layouts do not port — if the site was built in Elementor or Divi, that markup is meaningless outside WordPress and every page has to be reconstructed as a Drupal layout. Your forms get rebuilt. Your plugin behaviour gets rebuilt or replaced.

Budget accordingly. Content migration is often ten to twenty per cent of the work and the rebuild is the rest. Anyone quoting this as though it were a data transfer has not looked at your site.

The content model is the real project

This is where migrations succeed or quietly fail, and it happens before anyone writes code.

WordPress encourages a flat model. You have posts, you have pages, and when you need something else you add a custom post type with a pile of custom fields. Over five years that accretes: fields nobody fills, three different ways of marking something “featured”, taxonomies that overlap.

Drupal will faithfully reproduce that mess if you let it. The value of a migration is the chance not to. Before mapping a single field we inventory every content type, every field, and how often each is actually populated. It is normal to find that a third of the fields on a mature WordPress site are empty on more than ninety per cent of records. Those do not get migrated. They get deleted, and the argument about whether to keep them is the most valuable conversation in the project.

Skip this step and you pay Drupal’s complexity cost without collecting any of its benefit.

Plugins do not have module equivalents

Expect to be asked “is there a Drupal version of X?” for every plugin you run. Sometimes yes. Often the same job is done differently, and occasionally it is not done at all without custom work.

Some map cleanly enough. Yoast or Rank Math becomes Metatag plus Pathauto plus Simple XML Sitemap — three modules doing one plugin’s job, and configured properly they do it better. Contact Form 7 or Gravity Forms becomes Webform, which is more capable than either. Advanced Custom Fields becomes Drupal core fields, which is where Drupal is strongest.

Some do not. WooCommerce to Drupal Commerce is not a migration, it is a re-platform of your entire store with its own timeline and its own risk. Membership plugins, booking systems and anything holding years of transactional data deserve their own assessment before the main project is scoped.

Make that list early. It is the most common source of mid-project surprises.

Protecting the traffic

A migration that loses rankings has failed, whatever else it achieved — and this is the part most often skipped, because it produces nothing anyone can see.

Freeze a baseline before anything changes: a full crawl of the old site, Search Console data for both queries and pages, backlink data, and analytics landing pages. You cannot demonstrate that you protected traffic without a record of what you had.

Then build a complete URL inventory and map every old URL to exactly one new URL with a single-hop 301. Not a chain, and never a bulk redirect of retired pages to the homepage — Google treats that as a soft 404 and the equity evaporates anyway. Where WordPress permalinks differ from Drupal’s path patterns, Pathauto can usually be configured to reproduce the old structure exactly, which is far safer than redirecting at scale.

After cutover, re-crawl at twenty-four hours, seven days and thirty days, and watch Search Console coverage and 404 reports daily for the first week. Ranking damage from a migration typically surfaces three to four weeks out. Check only at launch and you will find out in the next quarterly report, when it is much harder to unpick.

So should you?

Probably not, and we would rather say so now than three months into a project. Migrate when your content model has genuinely outgrown WordPress, when workflow or multilingual or governance requirements are real rather than aspirational, and when someone will still own the site in two years. Those are good reasons, and the move pays for itself.

Migrate because Drupal sounds more serious, and you have bought a more expensive version of the same website.

Gspikes builds and maintains on both WordPress and Drupal, and we have talked as many clients out of this migration as into it. If you want an honest read on which side of the line your site falls, send us the URL and we will tell you — including when the answer is to stay put. More on how we work on our Drupal development page.