Drupal → WordPress
Analyze and move supported Drupal content into a prepared WordPress site through version-aware access, explicit bundle and field mapping, a representative dry run, reconciliation, and controlled cutover. Stable connector availability does not imply universal coverage for Paragraphs, modules, private files, or custom entities.
Self-service migration path
Source and target connectors are available. drupal: Available. wordpress: 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 a staging-safe Drupal URL and approved credentials for JSON:API or a compatible Migranetix Bridge. Required bundles, fields, vocabularies, users, comments, menus, and languages must be visible to that account.
Provide the Drupal version, enabled modules, content-type and field configuration, language setup, URL alias rules, and a list of business-critical custom entities.
Provide the staging URL, migration user, and Application Password. Install and configure the destination post types, taxonomies, fields, SEO storage, multilingual plugin, and Bridge where required before loading data.
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 Drupal and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Drupal data belongs in the prepared WordPress 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 stable Drupal capability and WordPress destination snapshot. Both platforms are enabled in both directions; the selected Drupal version and connector determine which records can be read directly.
The current catalog exposes Author, Category, Comment, Content, Menu, MenuItem, Tag. Drupal 10+ can use the reviewed JSON:API path; legacy sites can require a compatible Migranetix Bridge and version-specific discovery.
Authenticated REST and versioned Bridge adapters write into a prepared WordPress model. Custom post types, fields, taxonomies, menus, comments, and media still depend on target configuration and authorization.
Standard means the current adapters expose a direct structured path. Review means the rule depends on field configuration, connector coverage, or destination architecture. Custom means the source concept has no safe generic WordPress equivalent.
| Drupal source | WordPress target | Status and boundary |
|---|---|---|
| Nodes and content bundles | Posts, pages, or prepared custom post types | Standard with modeling: each Drupal bundle needs one approved WordPress destination type. |
| Typed fields | Core fields, post meta, ACF, blocks, or plugin fields | Review: scalar fields map directly more often than formatted text, lists, files, links, dates, or compound values. |
| Users referenced as authors | WordPress users and post authors | Standard with identity review: stable IDs and email matching preserve authorship; passwords and authentication behavior are separate. |
| Taxonomy vocabularies and nested terms | Categories, tags, or custom taxonomies | Standard: vocabularies, hierarchy, and term relationships are loaded before dependent content. |
| Comments and parent relationships | WordPress comments | Standard with validation: destination post and parent-comment IDs must resolve before acceptance. |
| Menus and menu links | WordPress menus and menu items | Standard with routing review: internal links must resolve against the approved destination URL map. |
| Path aliases and redirect history | Permalinks and redirect rules | Review: aliases are migration inputs; hosting or WordPress redirect implementation is a separate launch artifact. |
| Managed files and image fields | WordPress media and rewritten references | Review: every file must be discoverable, downloadable, accepted, and attached or referenced according to the destination rule. |
| Entity references and Paragraphs | Relationships, repeaters, blocks, or normalized child records | Review/custom: cardinality, ordering, revisions, nesting, and rendering determine the transformation. |
| Revisions, moderation, and scheduled states | WordPress revisions and editorial states | Review: current published content is the default; historical revisions or complex workflows need an explicit retention policy. |
| Translations and language relationships | Configured WordPress multilingual model | Review: locale identity, translation groups, fallback, slugs, and destination plugin behavior must be designed together. |
| Layout Builder, Views, blocks, modules, and theme behavior | Theme, templates, blocks, plugins, or custom code | Rebuild: presentation, queries, forms, permissions, and application behavior do not transfer as node data. |
The approved mapping workbook records bundle routing, typed-field transformations, dependency order, source identity, destination storage, and exception handling.
| Drupal value | Migration rule | WordPress result |
|---|---|---|
| Node ID and UUID | Preserve both as source identity and use the ID map for reruns | Stable destination lookup and delta updates |
| Bundle | Route through the approved bundle-to-type matrix | Post, page, or prepared custom post type |
| Title, body, summary, and text format | Sanitize approved markup and transform unsupported filters or embeds | Title, content, excerpt, and documented exceptions |
| Vocabulary, term ID, and parent | Create taxonomy terms in dependency order and resolve destination IDs | Category, tag, or custom-taxonomy hierarchy |
| User ID | Match or create an approved author identity | WordPress author assignment without Drupal credentials |
| Path alias and historical aliases | Select the canonical destination path and add legacy values to the URL map | Permalink plus redirect requirements |
| Entity reference or Paragraph item | Resolve child IDs and apply the approved field, repeater, block, or record transformation | Destination relationship with preserved order where supported |
| File ID and URI | Locate, download, validate, upload, and rewrite references | WordPress media record or documented failure |
Drupal and WordPress can represent the same editorial content very differently. Destination modeling must be approved before records are loaded.
Capture bundles, field storage, cardinality, allowed values, text formats, vocabularies, entity-reference targets, Paragraph types, languages, and module ownership.
Assign each source bundle to a WordPress post type or a documented archive/exclusion rule instead of collapsing all nodes into posts.
Create users, terms, media, and reusable child records before resolving node references, comments, and menu links.
Transform portable values deliberately while treating Views, Layout Builder, theme regions, forms, permissions, and module behavior as destination implementation.
Drupal path aliases and nested routes rarely match final WordPress permalinks without an explicit URL contract.
Combine the crawl, canonical aliases, language prefixes, historical redirects, menu routes, sitemap entries, and high-value landing pages.
Define post-type and taxonomy structures, collision handling, trailing-slash behavior, multilingual paths, and canonical rules before the final load.
Extract supported core and Metatag values, then map them to the selected WordPress SEO implementation instead of assuming plugin compatibility.
Update internal links and file references, then test one-to-one redirects, chains, loops, canonicals, sitemap entries, and priority URLs around cutover.
Acceptance requires reconciled records, references, URLs, and rendering—not just successful destination API responses.
Compare source, extracted, transformed, loaded, skipped, failed, draft, and published totals by bundle, language, taxonomy, and status.
Check long-form nodes, nested terms, multiple authors, Paragraphs, entity references, formatted text, translations, comments, menus, and media-heavy records.
Confirm authors, term hierarchy, referenced entities, comment parentage, menu nesting, source-to-target IDs, and repeatable reruns.
Validate rendering, assets, internal links, metadata, canonicals, redirects, sitemap coverage, crawl errors, and documented 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
Plan legacy access, fields, module data, URLs, dry runs, and source retirement.
Open guide →Compare content models, permissions, multilingual architecture, operations, and migration tradeoffs.
Open guide →Plan bundle, field, dependency, media, module-data, dry run, and cutover handling.
Open guide →Build an auditable URL, metadata, redirect, launch, and monitoring plan.
Open guide →Clear answers
Each bundle must be inventoried and routed to a prepared WordPress post type, field model, archive, or exclusion. Core nodes are more predictable than custom or module-owned entities.
Not generically. Paragraph types, nesting, cardinality, revisions, references, and rendering must be transformed into approved WordPress blocks, fields, repeaters, or child records.
Authors and approved user profiles can be mapped. Password portability, roles, permissions, SSO, and account activation depend on the destination authentication design and are not assumed.
Canonical and historical aliases become inputs to the destination permalink and redirect plan. Every valuable old URL is tested against its approved destination.
Yes when language values and translation relationships are accessible, but the WordPress multilingual plugin, locale mapping, translated slugs, fallbacks, and publishing rules must be prepared and tested.
No. Their data requirements are assessed, but queries, layouts, forms, permissions, integrations, and module behavior require WordPress-native implementation.
Current content and publication state are the standard baseline. Historical revisions and complex moderation workflows require an explicit retention and transformation scope.
Reconcile records by bundle and language, inspect complex relationships and rendering, crawl URLs, test redirects and metadata, and document every unresolved or accepted exception.
Next step
Create an account, select Drupal and WordPress, and analyze version, access, bundles, relationships, URLs, destination readiness, and validation requirements.
