How to Generate WordPress Content and Import Into Drupal

A CMS migration rarely goes smoothly. Files move, URLs change, and someone always worries about losing search rankings overnight. That doesn't stop teams from making the jump. WordPress can support complex content models through plugins and custom development, but organizations often move to Drupal for structured content modeling, granular permissions, or centralized control over a large site.

This guide covers how to generate WordPress content and import into Drupal: exporting your data, preparing Drupal to receive it, and running it through the WordPress Migrate wizard.

What Do You Need Before Starting the Migration? 

You need admin access to WordPress and terminal access to Drupal, plus content types and taxonomies built ahead to import WordPress content into Drupal.

1. A WordPress admin login with permission to reach Tools > Export
2. SSH or terminal access to Drupal, with Composer and Drush installed
3. Drupal content types built ahead of time (Article and Basic Page cover most WordPress sites)
4. Taxonomy vocabularies matching WordPress categories and tags

This step gets skipped more than it should during WordPress Drupal migration. Run the wizard before that structure exists, and mapping has nothing to map to.

How Do You Generate WordPress Content and Import into Drupal? 

Don't wait until the Drupal import to discover that the WordPress content is a chaotic mess. A Drupal migration services team can help you audit and clean the source content first, because the migration will move what you give it, including old test posts, duplicate categories, empty fields, and content built with a page builder that Drupal doesn't know how to interpret.

Before you generate WordPress content and import into Drupal, go through the WordPress content and decide what actually needs to move.

1. Delete or exclude old drafts, test content, duplicates, and anything no longer needed.
2. Clean up categories and tags. If the same topic appears under several slightly different names, decide which term should survive in Drupal.
3. Check that featured images and other media are not missing or broken.
4. List of custom post types and custom fields. Standard WordPress Migrate will not automatically convert these to Drupal content structures.
5. Flag shortcodes, page-builder content, and Gutenberg blocks that will need transformation rather than a straight import.
6. Export a list of existing URLs for important pages and posts so you can map them to their Drupal paths later.

If you're creating new content shortly before the WordPress Drupal migration, keep it consistent with the content model you've already planned for Drupal. Don't introduce a new custom field or content type on the WordPress side unless you know how it will be handled after the move.

This is also a good point to freeze major content-structure changes. Otherwise, you're cleaning and mapping one version of the WordPress site while editors are still changing another.

Once the source content is in reasonable shape, export the WXR file and move on to preparing Drupal.

How Do You Export Your WordPress Content as a WXR File? 

WXR stands for WordPress eXtended RSS, the XML format WordPress uses to package posts, pages, comments, custom fields, categories, and tags into one file. It's a content expert that helps to migrate WordPress posts to Drupal. However, it is not a full site backup and skips site configuration, plugin settings, and the binary attachment files themselves, so Drupal must still reach the original WordPress media URLs during migration.

1. Log in to your WordPress dashboard.
2. Go to Tools > Export.
3. Select All Content.
4. Click Download Export File.
5. Save the XML file somewhere you can transfer it to the Drupal environment.

Large sites sometimes stumble here. A multi-gigabyte browser export gets cumbersome fast and can time out. WP-CLI's wp export runs from the terminal instead, and its --max_file_size flag splits the output into smaller files, easier to move and import WordPress content into Drupal in batches. For very large or heavily customized sites, a direct database migration (covered below) can be a better fit than WXR, though size alone isn't a reason to abandon the file export.

How Do You Set Up Drupal to Accept WordPress Content?

Drupal core ships with a full suite of migration tools for WordPress to Drupal content migration, Migrate API being one of them. However, the Migrate API doesn't know WordPress's data structure out of the box. WordPress Migrate handles the WXR-based migration, Migrate Tools provides migration management, and Pathauto generates Drupal URL aliases. Composer pulls in Migrate Plus and Ctools automatically too, since WordPress Migrate depends on both.

composer require 'drupal/wordpress_migrate:^3.0@alpha' drupal/migrate_tools drupal/pathauto
drush en wordpress_migrate wordpress_migrate_ui pathauto -y

