FAQs

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.

There is no single "magic button" tool; the industry standard is Drupal's native Migrate API paired with Drush (the command-line shell).

1. For Drupal 6/7 upgrades: Use migrate_upgrade via Drush (drush migrate:upgrade) to scaffold migrations, then fine-tune via YAML.
2. For custom/external data: Use custom YAML migration plugins executed via Drush (drush migrate:import --tag=...).
3. For small, recurring non-technical imports: Modules like feeds work for simple periodic ingestion, but Migrate API + Drush remains the most performant, scale-tested solution.

Depending on the source format and complexity:

Core Modules:

• migrate: The foundational ETL framework and plugin system.
• migrate_drupal & migrate_drupal_ui: Core tools for migrating legacy Drupal 6/7 sites into modern Drupal.

Essential Contributed Modules:

• migrate_plus: Adds JSON/XML/REST endpoints, migration groups, and extra process plugins.
• migrate_tools: Adds migration management tools, web UI dashboards, and command line utilities.
• migrate_upgrade: Generates migration templates/configurations from an existing Drupal 6/7 database.

Format & Architecture Specific:

• migrate_source_csv / migrate_spreadsheet: For ingesting CSV, XLS, and XLSX files.
• migrate_file_to_media: Converts legacy file and image fields into Drupal Media entities.
• migrate_html_to_paragraphs: Splices monolithic WYSIWYG HTML into structured Paragraphs components.
   

The Drupal Migrate API is Drupal core’s built-in ETL (Extract, Transform, Load) framework. It provides a standardized, plugin-based architecture to import, reshape, and synchronize structured data, whether coming from legacy Drupal sites (Drupal 6/7), external CMSs, REST APIs, databases, or flat files, directly into modern Drupal entities.

Run repeated staging migrations, reconcile records using migration map and message tables, check taxonomy and author mappings, and confirm redirects before going live.

It can improve performance, but that's not guaranteed. Outcomes depend on hosting, caching, database and query behavior, and front-end implementation. Benchmark representative pages and key user journeys before and after migration rather than assuming the platform switch alone will improve performance.

Yes, for URLs with a genuine new equivalent. Avoid mass-redirecting unrelated pages to the homepage; Google can treat that as a soft 404.