How We Migrate: The Technical Process Behind a Drupal to WordPress Migration

Updated 09 July 2025 (first posted 20 March 2019)

Every Drupal site is different. Custom content types, unique field configurations, contributed modules with their own database tables, and years of accumulated content that doesn't fit neatly into any template. This is why I don't use off-the-shelf migration tools. Instead, I write custom scripts tailored to each site's specific data model, and run the migration iteratively until the output is clean.

Why Custom Scripts, Not Plugins

Automated migration tools like FG Drupal to WordPress work by mapping Drupal's core database tables to their WordPress equivalents. For a basic site with standard posts and pages, this can work. However, most Drupal sites that need professional migration have outgrown standard content types.

Custom content types, field collections, entity references, paragraphs modules, and bespoke database tables. These are the structures that make Drupal powerful and that make automated migration unreliable. My approach works directly against the databases, with scripts that understand your site's specific data relationships.

Phase 1: Content Audit and Mapping

Before writing any migration code, I need to understand your Drupal site's data model in detail. This means mapping every content type, field, taxonomy vocabulary, and relationship in your database.

What the Audit Covers

Content types and their fields. Every node type and its associated field definitions: text, image, file, entity reference, date, address, and any custom field types.
Taxonomy vocabularies. The vocabulary structure, term hierarchies, and how terms relate to content.
User roles and permissions. Which roles exist, what they can access, and how they map to WordPress capabilities.
Media and files. How files are referenced, where they're stored (public vs private filesystem), and any image style derivatives that need handling.
Custom modules and tables. Bespoke functionality that stores data outside Drupal's standard schema.

The output is a mapping document that pairs each Drupal data structure with its WordPress equivalent. This document drives every subsequent decision.

Phase 2: Database Mapping

Drupal and WordPress store content in fundamentally different database architectures. Understanding these differences is essential to writing reliable migration scripts.

Core Table Mapping

At the most basic level, Drupal's node table maps to WordPress's wp_posts. Node IDs become post IDs, creation timestamps convert to WordPress date format, and the node status field translates to WordPress publish states. Content bodies come from a separate revisions table in Drupal and need joining before insertion.

Taxonomy Mapping

Drupal's term_data (Drupal 7) and vocabulary tables map to WordPress's wp_terms and wp_term_taxonomy. The relationship tables that connect content to terms require their own mapping. Drupal allows multiple vocabularies with custom fields. WordPress uses categories, tags, and custom taxonomies, each with different behaviour.

Custom Fields

This is where the complexity lives. Drupal stores custom field data across multiple tables, typically one table per field, with separate columns for each property (value, format, language). WordPress stores custom fields as key-value pairs in wp_postmeta, or in structured formats if using Advanced Custom Fields or similar plugins.

Each custom field needs individual mapping logic. A Drupal entity reference field that links to another node might become a WordPress post relationship managed by ACF, or a simple post meta value, or a custom taxonomy, depending on how the relationship is used in the front end.

Phase 3: Migration Scripts

With the mapping document complete, I write custom scripts (typically a combination of SQL and PHP) that handle the actual data transfer. The scripts work against a copy of your production database, never against the live site.

Key considerations in the scripting phase:

Data type conversions. Drupal stores timestamps as Unix integers; WordPress uses DATETIME strings. Status values, user roles, and content types all need transformation.
Character encoding. Drupal and WordPress may use different encoding for special characters, accented text, and HTML entities. The scripts handle normalisation to prevent garbled content.
Relationship integrity. Content-to-taxonomy, content-to-author, and content-to-content relationships must transfer as a connected dataset. Migrating entities in isolation breaks these links.
Media file handling. File references in the database need updating to point to WordPress's upload directory structure. Physical files are copied separately via rsync or similar tools.

Phase 4: Iterative Testing

This is the phase that separates professional migration from a best-effort attempt. I run the migration scripts repeatedly (typically 5 to 20 cycles per project), with each iteration refining the output.

What Each Test Cycle Checks

Data completeness. Did every piece of content come across? Are any fields missing or truncated?
Relationship integrity. Are taxonomy terms correctly assigned? Do author attributions match? Are related content links valid?
Visual accuracy. Does the content render correctly in the WordPress theme? Are images displaying, embeds working, and formatting intact?
Edge cases. Content with unusual characters, extremely long fields, empty values, or draft states. These are the entries that break on the first pass and get fixed in subsequent cycles.

Each cycle produces a test report documenting what was fixed and what needs attention in the next run. The site owner reviews key content at each stage to confirm accuracy.

Phase 5: URL Mapping and Redirects

Once the content migration is stable, I build the redirect map. Every Drupal URL alias is paired with its new WordPress URL, and 301 redirects are configured at the server level.

This phase works in parallel with the SEO preservation strategy. For sites with significant organic traffic, I audit the URL list against analytics data to prioritise the pages that matter most. The redirect rules are tested before launch to ensure no high-value URLs return 404 errors.

Phase 6: Zero-Downtime Launch

For business-critical sites, downtime during migration isn't acceptable. The launch process uses a staged approach:

Build on staging. The WordPress site is built and populated on a staging server, with all test cycles completed there.
Final delta migration. A last-pass script migrates any content created or updated since the previous full migration.
DNS cutover. DNS records are updated to point to the new WordPress server. The old Drupal site remains available as a fallback until the transition is verified.
Post-launch verification. Content spot-checks, redirect testing, analytics confirmation, and search console monitoring in the first 48 hours.

The total migration timeline typically runs 4 to 12 weeks, depending on the complexity of the content model, the volume of data, and the number of test cycles needed to achieve clean output.

Related reading:

Want to Understand What Your Migration Involves?

I provide a detailed content audit and migration plan before any work begins. Get a free consultation to discuss your Drupal site's technical requirements.

Get a Free Quote