One thing to flag as part of this WordPress to Drupal content migration guide: WordPress Migrate's Drupal 10/11 release is still alpha, with no stable release, so test in a staging environment before a production import. The version constraint above accepts alpha stability for this package only, not your whole project.

1. WordPress Migrate reads the WXR file and maps content to Drupal
2. Migrate Tools adds the Drush commands and status pages for migrations
3. Pathauto generates URL aliases for imported content
4. Redirect isn't part of the core migration, but install it separately for permanent redirects from old WordPress URLs to new ones

How Do You Run the WordPress Migrate Wizard?

The WordPress Migrate UI lives under Structure > Migrate in your Drupal admin. It is an important part when you’re trying to generate WordPress content and import into Drupal, as it walks you through uploading the WXR file, setting the source site's URL, and configuring how WordPress content maps to Drupal content types, fields, and taxonomies during.

Enter the original WordPress site's base URL exactly when you import WordPress content into Drupal, or your new paths build around the old domain instead of clean local ones. Step through the wizard, review each mapping, and click Execute. A progress bar runs while Drupal processes the batch. drush migrate:import --all does the same job from the terminal, and you may need to run it twice before dependencies clear.

Why Does Content Still Look Broken After the Import?

A handful of migration mistakes and issues show up almost every time, and none of them mean the migration failed.

1. Inline images. Featured images are supported, but validate when performing WordPress content migration to Drupal rather than assume perfection; the issue queue notes known gaps around captions and alignment. Images embedded in post bodies can retain references to old WordPress URLs, so check them rather than assume every reference was rewritten. If those references still point to the old site, you may need a follow-up media migration or a find-and-replace pass to update them.
2. Shortcodes. WordPress shortcodes such as [gallery] or [caption] mean nothing to Drupal's text filters and render as literal bracketed text. Handling this during migration, via a Migrate process plugin, beats teaching text filters WordPress syntax later.
3. Broken URLs and lost rankings during WordPress Drupal migration. WordPress permalinks like /2023/05/my-post-title won't matchDrupal's default paths, and Pathauto won't preserve the old ones automatically. Configure Pathauto's patterns for the aliases you want, map each old path to its new equivalent, then install Redirect for 301s from old to new before you point DNS anywhere.
4. Custom post types, ACF/SCF fields, and Gutenberg blocks. These need handling beyond the standard WordPress Migrate workflow. Native support for custom post types and ACF/SCF data are open feature requests, and Gutenberg block content isn't migrated as native Drupal structured blocks; plan for extra transformation if your site needs equivalent components.

What Is the Best Way to Migrate a Large or Complex WordPress Site? 

Size alone usually isn't the deciding factor. What pushes a project toward a direct database connection is usually a combination of scale and complexity: large content volumes, years of plugin data, or content a standard WXR export doesn't represent cleanly. For automated content migration to Drupal, a direct SQL migration also gives developers access to WordPress database data they can map with custom migration logic, including plugin-specific fields and custom post types. 

WordPress Migrate SQL, built by Metadrop, does this. Its stable release targets Drupal ^11.2, so check that against your version first. Instead of a WXR file, it reads data directly from WordPress's database: wp_posts, wp_terms, wp_users, wp_term_relationships, and attachment records, which WordPress stores as posts too. This approach can be useful for WordPress to Drupal content migration when you need access to data that a standard WXR export doesn't represent cleanly. Your Drupal environment needs network access to that database, with an account holding sufficient read access, typically SELECT on the tables being migrated. The module can also be extended to read plugin-specific data not represented in the standard WXR migration, such as translation plugin data, though that isn't automatic. 

The module offers two paths: the "WordPress Migrate SQL - Basic" submodule for a zero-code import on standard sites, or drush generate wordpress-migration to scaffold a custom module with migrations for users, terms, attachments, and posts, ready to customize for legacy markup or shortcodes.

Final Thoughts

A WordPress to Drupal content migration takes patience more than raw technical skill. Export the WXR file, get your content types and modules ready, run the wizard, then validate the details that decide whether it worked: images, taxonomies, fields, shortcodes, and redirects.

Hit a wall in the process? Contact our experts and get started with content migration from WordPress to Drupal.