WordPress → Drupal
Move WordPress content into Drupal with explicit bundle and field mapping, dependency ordering, media and taxonomy handling, alias and redirect planning, staging reconciliation, and controlled cutover. Destination development and module behavior remain separate scope.
Self-service migration path
Source and target connectors are available. wordpress: Available. drupal: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the site URL and Application Password, or approve a compatible Bridge when REST does not expose required custom types, metadata, comments, menus, media, or plugin records.
Install and approve the compatible Migranetix Bridge for the actual Drupal version. Drupal JSON:API is currently a source path, not the standard target write path.
Approve content types, fields, text formats, vocabularies, media or file fields, users, comments, menus, aliases, redirects, Metatag fields, moderation, language settings, and staging backups before loading.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to WordPress and connect a prepared staging Drupal destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported WordPress data belongs in the prepared Drupal model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
This page is synchronized with the WordPress source capability and stable Drupal target capability. Both are public-ready in both directions; Drupal destination writes use a compatible Bridge rather than the source-only JSON:API connector.
The current source exposes Authors, Categories, Tags, Posts and pages, Comments, Menus, Menu items, Media through authenticated REST or versioned Bridge paths. Plugin-owned data remains separate discovery scope.
The current target exposes Author, Category, Comment, Content, Menu, MenuItem, Tag across versioned Bridge adapters. Drupal 5 through 11+ are represented, but the exact destination version, tables, modules, fields, and write path must be verified.
Standard means the versioned adapters expose corresponding entities. Review means the destination bundle, field, module, or identity model must be approved. Custom means plugin or application data needs a dedicated pipeline.
| WordPress source | Drupal target | Status and boundary |
|---|---|---|
| Posts and pages | Drupal nodes in approved content types | Standard with mapping: title, body, summary, dates, status, type, author, taxonomy, slug, and supported metadata are routed into prepared bundles. |
| Custom post types and fields | Custom content types and fields | Review/custom: source exposure, destination field definitions, cardinality, formats, defaults, and relationships must match. |
| Users and authors | Drupal users and node ownership | Standard with review: profiles and authorship can map; roles, passwords, MFA, memberships, and private access require separate rules. |
| Categories and tags | Vocabularies and taxonomy terms | Standard: vocabularies and terms load before nodes and resolve through the ID map. |
| Comments | Drupal comments linked to nodes and users | Standard with review: parent relationships, status, anonymous identity, fields, and destination comment configuration must be available. |
| Menus and menu items | Drupal menus and custom menu links | Standard with review: hierarchy, internal targets, aliases, external links, language, and enabled state are validated. |
| Images and files | Managed files, media entities, and node fields | Standard with validation: the destination field and media configuration determine how files, alt text, ownership, and references are stored. |
| Slugs, SEO fields, and old URLs | Path aliases, Metatag fields, and Redirect records | Standard when modules and fields exist: the Bridge supports aliases, supported SEO payloads, and redirect records in prepared destinations. |
| Blocks, shortcodes, embeds, and builders | Formatted text, Paragraphs, Layout Builder, or custom components | Review/custom: presentation-bound markup requires transformation or reconstruction. |
| Plugins, WooCommerce, forms, memberships, and workflows | Drupal modules, Commerce, Webform, custom entities, or integrations | Custom: application behavior does not become equivalent through content migration alone. |
The approved workbook connects WordPress types and fields to exact Drupal bundles, field machine names, dependencies, transformations, and exception handling.
| WordPress value | Migration rule | Drupal result |
|---|---|---|
| Post type and source ID | Route to an approved bundle and preserve source identity | Drupal node type, node ID map, and repeatable update path |
| Title, body, excerpt, date, status | Normalize markup and translate workflow state | Node title, body, summary, timestamps, and publication state |
| Category and tag IDs | Create vocabularies and terms before dependent nodes | Taxonomy term references using destination IDs |
| Author and comment relationships | Create or match users, then load nodes and comments in dependency order | Node ownership and Drupal comment references |
| Attachment and featured image | Download, validate, create file or media records, and populate approved fields | Managed file or media entity plus node relationship |
| Slug, SEO values, and source URL | Create the approved alias, Metatag payload, and redirect record | Drupal path alias, metadata, and tested old-to-new redirect |
Drupal requires an explicit destination model. Importing every WordPress record into one generic Article bundle usually loses structure and creates avoidable editorial debt.
Review post types, taxonomies, fields, ACF groups, users, roles, comments, media, menus, plugin tables, blocks, shortcodes, volumes, statuses, and URLs.
Approve content types, field machine names, types, cardinality, required values, defaults, references, text formats, revisions, moderation, languages, and displays.
Create users, vocabularies, terms, files or media, and menus before the nodes, comments, and menu links that depend on their destination IDs.
Treat Paragraphs, Layout Builder, Views, Webform, Commerce, search, permissions, integrations, theme, and custom modules as coordinated implementation work.
The current Migranetix destination path uses versioned Bridge adapters. Drupal also documents a WordPress Migrate workflow for Drupal 10.5 and 11 using WXR, Migrate API, contributed modules, and Drush.
Use the reviewed versioned Bridge when the project needs repeatable source-to-target mapping across configured users, taxonomy, content, comments, menus, media, aliases, and redirects.
Use the official ecosystem path as a reference or alternative for supported posts, pages, comments, attachments, tags, and categories into a prepared modern Drupal site.
The current Drupal 10.5/11 WordPress Migrate release is alpha and depends on contributed modules, so its suitability and security coverage must be reviewed rather than assumed.
Drupal migration tooling can track and roll back imported records, but rollback can remove destination changes made after import and does not replace backups or cutover controls.
A successful database write is not an accepted Drupal migration. Final evidence must cover entity integrity, rendered pages, editorial behavior, URLs, and production signals.
Map every valuable WordPress URL to the approved Drupal alias and test Redirect records, status codes, loops, chains, language prefixes, parameters, and trailing slashes.
Compare source, extracted, transformed, loaded, skipped, rejected, and failed totals for users, terms, nodes, comments, files, menus, and links.
Inspect text formats, fields, references, media, alt text, comments, menus, revisions, moderation, permissions, preview, editing, search, forms, and representative templates.
Validate metadata, canonicals, internal links, sitemaps, robots rules, analytics, conversion paths, logs, priority pages, and post-launch exceptions.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Prepare content types, vocabularies and relationships in Drupal.
Open guide →Review WordPress source extraction, custom types, plugins, users, media, and URL handling.
Open guide →Review the reverse direction and Drupal-specific content-model boundaries.
Open guide →Compare a publication-focused Ghost destination with a narrower standard content model.
Open guide →Clear answers
Yes. They can map into prepared Drupal content types through the current Bridge path. The destination bundles, fields, formats, aliases, and workflow must be approved first.
The current Drupal target exposes users, comments, menus, and menu links. Identity, password compatibility, roles, comment fields, hierarchy, aliases, and permissions still require review.
They can be assessed when source values are accessible and equivalent Drupal fields or entities exist. Complex ACF structures, serialized data, and plugin tables usually require custom mapping.
Not for the current standard target path. Drupal JSON:API is configured as a source connector; destination writes use a compatible versioned Migranetix Bridge.
It is an available Drupal ecosystem path for supported WXR content. The current Drupal 10.5 and 11 release is alpha and uses contributed dependencies, so project fit must be reviewed.
Prepared Drupal destinations can receive aliases, supported Metatag data, and Redirect records. Coverage still depends on installed modules, field configuration, and an approved URL map.
No. Drupal theme, components, Paragraphs, Layout Builder, Views, forms, commerce, search, memberships, permissions, and integrations are separate implementation work.
No. Reduce risk with backups, dry runs, reconciliation, URL mapping, staged validation, cutover controls, analytics, monitoring, and rollback decisions.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
