Most Drupal to WordPress migrations that go wrong do so for the same handful of reasons. The content arrives on the new platform missing fields or broken formatting. URLs change without redirects in place, so pages that ranked well in search simply vanish. Custom functionality that worked reliably in Drupal gets approximated rather than properly rebuilt in WordPress, and behaves differently in ways nobody notices until a client reports a problem weeks after launch.
None of these are inevitable. They are the predictable result of treating a Drupal to WordPress migration as a content copy rather than a platform rebuild, and of underestimating what is actually involved. This guide covers what a proper Drupal to WordPress migration looks like, what typically goes wrong, and what to look for when choosing someone to do the work.
When migrating from Drupal to WordPress makes sense
The most common trigger right now is Drupal 7’s end of life in January 2025, which means sites still running on it are no longer receiving security updates. Drupal 10 also reaches end of life in the second half of 2026, adding a second wave of organisations facing the same decision.
But end of life pressure is not the only reason to migrate. WordPress makes sense over staying on Drupal, or upgrading within Drupal, when the organisation needs non-technical staff to manage content without developer involvement, when the long-term cost of Drupal development resource is out of proportion to what the site actually does, or when the plugin and theme ecosystem in WordPress covers the functionality requirements more efficiently than custom Drupal module development would.
It does not always make sense. Drupal is genuinely the right choice for highly complex, enterprise-grade platforms with sophisticated access control, multilingual requirements, or unusual content architecture. Migrating those to WordPress for the wrong reasons creates new problems in exchange for solving old ones.
What a proper migration involves
A well-executed Drupal to WordPress migration follows five stages, and cutting corners on any of them creates problems that surface later.
Discovery and audit. Before any build work begins, the existing Drupal site needs a thorough audit: content types, taxonomies, custom modules, URL structure, user roles, any third-party integrations. This is what the migration plan is built from. Skipping it means discovering surprises mid-build rather than before the first line of code is written.
WordPress architecture. Drupal’s content model does not map directly to WordPress. Content types become custom post types, taxonomies need to be recreated, Drupal Views need to be rebuilt using WordPress queries or plugins, and any custom module functionality needs an equivalent, whether that is a bespoke plugin, an off-the-shelf solution, or a combination of both. Getting the architecture right before building saves significant rework later.
Theme development. Whether the design is staying the same or being refreshed, a new WordPress theme needs to be built from the ground up. A Drupal theme cannot be transplanted to WordPress. The theme build is typically the largest single element of a Drupal to WordPress migration project.
Content migration. This is where most migrations run into trouble. Simple sites with a handful of pages can be moved manually. Sites with thousands of nodes, complex field structures, user accounts, or structured content relationships need a properly built content importer that maps Drupal’s data structure to WordPress correctly. Plugins like FG Drupal to WordPress handle basic content, but anything beyond standard pages and posts usually needs custom work.
Testing and launch. Before going live, every redirect needs to be in place, every piece of migrated content needs to be checked for formatting integrity, and the full site needs to be tested across browsers and devices. The launch itself needs to be coordinated carefully, with DNS cutover planned and post-launch monitoring in place to catch anything missed.
What gets missed in a bad migration
The four areas where a Drupal to WordPress migration most commonly goes wrong are content, URLs, SEO metadata, and custom functionality.
Content migration errors range from missing fields and stripped formatting to broken media attachments and incorrect relationships between content types. These often go unnoticed until someone tries to edit a page and finds it in a different state to how it appeared on the front end.
URL changes without redirects are the most damaging mistake a migration can make. Every URL that existed on the Drupal site and has been indexed by Google needs either to be preserved exactly or redirected to its WordPress equivalent with a 301 redirect. Without this, every indexed page becomes a 404, organic traffic drops, and rankings that took years to build are damaged or lost entirely.
SEO metadata, page titles, meta descriptions, canonical tags, and structured data need to be migrated and checked, not assumed to carry over automatically.
Custom Drupal functionality, particularly anything built on Views, Rules, or bespoke modules, needs to be identified in the discovery phase and properly accounted for in the WordPress build. The assumption that a plugin will handle it is sometimes correct, but needs verifying before it is relied upon.
What to look for in a developer
The questions worth asking any developer or agency tendering for a Drupal to WordPress migration project are these: have you done this before at a similar scale, do you have your own content migration tooling or are you relying entirely on off-the-shelf plugins, how do you handle URL mapping and redirects, and what does your testing process look like before launch?
A developer who has delivered migrations at scale will have encountered and solved the content migration problem properly. They will have a view on what needs custom work and what can be handled by existing tools. They will treat URL mapping as a non-negotiable part of the project, not an afterthought.
If you are looking at proposals, the detail in the discovery and content migration sections of a quote tells you more about the quality of what you are likely to get than anything else.
I have delivered Drupal to WordPress migrations involving hundreds of thousands of content nodes and tens of thousands of user accounts, and have built my own importers from those projects that handle complex content structures more reliably than generic plugin solutions. If you are planning a migration and want to talk through the scope, get in touch. You can also read more about why Drupal 7’s end of life makes WordPress the right move for many organisations, or find out more about what to look for when hiring a freelance Drupal developer in the UK.
