Drupal Migration Tools: Migrate API, Modules & Automation | Innoraft Skip to main content

Search

4 Sep, 2026
8 min read

Drupal Migration Tools: Migrate API, Modules & Automation

author-picture

Author

Anuska Mallick

Sr. Technical Content Writer

As an experienced Technical Content Writer and passionate reader, I enjoy using storytelling to simplify complex technical concepts, uncover real business value, and help teams make confident digital transformation decisions.

Image
Drupal Migration Tools: Migrate API, Modules & Automation

Migrating to modern Drupal isn't a single button-click. It's a strategic combination of frameworks and modules, chosen based on your source data, your transformation needs and how often the migration needs to run. There's no specific "Drupal migration tools" that handles every scenario. A database import behaves nothing like an XML feed with nested taxonomy terms, and a Drupal 6 upgrade isn't the same job as pulling content out of WordPress.

In the following blog, we will cover three layers: the core Migrate API that every migration builds on, the contributed modules that fill the practical gaps, and the execution strategy that decides whether a migration runs once or keeps running for years. At Innoraft, we've built migration paths for clients moving off Drupal 7, WordPress and custom CMS platforms, and the same rule holds for most projects: add tooling only when the data forces you to.

What is The Drupal Migrate API?

Drupal core ships three Drupal migration tools built around the Drupal Migrate API. Migrate is the general-purpose migration framework, using an Extract, Transform, Load model (ETL). Migrate Drupal handles Drupal-to-Drupal migrations, particularly moving Drupal 6 or 7 into modern Drupal. Migrate Drupal UI provides a browser-based interface for the Drupal 6/7 upgrade workflow. Together, these core modules are the foundation for migrations built using Drupal's Migrate API, whether the source is an older Drupal site or something else entirely.

Worth separating out: a Drupal 10 to Drupal 11 move is a core version upgrade, handled through Drupal's standard update process, not a content migration. Migrate applies when you're bringing in Drupal 6/7 content, or content from an external source altogether.

The framework runs on three plugin types, matching the ETL model:

  1. Source plugins retrieve rows from databases, files, JSON or XML data, or web services.
  2. Process plugins map and reshape fields, values and references during the move.
  3. Destination plugins write the processed data into nodes, taxonomy terms, users or media entities.

Here's the gap: Core Migrate hands you the plugin system and YAML-based migration definitions. It doesn't come with a UI, scheduling or parsers for spreadsheets. Real-world WordPress to Drupal migrations, especially ones with custom formats or recurring syncs, need the contributed Drupal migration modules that sits on top of it.

Which Contributed Modules do You Actually Need?

Among the Drupal migration tools, two contributed modules are critically important: Migrate Plus and Migrate Tools. They solve different problems, and conflating them is a common mistake.

Migrate Plus extends the core framework with migration configuration entities, migration groups, additional process plugins and source functionality for formats such as JSON and XML. It's not Drupal's Configuration Management system, despite the name overlap. It's specific to how migrations get organized and extended.

Migrate Tools adds a web UI, progress reporting and extra commands, including migrate:tree for viewing migration dependency trees. Since Drush 10.4, most of its core commands are also available directly in Drush, so you don't strictly need Drupal Migration Tools just to run migrations from the command line. Its stable release currently supports Drupal 9.1, 10 and 11.

Beyond those two, module choice depends on the source format and the transformation you need. Here’s a comprehensive overview.

ModulePrimary Use CaseWhen to Use It
Migrate Drupal (Core)Legacy upgradesMigrating config and content from Drupal 6 or 7
Migrate UpgradeLegacy upgradesGenerating migration configuration from a Drupal 6/7 source via a Drush-based workflow
Migrate Source CSVSource parsingIngesting structured spreadsheet exports
Migrate SpreadsheetSource parsingSource data is .xls, .xlsx, .ods or .csv
Migrate File Entities to MediaContent transformationConverting legacy file entities, including Drupal 7 files, into Media entities
Migrate HTML to ParagraphsContent transformationBreaking monolithic WYSIWYG HTML into structured Paragraphs; currently a release-candidate project, so verify core compatibility first

