How to Migrate from Drupal to WordPress: 7 Easy Steps

Problem Statement & Impact

Migrating enterprise content management systems from Drupal to WordPress introduces complex architectural, data transformation, and security challenges. The fundamental differences between Drupal’s entity-attribute-value (EAV) storage model and WordPress’s structured relational database schema (utilizing posts, postmeta, terms, and term_relationships) mean that native data structures cannot be directly interchanged. Attempting a naive database migration results in broken foreign keys, orphaned metadata, corrupted serialization strings, and compromised user permission mappings.

Affected environments include enterprise Linux server stacks running PHP 8.1 or higher, MySQL 8.0 or MariaDB 10.5+, and NGINX or Apache web servers hosting high-traffic publishing platforms. In enterprise scenarios involving millions of nodes, taxonomy terms, and user revisions, migration projects frequently encounter HTTP gateway timeouts, PHP memory exhaustion errors, and database deadlocks.

The business and security consequences of an unmitigated or poorly executed migration are severe. Incomplete content mapping leads to broken internal links and a catastrophic loss of search engine optimization (SEO) equity, culminating in immediate drops in organic traffic and revenue. Furthermore, inadequate server hardening and improper permission mapping during the staging-to-production cutover expose the new WordPress core, plugins, and REST API endpoints to automated vulnerability scanning, remote code execution (RCE) attempts, and privilege escalation exploits. Ensuring a deterministic, secure migration path requires strict adherence to database normalization, automated redirection maps, and aggressive runtime security hardening.

Root Cause Analysis & Architecture

The core technical friction in a Drupal-to-WordPress migration stems from how each platform models content. Drupal stores content using flexible entity types and fields distributed across dozens of tables such as node, node_revision, field_data_field_*, and taxonomy_index. Relationships are established via entity IDs and bundles, allowing for deeply nested hierarchies and polymorphic data structures.

WordPress relies on a rigid, highly optimized five-table core schema:

• wp_posts: Stores all content types (posts, pages, custom post types, attachments, and revisions) in a unified table.
• wp_postmeta: Stores arbitrary key-value pairs associated with posts, handling custom fields and metadata.
• wp_terms, wp_term_taxonomy, and wp_term_relationships: Manage categorizations, tags, and custom taxonomies using a normalized relational model.

During data transformation, Drupal nodes must be flattened and mapped directly into wp_posts, while node body fields, body summaries, and custom field values must be extracted and injected into either the post content or serialised/scalar rows within wp_postmeta. Failure to sanitize character sets (e.g., converting Drupal’s utf8mb4_general_ci to WordPress’s expected utf8mb4_unicode_520_ci) during extraction results in character truncation, broken multi-byte strings, and fatal SQL syntax errors.

From an execution lifecycle perspective, monolithic HTTP-based migrations often fail due to PHP execution time limits and memory caps. When a migration script attempts to load thousands of heavy Drupal nodes, parse their XML or JSON payloads, and execute individual database insert queries within a single request context, PHP reaches its memory_limit threshold, triggering a fatal out-of-memory exception. Additionally, concurrent web server timeouts (configured via NGINX proxy_read_timeout or PHP-FPM request_terminate_timeout) abruptly terminate long-running migration scripts, leaving behind partial database transactions and corrupted auto-increment pointers.

Step-by-Step Implementation & Remediation Guide

Executing a robust Drupal-to-WordPress migration requires a controlled, command-line-driven workflow. This guide details the programmatic extraction, data transformation, database import, and structural verification steps.

Step 1: Environment Provisioning and WP-CLI Initialization

Provision a dedicated staging server running Ubuntu 22.04 LTS, NGINX, PHP-FPM 8.2, and MySQL 8.0. Install WP-CLI globally to manage the WordPress installation programmatically.

# Update system packages and install prerequisites
sudo apt update && sudo apt install -y curl git unzip php8.2-fpm php8.2-mysql php8.2-xml php8.2-mbstring php8.2-curl php8.2-zip mysql-server nginx

# Download and install WP-CLI
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# Create WordPress web root and configure permissions
sudo mkdir -p /var/www/html/wordpress
sudo chown -R $USER:$USER /var/www/html/wordpress
cd /var/www/html/wordpress

# Download WordPress core and generate wp-config.php
wp core download --version=latest --locale=en_US
wp config create --dbname=wordpress_staging --dbuser=wp_user --dbpass='StrongSecurePassword_987!' --dbhost=localhost --dbprefix=wp_
wp db create
wp core install --url=https://staging.example.com --title="Migration Staging" --admin_user=admin_migrator [email protected]

Step 2: Drupal Data Extraction via Migration Scripts

Avoid heavy graphical user interface migration plugins that frequently time out. Instead, extract Drupal nodes into a structured JSON payload or intermediate relational format using a custom PHP script or Drupal’s internal migration modules. For large datasets, utilize a dedicated extraction script executed via Drupal’s Drush CLI.

# Navigate to Drupal root directory
cd /var/www/html/drupal

# Export nodes, titles, bodies, and creation dates using Drush
drush php-script export_nodes_to_json.php > /tmp/drupal_migration_payload.json

