FAQs

Start with a URL and data-mapping plan. Preserve important URLs, migrate SEO metadata and taxonomy relationships correctly, set up necessary redirects, and validate indexability, canonicals, sitemaps, internal links and metadata before launch.

Create the required Drupal taxonomy vocabularies first, then migrate WordPress categories and tags into the corresponding terms. Run taxonomy migrations before dependent content, or configure migration dependencies so content can resolve the correct term IDs.

Yes. WordPress categories and tags can be migrated into Drupal taxonomy vocabularies and terms. Custom taxonomies may require a more specific mapping depending on their hierarchy and structure.

First, identify where your WordPress SEO plugin stores titles, descriptions and other metadata. Then map each value to the appropriate Drupal Metatag configuration rather than assuming WordPress and Drupal use the same fields or storage structure.

Recreate the existing permalink structure in Drupal using Pathauto where practical, and create explicit URL aliases for URLs that need to remain exactly the same. Test the resulting URLs before launch to catch missing or incorrect mappings.

Map each important WordPress URL to its intended Drupal URL before migration. Preserve the existing URL where possible by creating matching Drupal URL aliases; for changed URLs, map them directly to their new destinations with permanent redirects.

1. Declarative YAML Configuration: Map fields, transformations, and relationships in human-readable YAML without having to write boilerplate PHP.
2. Automatic Relationship Resolution: Using the migration_lookup process plugin, Drupal maps legacy relationships (e.g., author IDs, taxonomy terms, parent nodes) to newly created Drupal IDs on the fly.
3. Safe Reversibility & Rollbacks: If an import has errors, you can roll back the entire batch without leaving orphan records or database bloat.
4. Memory & Performance Handling: The framework processes records in memory-safe chunks with batching, skipping unchanged rows, and catching fatal errors on a per-row basis.

Yes, easily. Common approaches include:

1. WXR XML Export: Ingesting WordPress XML exports using the wordpress_migrate module or custom XML source plugins.
2. WordPress REST API: Using migrate_plus with a JSON source plugin pointing directly to /wp-json/wp/v2/posts.
3. Direct Database Access: Querying the wp_posts and wp_postmeta tables directly via standard SQL source plugins.
4. Gutenberg Blocks / Shortcodes: Custom process plugins can parse Gutenberg comment blocks or shortcodes and map them into Drupal Paragraphs or native Block components.

It processes data through three sequential pipeline stages:

1. Extract (Source Plugin): Connects to the data source (SQL table, CSV, REST API, JSON, XML) and reads records row by row.
2. Transform (Process Plugin): Cleanses, manipulates, and formats values (e.g., transforming date strings, re-mapping taxonomy IDs, or combining split name fields).
3. Load (Destination Plugin): Writes the final output into Drupal destination entities (Nodes, Media, Taxonomy Terms, Users, Paragraphs, or Config).
4. The Secret Sauce: The Migrate API automatically creates underlying map tables that pair source IDs with new Drupal entity IDs. This allows Drupal to look up relationships (like post authors or parent terms) dynamically and enables one-command rollbacks (drush migrate:rollback).

Yes. Automation can be handled at multiple layers:

• Scheduled Background Syncs: Modules like migrate_cron or server-level cron jobs can trigger Drush commands on a schedule.
• Incremental / Delta Imports: By enabling track_changes: true (which hashes row data to detect modifications) or setting a high_water_property (using a timestamp or incremental ID), migrations will only process new or updated records on repeat runs.
• CI/CD Pipelines: Migrations can be automated as part of automated deployment workflows—running imports against staging, validating entity references, and applying updates seamlessly.