How to generate WordPress content and import into Drupal

Here's a Quickstart, which outlines the process of migrating content from WordPress to Drupal with DDEV:

1. Generate example content in a WordPress web site
2. Export content from WordPress to an XML-file in WXR format
3. Import WordPress content into Drupal

This example requires two local DDEV instances under https://wp.ddev.site and https://drupal.ddev.site.

Install WordPress and create example content

Here's how to generate test content in a local WordPress installation with the FakerPress plugin, allowing you to experiment with migrating content from WordPress into Drupal.

First, install WordPress in DDEV with the DDEV Quickstart for WordPress.

Use the WordPress FakerPress plugin to generate users, taxonomies, and realistic posts, with links and images:

1. Click Plugins > Add plugin
2. Search for "Fakerpress" in the "Search Plugins" field
3. Click Install Now and Activate

4. In WordPress menu, visit FakerPress > Users, Terms, Posts, Attachments and Comments and generate these

Dummy Content Generator can also generate users, but only simple posts without links and images. Advantage: Can generate WooCommerce products.

Export content from WordPress

Export the WordPress web site content to an XML file in WXR format ("WordPress eXtended RSS"), including posts, pages, comments, custom fields, categories, and tags via the GUI or with the wp tool from the command line.

Export WordPress content via the GUI

1. Go to Tools > Export page in the left side menu
2. Select "All Content"
3. Click the Download Export File button

An XML file (WXR format) is downloaded to your computer.

Export using the command line (WP-CLI) tool wp

You can export all site data using the WP CLI wp export command.

$ ddev wp export
Starting export process...
Writing to file /var/www/html/mywordpresssite.wordpress.2026-03-12.000.xml
Success: All done with export.

Your site data is downloaded into a file, we'll refer to it as my_wp_export.xml from here on.

Install Drupal and contrib modules

Install Drupal with the DDEV Quickstart for Drupal.
Note: The domain should be drupal.ddev.site, so use mkdir drupal && cd drupal.

Set "minimum-stability": "alpha" in composer.json to allow downloading Wordpress Migrate, and download and install these contrib modules, and their dependencies:

$ ddev composer require drupal/wordpress_migrate drupal/migrate_tools drupal/pathauto
$ ddev drush install wordpress_migrate wordpress_migrate_ui -y

Test connectivity between source and target

Check if your two DDEV instances can see each other, by running this command in the Drupal DDEV instance (replace image path with an existing image):

$ ddev exec curl https://wp.ddev.site | grep "<title>"
[...] <title>My WordPress site</title>
$ ddev exec curl https://wp.ddev.site/wp-content/uploads/2026/03/1dc65fa5-2b44-3666-94e6-7c91e40ad69b-300x200.jpg --output wp.ddev.site-test.png

Place the my_wp_export.xml file from the WordPress installation in your Drupal installation, so it's ready for import.

Import WordPress data into Drupal

Now you are ready to migrate the WordPress content into Drupal.

Go to https://drupal.ddev.site/admin/structure/migrate and follow the steps under Migrate via User Interface Wizard (README).

You can use the Article content type and its field_image as targets.

When the migration wizard is complete and lists all migrations, click the "Execute" button after each migration to import the content.

Congratulations! If all went well, you should now have several posts with images, exported from WordPress, and imported into Drupal.

Note: There is a challenge with comments as of March 2026 (see #3578768: drush migrate:import --all fails due to Migrate Tools regression) where the comment migration code can block other migrations, if run via Drush:

[error] Migration my_wordpress_comment_post did not meet the requirements. Missing migrations my_wordpress_content_post. In MigrateToolsCommands.php line 1184: my_wordpress_comment_post migration failed.

Until it is fixed, use the GUI and click "Execute".

Eventually, the Drush command should work as well, so in the future, when it is fixed:

... you can use Drush to import everything. Run this command until there are no more errors:

$ drush migrate:import --all

Automate migration creation with Drush

You can create a very basic migration with Drush (and not via the GUI) and direct all content to the "Article" content type in a standard Drupal 11 installation with the command below.

Place the exported file (in the example called my_wp_export.xml) in the root of the installation, and run this Drush command:

drush wordpress-migrate-generate /var/www/html/my_wp_export.xml \
--group-id=my_wp \
--prefix=my_ \
--base-url=https://wp.ddev.site \
--category-vocabulary=tags \
--tag-vocabulary=tags \
--image-field=field_image \
--page-type=article \
--page-body-field=body \
--page-text-format=full_html \
--post-type=article \
--post-body-field=body \
--post-text-format=full_html

Note March 2026: Use dev-version for --page-body-field.

Use cases

Setting up a basic WordPress instance as well as a Drupal installation for import, and getting everything right takes quite some time, since there are a lot of parameters in a WordPress to Drupal migration, like local developer environments, WordPress source, configuration of the migration of fields, formats, etc. Fulfilling all these requirements before a bug can be reproduced, tested and solved can be arduous.

• It takes a lot of time
• Mistakes can be made
• An important step can be forgotten
• There are many parameters

If possible, speed up and streamline the process, by automating as many steps as possible, and use Drush to set up a very basic migration configuration, based on a very basic WordPress installation, and import into a plain vanilla Drupal 11 installation. This streamlines and speeds up the process of creating identical environments, avoiding "it works on my machine" or "I don't see the same behavior" situations, since everything should be identical.

Now, the developer can easily and quickly reproduce the scenario, by funnelling the WordPress data to sane defaults in a plain vanilla Drupal 11 installation, using values which are the most lenient and accepting (see Drush command above), for example:

• Both WP "Posts" and "Pages" should be targeted at Drupal "Article" content type
• All WP "Tags" are targeted at Drupal's "Tag" vocabulary
• Use "Full HTML" for all format options
• and so on ...