Migration guide

Can you migrate Drupal to WordPress?

Last updated: July 2026 · By the Replatform Radar team — specialists in pre-migration CMS content audits

Yes — Drupal to WordPress is one of the highest-volume CMS migrations, driven largely by Drupal 7's end-of-life and the pull of simpler authoring and maintenance. But it is a content-model translation, not a copy: Drupal's entities and typed fields are richer than vanilla WordPress, so the real work is deciding how much structure to preserve and rebuilding what WordPress lacks natively — Views, contributed modules, and multilingual.

Drupal is built around entities and fields: content types (bundles) with strongly-typed fields (field_*), entity references between them, and taxonomy vocabularies. WordPress's native model is comparatively flat — posts and pages plus loosely-typed post meta, categories and tags. The core decision is how much of Drupal's structure to preserve: each content type typically becomes a Custom Post Type (CPT), and each structured field is rebuilt with Advanced Custom Fields (or Pods/Toolset) rather than dumped into the post body.

The second reality is that Drupal's content model is usually richer than vanilla WordPress, so a chunk of the work is rebuilding what WordPress lacks natively. The clearest example is Views — Drupal's UI for every listing, archive, and filtered block. WordPress has no built-in equivalent, so each View is re-implemented with WP_Query and custom templates, or approximated with a plugin (Toolset Blocks, Query Wrangler, GravityView). Twig theming and contributed modules (Webform, Paragraphs, Rules, Commerce) likewise have no drop-in counterparts.

So an automated tool moves the data but not the behavior. Plugins like FG Drupal to WordPress reliably migrate nodes, taxonomies, users, comments, and media, but content types with many custom fields, listings, multilingual structure, and URL/redirect logic still need mapping, configuration, and often custom scripting. A realistic project audits the Drupal structure, decides what to keep, models the CPT/field/taxonomy equivalents, migrates data, rebuilds listings and templates, and preserves URLs via redirects.

In your report — not a generic checklist

The Drupal → WordPress detail, catered to your site

A pre-migration scan produces a report tailored to this exact transfer, covering the parts that decide whether the project goes smoothly:

How Drupal and WordPress compare across the dimensions that matter for a migration
The field-mapping table — what each Drupal construct becomes in WordPress
The Drupal to WordPress-specific gotchas that silently cause data loss, broken links, and ranking drops
Realistic timeline and cost drivers for this migration
Your own site’s findings scored against all of it

Scan my site for this migration →

In depth

What a Drupal to WordPress project actually looks like

A realistic shape for this specific transfer. Phases, the work inside each, and the failures that recur on this exact platform pair. Spans assume a mid-size estate; large or multi-site estates run longer.

Entity and module auditWeeks 1-3
- Map every content type, field, taxonomy vocabulary and paragraph type; Drupal's field system is more granular than WordPress's, so decide early what becomes a custom field versus a block versus a taxonomy.
- Inventory contributed modules and mark each: WordPress core equivalent, plugin equivalent, custom build, or drop. This list is the real scope of the project.
- Catalogue Views - Drupal sites often carry dozens - and decide which become WP_Query templates, which become plugin-driven listings, and which nobody has looked at in years.
- Record the path-alias table; Drupal aliases rarely match WordPress permalink structures, and this drives the redirect map.
Model and template mappingWeeks 3-7
- Translate content types into post types and fields into a structured custom-field approach, resisting the temptation to dump everything into post content.
- Map taxonomy vocabularies to WordPress taxonomies, deciding where Drupal's hierarchical terms need flattening.
- Rebuild theme templates: Twig does not port to PHP templates or block themes, so the front end is a rebuild even though both platforms are PHP.
- Decide the editorial experience - classic editor with custom fields, or block editor with custom blocks - because it determines how content must be shaped on import.
Migration and rebuildWeeks 6-12
- Script the content migration from the Drupal database or JSON:API into WordPress, transforming field structures rather than copying rows.
- Move files from Drupal's public files directory into the WordPress media library, preserving alt text and captions, then rewrite in-body references.
- Rebuild multilingual behaviour deliberately: Drupal core handles translation natively, WordPress needs a plugin with a different data model, and this is routinely underestimated.
- Re-create user roles and permissions; Drupal's granular permission system does not map cleanly onto WordPress's smaller role set.
LaunchWeeks 12-16
- Build 301s from every Drupal path alias and node/NNN URL to the new permalinks, including the numeric node paths that external sites often link to.
- Verify menu structure, breadcrumbs and internal links, which frequently break when hierarchy is flattened during import.
- Watch for duplicate content from taxonomy and archive pages that WordPress generates automatically and Drupal did not.

Pre-launch verification checklist

The checks worth running before DNS moves. Each one maps to a failure we see repeatedly on Drupal to WordPress projects.

Both alias URLs and raw /node/NNN URLs redirect to the correct WordPress permalinks - external links often use the numeric form.
In-body file and image references point at the WordPress media library rather than surviving /sites/default/files/ paths.
Taxonomy hierarchy and term URLs behave as intended, and auto-generated archive pages are either wanted or set to noindex.
Editorial workflow and roles are re-created at a level the team can actually operate, with any loss of granularity acknowledged.
Translations resolve correctly, with hreflang emitted, if the site was multilingual.
Structured data that Drupal modules emitted is re-created via the WordPress SEO plugin or theme templates.
Views-driven listings return the same content in the same order as the Drupal originals, verified against a handful of real pages.

Risk register

Risk	Likelihood	Mitigation
Field-level structure collapsed into unstructured post content	High	Agree the custom-field model before import and validate it against the most complex content type first.
Multilingual complexity discovered mid-project	Medium	Prototype the translation plugin with real content in week one if the site has more than one language.
Numeric node URLs left unredirected	High	Include /node/NNN paths in the redirect map explicitly; alias-only mapping misses inbound links.
Contributed-module functionality assumed to exist in WordPress	High	Resolve every module to a named replacement during the audit, before build estimates are given.
Auto-generated archive pages creating duplicate content	Medium	Decide indexation for author, date and taxonomy archives deliberately at launch.

Case studies: Drupal to WordPress migrations

Anonymized, real-world lessons from moves like this one. What breaks, what works, and how to protect your traffic.

FAQ

Drupal to WordPress: frequently asked questions

Can you migrate a Drupal site to WordPress?

Yes. Content, users, comments, taxonomies, and media migrate well with tools like FG Drupal to WordPress plus WP-CLI or custom scripts for scale. What does not migrate automatically is behavior — Views, custom-module logic, and Twig templates are rebuilt, not copied.

Is it hard to move from Drupal to WordPress?

The data move is straightforward; the hard part is the model gap. Because Drupal's structured fields, entity references, Views, and multilingual model are richer than vanilla WordPress, effort scales with how much structure you preserve and how many listings and modules you rebuild — not with page count alone.

What happens to my Drupal Views?

Nothing transfers automatically — WordPress has no Views equivalent. Each View is re-created with WP_Query and custom templates, or approximated with a plugin. This is often the largest single work item in the migration.

Will my URLs and SEO survive?

They can, but only with deliberate work: baseline every URL/title/meta first, match WordPress permalinks to old Pathauto aliases where possible, and 301-redirect everything else without chains. Expect some short-term ranking fluctuation even with perfect redirects; sloppy redirect maps cause large, slow-to-recover losses.