DuePress

Drupal to WordPress migration, without surprises

A Drupal to WordPress migration is mostly a decision about addresses and modules, not about content. Nodes, fields and taxonomy terms export cleanly and import reliably. Three things cost time instead. Drupal builds URLs differently. Every contributed module needs a WordPress answer that somebody chooses rather than converts. And a Drupal site of any age usually carries custom code nobody has read in years. This page sets out how we scope that work, and who it genuinely suits.

First step
A fit check, before any access
Costs nothing
Describing the problem is free
You keep
A written record of the work

Who this is for, and who it is not

Being direct here saves both sides a conversation.

This suits small and mid-sized Drupal sites. Association sites, small nonprofits, local government departments, a marketing site that outgrew the team behind it. Typically a few hundred nodes, a handful of content types, and nobody left in-house who writes Drupal.

It does not suit enterprise Drupal. A multi-site platform with custom modules, an integration layer and a procurement process is a different engagement, and the agencies who specialise in it will serve you better. If your Drupal estate reaches that size, we say so rather than take the work.

Why Drupal owners are moving

Two forces, and they compound.

Drupal 7 reached end of life on 5 January 2025. So a site still running it gets no security updates from the project. A few vendors sell extended support commercially, which buys time rather than solving anything. Our guide on what to do about Drupal 7 end of life lays out every option, including staying.

The second force is quieter. Modern Drupal is a different system from Drupal 7, so moving forward inside Drupal means a rebuild rather than an upgrade. Once the choice is a rebuild either way, owners ask where their team can actually publish. Many then pick WordPress. That is a real pattern rather than a sales line. When Drupal 7 sites moved, far more of them landed on WordPress than on modern Drupal.

What a Drupal to WordPress migration transfers, and what it decides

Transfers cleanly

Nodes and their fields, taxonomy vocabularies and terms, users, and files. Drupal describes its structured content well, so the export side stays more predictable than a website-builder move.

Has to be mapped, not moved

Content types become post types or page templates, and that mapping is a decision. Views have no direct equivalent, so we rebuild them as queries or archive templates. Contributed modules each need an answer: a WordPress plugin, a theme feature, or the honest conclusion that nobody uses the feature any more. That last outcome happens more often than owners expect, and it costs the least.

The part that decides your traffic

Drupal paths, path aliases and node IDs do not survive the move, so every address changes. Each one needs a redirect to its closest real equivalent. We build that map from a crawl of the live site, because a sitemap may be incomplete. Google’s site move guidance explains why this step carries your standing across.

How the work runs

Diagnosis first, as with everything here. Before a quote we establish the Drupal version, the content type and module inventory, the address count, and whether any custom module does something WordPress cannot.

That produces a written scope naming the exclusions. Scope matters more on migrations than on repairs, because undiscovered work turns a fixed price into an argument. From there we follow the sequence on the migration overview: inventory, structure, content, redirects, rebuilds, verification.

The Drupal site stays reachable until the WordPress one works. That order is reversible. The other one is not.

When staying on Drupal is the better answer

There are real cases, and omitting them would be dishonest.

Maybe you run a supported Drupal release. Maybe someone on your side knows Drupal. Maybe your content model genuinely needs what Drupal does well. Then moving buys you nothing you cannot already have. Drupal handles structured content and permissions better than WordPress does out of the box, so pretending otherwise would give you a poor reason to change platform.

Equally, you might be leaving because the site keeps breaking or feels unmaintained. That is a maintenance finding rather than a platform one, and it travels with you. Our guide on what actually breaks in a migration covers that failure mode and the rest.

What it costs

Drupal migrations vary widely, because the module inventory drives the work. Published figures skew high here. Most providers writing about Drupal migration describe enterprise engagements running into five and six figures, and those numbers are real for that size of site.

A small association site with four content types and no custom modules is not that job. A headline figure would either price out simple work or need revising upward, so we confirm scope and price in writing before implementation begins. Our pricing approach explains the reasoning, and the diagnosis has value even when the answer is that you should stay put.

Start with a diagnosis

Send the site address, the Drupal version, and a list of the modules you actually rely on. That is enough to scope the work rather than guess at it.

You get the address plan, the module replacements, the risks and the price in writing. Our published scope and how the process runs sit alongside it. Once the site runs on WordPress the maintenance obligation is continuous, so most people settle ongoing care at the same time. To begin, start a diagnosis.

Bring us the problem

Describe what you can see. You get a fit check first, then a diagnosis, then a scope and price in writing before anything on your site changes.

Describe the problem