Content migration is the part of a Drupal to WordPress project that gets underestimated most consistently. The assumption is that moving content from one CMS to another is a relatively straightforward technical task. In practice, it is usually the most complex and time-consuming part of the whole project, and the part most likely to cause problems that only surface after launch.
This post covers what actually happens to your content during a Drupal to WordPress migration, what typically goes wrong, and what a properly handled content migration looks like.
Why Drupal content does not move cleanly to WordPress
Drupal and WordPress store content in fundamentally different ways. Drupal is built around a highly flexible content entity system, where content types can have any number of custom fields, each storing different data types: text, files, references to other content, taxonomies, and more. WordPress uses a simpler post-based model with a more limited native field structure.
The result is that a direct database transfer between the two platforms is not possible. Every piece of Drupal content needs to be mapped to a WordPress equivalent, field by field, content type by content type. Where Drupal has a field that has no direct WordPress equivalent, a decision needs to be made: recreate it using a custom field plugin like Advanced Custom Fields, rebuild it as a custom post type, or restructure how that content is handled in WordPress entirely.
What content migration actually involves
A properly handled Drupal to WordPress content migration involves several distinct stages.
Content audit. Before any migration work begins, the full scope of the content needs to be mapped: every content type, every field, every taxonomy, every media attachment, and every relationship between pieces of content. This is what the migration plan is built from. Skipping the audit means discovering unmapped content mid-migration rather than before any code is written.
Field mapping. Each Drupal field needs a corresponding destination in WordPress. Standard fields like title, body, and date map straightforwardly. Custom fields, file references, entity references, and structured field collections need to be mapped individually and their WordPress equivalents either identified or built before the migration runs.
Content importer development. For anything beyond a small brochure site, content migration needs a custom-built importer rather than an off-the-shelf plugin. Generic plugins like FG Drupal to WordPress handle standard nodes and basic fields, but fall short on complex field structures, custom content types, media handling, and taxonomy relationships. A custom importer is written specifically for the structure of the site being migrated, which means it handles edge cases rather than approximating them.
Migration testing. A migration importer needs to be run and reviewed before it is run on the live data. This means setting up a staging environment, running the importer, and going through the migrated content systematically to check that fields have landed correctly, media has transferred, relationships are intact, and nothing has been lost or corrupted in the process.
URL mapping and redirects. Drupal and WordPress use different URL structures by default, and even where they are similar, content paths often change during a migration. Every URL that existed on the Drupal site and has been indexed by Google needs to be mapped to its WordPress equivalent and a 301 redirect put in place. Without this step, every indexed page becomes a 404 after launch and search rankings built over years can be lost within weeks.
What goes wrong when content migration is handled badly
The most common content migration problems are missing or corrupted fields, broken media attachments, lost taxonomy relationships, and absent redirects. These tend to surface in a predictable pattern: the site launches, looks fine on a surface-level review, and then problems are reported by editors trying to update content, or by a sudden drop in organic traffic as 404s accumulate in Search Console.
Fixing content migration errors after launch is significantly more expensive than getting it right before. The content often needs to be re-migrated, redirects need to be audited and rebuilt, and any SEO damage from the 404 period takes time to recover from regardless of how quickly the technical issues are resolved.
What a well-handled content migration looks like
I have delivered content migrations at considerable scale, including platforms with hundreds of thousands of content nodes and tens of thousands of user accounts. For projects of that complexity, off-the-shelf migration plugins are not a realistic option. I have built my own Drupal to WordPress content importers from those projects, written specifically to handle complex field structures, media relationships, and taxonomy mappings that generic tools cannot manage reliably.
That means the content migration itself is a known quantity rather than something that needs to be figured out from scratch. The importer is built, tested on a staging environment, reviewed with the client, and run on the live data only once everything has been verified.
The FG Drupal to WordPress plugin is a useful starting point for simpler migrations, but for anything involving complex field structures or large content volumes, a custom importer is the more reliable approach.
If you are planning a Drupal to WordPress migration and want to understand how the content side of the project will be handled, get in touch. You can also read the full Drupal to WordPress migration guide for an overview of the complete process, or find out more about what to look for when hiring a freelance Drupal developer for a project like this.
Concerned About Your Content Migration?
Content migration is where most projects run into trouble. Get in touch to discuss how your specific content structure will be handled before the project begins.