Use Migrate Source CSV when the source is plain CSV. Use Migrate Spreadsheet for native XLS, XLSX or ODS files, or when you want one plugin that also handles CSV.

Newer entries like AI Migration are worth watching too. It uses AI to parse relatively unstructured web content and generate migration definitions based on a Drupal content migration model. It currently sits at a 1.0 release candidate with support for Drupal 10 and 11, but Drupal.org lists no supported stable release yet, so it needs careful evaluation before production use.

What's the Best Way to Select and Automate Your Drupal Migration Tools?

Drupal migration is not a one-and-done operation. This is why when the migration needs to run repeatedly, at scale, or with predictable Drupal site performance optimization results, you need to automate the whole process.

Here's a step-by-step process preferred by our experts at Innoraft-

  • Step 1: Identify the Source and Transformation Needs

Match your data type, whether that's a SQL database, a spreadsheet export, an XML feed or a REST API, to the modules above. Standard field mapping covers most content. Complex business logic, like merging three legacy fields into one, may require custom migration logic, such as a custom process plugin or another migration-specific extension.

  • Step 2: Determine Execution and Drupal Migration Automation Requirements

  1. One-time migrations run through standard Drush commands: migrate:import, migrate:rollback, migrate:status. WordPress to Drupal migration tools can use these same commands when moving content from WordPress into Drupal. Large migrations should be designed for incremental processing instead of one giant batch. Memory limits, execution time, database performance and the complexity of custom processing all affect how a migration performs, not just row count.
  2. Migrations with dependencies, such as users before content or taxonomy before nodes, should define those dependencies directly in the migration configuration; the Migrate API supports this natively. For larger migration sets that need to run in a defined sequence from the command line, Migrate Manifest can be useful, though its current stable release does not list Drupal 11 compatibility, so check the project page first.
  3. Drupal's Migrate API also maintains map tables that associate source IDs with destination IDs, allowing subsequent runs to track which source records have already been migrated and their corresponding destination records. Drupal data migration tools should account for this mapping when migrations need to be rerun or updated. However, only scheduling doesn't work as a real sync strategy. Repeated imports without any reliable source IDs and update handling can create duplicates or out of sync content.
  4. Treat migration like any other deployment step for your CI/CD workflow. Drupal migration automation options can help run migration processes consistently across environments. Run them against staging, check the result, and then promote them to the production stage of your phased Drupal Migration process.
  • Step 3: Plan for Testing and Rollbacks:

As experienced Drupal migration services provider, here’s what we suggest on the last stage of automating your migration process- 

  1. Validate entity relationships early: Build migration stubs early, and validate entity relationships before cutover: does a migrated node reference the right taxonomy term, does the right user own the right content.
  2. Test rollback alongside import: Make sure rollback behaves predictably, especially when migrations involve referenced entities, dependencies, or custom processing.
  3. Run and validate the migration in staging: Check entity references, files and media, URL and path preservation, redirects and multilingual fields too, if the source content has them. Skipping a staging run is a common way for these issues to surface for the first time in production.

Building Your Migration Toolkit

When it comes to choosing the right WordPress to Drupal migration tools, the best strategy uses the least tooling that gets the job done. Start with the Migrate API. Add Migrate Plus when you need its extended source, process or migration-configuration features, and add Migrate Tools when its UI and extra commands help your workflow. Bolt on niche modules like Migrate Source CSV or Migrate HTML to Paragraphs only when the data actually requires them, and check compatibility before adopting anything at release-candidate stage.

Once the Drupal migration tools are selected, the next crucial phases are data mapping, SEO preservation and post-migration validation. Those phases decide whether a migration actually succeeds, and they're worth their own closer look.

Wondering which tools your Drupal migration process will benefit from? Connect with our experts and choose the right tools today! 

FAQ

Frequently Asked Questions

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.

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.
     

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.

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.

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, 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.

  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.

Didn’t find what you were looking for here?