The extraction script must process nodes in chunks to prevent memory exhaustion:

<?php
// export_nodes_to_json.php
use Drupal\Core\Database\Database;

$connection = Database::getConnection();
$query = $connection->select('node_field_data', 'n');
$query->fields('n', ['nid', 'type', 'title', 'created', 'uid']);
$query->range(0, 5000);
$results = $query->execute()->fetchAll();

$export = [];
foreach ($results as $row) {
    // Fetch body field data
    $body_query = $connection->select('node__body', 'b');
    $body_query->fields('b', ['body_value', 'body_summary']);
    $body_query->condition('b.entity_id', $row->nid);
    $body = $body_query->execute()->fetchAssoc();

    $export[] = [
        'drupal_id' => $row->nid,
        'type' => $row->type,
        'title' => $row->title,
        'content' => $body['body_value'] ?? '',
        'summary' => $body['body_summary'] ?? '',
        'date' => date('Y-m-d H:i:s', $row->created),
        'author' => $row->uid
    ];
}

echo json_encode($export, JSON_PRETTY_PRINT);

Step 3: Programmatic Import into WordPress

Import the generated JSON payload into WordPress using a custom WP-CLI command or a dedicated import script that maps fields correctly into the wp_posts table.

<?php
// import_payload.php
if (!defined('ABSPATH')) {
    exit;
}

$json_data = file_get_contents('/tmp/drupal_migration_payload.json');
$nodes = json_decode($json_data, true);

foreach ($nodes as $node) {
    $post_data = [
        'post_title'   => sanitize_text_field($node['title']),
        'post_content' => wp_slash($node['content']),
        'post_status'  => 'publish',
        'post_date'    => $node['date'],
        'post_type'    => ($node['type'] === 'article') ? 'post' : 'page',
        'post_author'  => 1
    ];

    $post_id = wp_insert_post($post_data);

    if (!is_wp_error($post_id)) {
        // Store original Drupal ID in postmeta for reference and redirection mapping
        update_post_meta($post_id, '_drupal_node_id', $node['drupal_id']);
    }
}
WP_CLI::success("Migration payload successfully imported.");

Execute the import script via WP-CLI:

wp eval-file /path/to/import_payload.php --path=/var/www/html/wordpress

Step 4: Configuring Permanent 301 Redirects

To preserve search engine rankings, map old Drupal URL structures (e.g., /node/{nid}) to new WordPress permalinks. Implement these rules directly within the NGINX server block to avoid overhead from PHP-based redirect plugins.

# NGINX Configuration for Drupal-to-WordPress URL Rewrites
server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    root /var/www/html/wordpress;
    index index.php index.html;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Map old Drupal node paths to WordPress permalink structure
    location ~* ^/node/([0-9]+)$ {
        try_files $uri @drupal_redirect;
    }

    location @drupal_redirect {
        # Internal PHP lookup to resolve old Drupal NID to new WordPress URL via postmeta
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /var/www/html/wordpress/resolve-redirect.php;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Production Hardening & Edge Cases

Moving a site from Drupal to WordPress introduces distinct performance and security challenges that must be addressed before the final DNS cutover.

Database Character Set Normalization

A frequent edge case involves multi-byte character corruption during database imports. If the Drupal database utilized utf8mb4_general_ci and the target WordPress instance uses utf8mb4_unicode_520_ci, special characters, emojis, and non-Latin scripts may render as mojibake. Ensure all tables are explicitly altered prior to import validation:

wp db query "ALTER DATABASE wordpress_staging CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;"
wp db query "CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;"

Object Caching and Transient Bloat

Drupal relies heavily on internal caching tables. When migrating, cache tables should not be transferred. In WordPress, configure Redis or Memcached as an external object cache to offload heavy database queries generated by complex menus, taxonomies, and widget trees. Install the persistent object cache drop-in via WP-CLI:

wp plugin install redis-cache --activate
wp redis enable

WordPress Security Hardening Implementation

WordPress core and administrative directories require stringent access controls to prevent exploitation. Update wp-config.php to disable file editing from the dashboard, enforce SSL, and restrict administrative access:

<?php
// Security Hardening Directives in wp-config.php
define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
define('WP_AUTO_UPDATE_CORE', 'minor');

// Limit post revisions to conserve database storage
define('WP_POST_REVISIONS', 5);

// Secure authentication keys and salts (generate via official API)
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Furthermore, restrict access to sensitive files via NGINX rules:

# Block direct access to wp-config.php and sensitive dot files
location ~* /(wp-config\.php|readme\.html|license\.txt|\.ht) {
    deny all;
    return 404;
}

# Block execution of PHP files inside uploads directory
location ~* /wp-content/uploads/.*\.(php|php5|phtml)$ {
    deny all;
}

Diagnostic Verification & Checklist

To guarantee operational integrity, execute the following verification matrix across staging and production environments before routing live traffic.

Following successful validation of all diagnostic checks, update DNS A and AAAA records to point to the hardened production server. Monitor error logs and traffic analytics continuously to catch any edge-case routing anomalies or missing asset dependencies immediately.