The hardest part of a Drupal to WordPress migration is not the technical process of moving files and database records. It is understanding how Drupal’s content architecture maps to WordPress’s, because the two platforms model content in fundamentally different ways, and a migration that ignores those differences loses structured data silently.
The Core Architecture Difference
Drupal is built on an entity model. Every piece of content is a node, and every node has a type. The fields on that node type are defined using the Field API (or CCK in older Drupal 7 installations). Taxonomies are first-class entities with their own field storage. The architecture is powerful and flexible, but it means a single article in Drupal might have its data spread across a dozen database tables: node, node_revision, field_data_body, field_data_field_image, field_data_field_related_content, field_revision_field_tags, and more.
WordPress uses a simpler model. Content is stored in wp_posts with most core fields (title, content, author, date, status) as columns. Additional structured data is stored in wp_postmeta as key-value pairs. ACF Pro (Advanced Custom Fields) extends this by providing a managed field system that maps fields to post meta records with proper data types. The mapping from Drupal‘s field API tables to WordPress‘s post meta system via ACF is direct but requires explicit per-field configuration for every content type.
The Full Content Mapping Reference
| Drupal Element | Drupal Storage | WordPress Equivalent | Notes |
|---|---|---|---|
| Node (article type) | node + field_data_* tables | WP Post (post_type=post) | Body, title, author, date preserved |
| Node (basic page type) | node + field_data_* tables | WP Page (post_type=page) | Supports full page hierarchy |
| Custom node type | node + custom field_data_* tables | Custom Post Type + ACF Pro fields | Fields mapped one-to-one |
| Paragraphs module items | paragraphs_item + field_data_* tables | ACF Flexible Content / Gutenberg Blocks | Complex layouts require per-block rebuild |
| CCK / Field API fields | field_data_field_* tables per field | ACF Pro custom fields (wp_postmeta) | Date, image, file, text, number all supported |
| Taxonomy vocabulary | taxonomy_vocabulary table | Custom taxonomy (register_taxonomy) | Hierarchy preserved |
| Taxonomy term | taxonomy_term_data + term_hierarchy | WP term (wp_terms + wp_term_taxonomy) | Term slugs and parent IDs mapped |
| Views module (display) | views_view table + rendered output | WP_Query + custom archive templates | Logic must be rebuilt; rendered output not portable |
| Drupal Forum module | forum + comment tables + node type | wpForo 360° AI (forum categories + topics) | Topics, replies, author attribution preserved |
| Drupal Webform | webform + webform_submitted_data tables | Gravity Forms / WPForms | Submission history archived |
| Drupal Comments | comment table | WP native comments (wp_comments) | Author, date, content, parent thread |
| Drupal User | users + users_roles tables | WP User (wp_users + wp_usermeta) | Roles mapped; passwords require reset on login |
| User profile fields | profile_value (profile2 module) | WP user meta via ACF User fields | Custom fields mapped explicitly |
| Managed files / Media | file_managed + field_data_field_image | WP Media Library (wp_posts type=attachment) | Filenames, alt text, captions preserved |
| URL aliases | url_alias table (D7) / path_alias entity | WP post slug + Redirection plugin 301s | Each alias either becomes slug or a redirect |
| Metatag module fields | metatag table per entity | Yoast SEO post meta (_yoast_wpseo_*) | Title and description per post |
| Menu links | menu_links table | WP navigation menus (wp_nav_menus) | Hierarchy and URL targets preserved |
| Blocks (regions) | block table + block_custom | WP Widgets + Template parts (PHP) | Custom block content rebuilt in theme |
| Node revisions | node_revision + field_revision_* tables | WP post revisions | Latest published version migrated; history archived |
Nodes to Posts: The Core Migration
Every piece of content in Drupal is a node. The node type determines which fields are attached and how the content is displayed. In WordPress, the equivalent is a post type: built-in post types (post, page) plus custom post types for any structured content beyond standard articles and pages.
Drupal article nodes map to WordPress posts. Drupal basic page nodes map to WordPress pages, preserving the parent-child hierarchy from the Drupal menu_links table. Custom node types (event, product, staff profile, case study) map to custom post types registered in WordPress with a matching set of ACF Pro fields for every custom field defined in Drupal.
The field values for each node are stored in Drupal‘s field_data_field_* tables. A node with a date field, an image field, and a related content field will have three separate field_data_ tables contributing data to that single node. A proper migration reads each of these tables and writes the values to the corresponding ACF Pro field in WordPress post meta. This is why HTML scraping produces incomplete migrations: the scraped page may show a date and an image, but the underlying structured field values are never written to the WordPress database.
Taxonomy: Vocabularies, Terms, and Hierarchy
Drupal uses vocabularies (named groups of terms) as the taxonomy structure. A vocabulary called “Topics” with terms like “Policy”, “Technology”, and “Healthcare” becomes a custom taxonomy in WordPress with matching terms. The hierarchy of terms (parent terms and child terms defined in Drupal’s taxonomy_term_hierarchy table) is preserved in WordPress‘s term parent relationships.
Free tagging vocabularies (flat, unstructured tag lists) map to WordPress tags or custom taxonomy terms depending on how the vocabulary was used. Controlled vocabularies with hierarchical structure become hierarchical custom taxonomies. The term-to-content relationships stored in Drupal‘s field_data_field_tags and similar tables are recreated as WordPress term-object relationships in wp_term_relationships.
CCK and Field API: Custom Fields to ACF Pro
The Field API (and its predecessor CCK, the Content Construction Kit) is how Drupal extends content types with structured custom fields. A typical Drupal site might have an event content type with a start date field (stored in field_data_field_event_date), a location address field (stored in field_data_field_location), and a speaker reference field linking to another content type.
Each of these maps to an ACF Pro field in WordPress. Date fields become ACF Date Picker fields. Address fields become ACF Group fields with sub-fields for street, city, and country. Post reference fields become ACF Relationship or Post Object fields. The migration reads each field_data_field_* table directly and writes the values to WordPress post meta with the ACF field key prefix that ACF Pro uses to validate field data.
Drupal Forum Module to wpForo
The Drupal Forum module stores discussion content as a special node type with comments as threaded replies. Forum containers (top-level forum categories) are vocabulary terms in a Forum vocabulary. Forum topics are nodes of type “forum”. Replies are Drupal comment entities on those nodes.
All of this maps cleanly to wpForo 360° AI in WordPress. wpForo 360° AI forum categories receive the content from Drupal’s forum container terms. wpForo topics are created from the Drupal forum node data with original author attribution and publication timestamp preserved. wpForo replies are created from the Drupal comment data with original commenter names and dates. The result is a fully functional community forum in WordPress with complete historical content, not a blank forum that asks the community to start over.
Views: The One Thing That Cannot Be Ported
The Views module in Drupal is one of the platform’s most powerful features. It allows site builders to create custom lists, archive pages, and data displays through a graphical query builder without writing PHP. A Views display is a configured query against the Drupal database with a template for the output.
Views configurations cannot be ported to WordPress. The Views query model is specific to Drupal’s entity system. The equivalent in WordPress is a custom WP_Query loop inside a page template or archive template, or a plugin like Views for WP. Each Views display used on the Drupal site must be assessed, and its output rebuilt in WordPress through the appropriate mechanism. This is one of the tasks that requires developer time regardless of which migration approach is used.
Paragraphs: The Flexible Layout Challenge
The Paragraphs module is used extensively on modern Drupal sites to build flexible page layouts. A page built with Paragraphs might contain a text block, an image gallery, a testimonial slider, and a CTA section, each as a different Paragraph type with its own field structure. Paragraph data is stored in paragraphs_item and related field_data_field_paragraphs_* tables.
Paragraphs-based layouts map to ACF Flexible Content in WordPress or to custom Gutenberg blocks. Each Paragraph type becomes a layout row in ACF Flexible Content or a Gutenberg block variant. The field values for each Paragraph instance are read from the Drupal tables and written to the ACF sub-fields. This requires rebuilding the visual output of each Paragraph type as a PHP template partial or Gutenberg block before the content migration runs, so that the imported data has a template to render it.
What a Database-Level Migration Covers
gConverter migrates Drupal sites by reading the source database directly. Every node type is mapped, every field value is written to the correct ACF Pro target, every taxonomy relationship is preserved, every URL alias becomes either a matching WordPress slug or a 301 redirect, and Drupal Forum content migrates to wpForo 360° AI with full attribution. The Webform submission history is archived. Metatag SEO data is written to Yoast SEO. Media files are imported to the WordPress Media Library with filenames, alt text, and caption data preserved.
Before any access to your database, we sign a Data Processing Agreement. Your credentials are stored in AES-256 encrypted vaults, transferred over TLS 1.3, and all client data is permanently deleted within 30 days of delivery. We are US-registered with full EU GDPR compliance.
Read the data protection documentation →
For everything about why organizations are moving from Drupal to WordPress: Why Businesses Are Moving From Drupal to WordPress →
What Clients Say
Went FAR above and beyond to help us work through this project. We are thrilled with the final result and they were professional, great to work with, and responsive every step of the way. Would highly recommend.
Anna P., Wilmington NC – Customer Lobby, January 2026
Very few conversion issues on the first pass, and they cleaned it right. Very Impressive.
Stacy C., Katy TX – Customer Lobby, November 2025
The Bottom Line
The content in a Drupal site is not a monolithic blob. It is a structured set of entities with typed fields, explicit taxonomy relationships, URL aliases, and SEO metadata, each stored in specific database tables. A migration that reads those tables explicitly and maps each piece of data to the correct WordPress destination produces a site where every structured field is populated, every URL is preserved or redirected, and every community forum post arrives with its author and date intact. A migration that does not do this produces a site that looks complete on the surface while silently missing years of structured content.