The most common reason a Joomla to WordPress migration loses data is not that the migration tool failed. It is that the tool only knew about the core Joomla tables and ignored the extension tables where a significant portion of the content actually lives. K2 items in #__k2_items, VirtueMart products in #__virtuemart_products, Joomla custom field values in #__fields_values: these are the tables that generic tools and inexperienced developers routinely miss.
How Joomla Structures Content Differently From WordPress
Joomla organizes content around a section-category-article hierarchy. In older Joomla 2.5 installations, content had three levels: sections, categories, and articles. In Joomla 3, sections were deprecated and the structure became category-article with unlimited nesting. Articles are stored in the #__content table. Categories are in #__categories. The table prefix #__ is configurable per installation and appears as the actual prefix in the database (commonly jos_ or a custom string).
WordPress uses a flatter model: posts in wp_posts, categories and tags in wp_terms and wp_term_taxonomy, with additional structured data in wp_postmeta via ACF Pro. The migration maps Joomla’s distributed content tables to WordPress’s consolidated model explicitly, table by table.
The Full Content Mapping Reference
| Joomla Element | Joomla Storage | WordPress Equivalent | Notes |
|---|---|---|---|
| Articles (standard content) | #__content table | WordPress Posts (post_type=post) | Title, body, intro text, author, date preserved |
| Static pages | #__content with is_static=1 or menu type=article | WordPress Pages (post_type=page) | Parent-child hierarchy from categories |
| Categories | #__categories table (hierarchical) | WordPress Categories (custom taxonomy) | Full hierarchy preserved |
| K2 articles (K2 extension) | #__k2_items table | WordPress Custom Post Type + ACF Pro fields | Requires explicit K2 table migration |
| K2 categories | #__k2_categories table | WordPress Custom Taxonomy | K2 hierarchy preserved |
| K2 extra fields | #__k2_extra_fields + #__k2_extra_fields_values | ACF Pro custom fields | Per-field explicit mapping required |
| Custom fields (Joomla 3.7+) | #__fields + #__fields_values tables | ACF Pro custom fields (wp_postmeta) | Field type mapping required |
| Registered users | #__users table | WordPress Users (wp_users) | Passwords hashed differently, reset on login |
| User groups / permissions | #__usergroups + #__user_usergroup_map | WordPress User Roles (wp_capabilities) | Group-to-role mapping explicit |
| Tags (Joomla 3.1+) | #__tags + #__contentitem_tag_map tables | WordPress Tags (wp_terms) | Tag-article relationships preserved |
| Media / images | Joomla /images/ folder + #__content references | WordPress Media Library (wp_posts type=attach) | All referenced images imported with alt text |
| Navigation menus | #__menu + #__menu_types tables | WordPress Nav Menus (wp_nav_menus) | Menu hierarchy and link targets preserved |
| HTML modules (sidebar content) | #__modules table (module_type=mod_custom) | WordPress Widgets / Text Blocks | Custom HTML module content migrated |
| VirtueMart products | #__virtuemart_products + #__vm_product_details | WooCommerce Products | Requires dedicated VirtueMart migration |
| VirtueMart categories | #__virtuemart_categories table | WooCommerce Product Categories | Category hierarchy and images preserved |
| Joomla template (CSS + PHP) | templates/ folder + TemplateManager config | Custom WordPress PHP theme | Not portable, rebuilt from scratch, 1:1 visual |
| SEF URLs (sh404sef or Joomla router) | #__redirect_links or router config + aliases | WordPress permalink slugs + Redirection 301s | Every URL preserved or redirected |
| Joomla SEO metadata (JSitemap etc.) | Extension-specific metadata tables | Yoast SEO post meta (_yoast_wpseo_*) | Title, description per article |
| Joomla Forum (Kunena) | Kunena extension tables (#__kunena_*) | wpForo 360° AI | Topics, replies, members preserved |
Articles: The Core Migration
Standard Joomla articles live in the #__content table. Each row contains the article title, the full article text (fulltext field), the intro text (introtext), the publication state, the author UID, the creation date, the category ID, and the alias field that determines the SEF URL segment for that article.
A proper migration reads each row from #__content and creates a corresponding WordPress post. The introtext and fulltext are concatenated in the correct order. The alias field is used as the WordPress post slug, preserving the URL. The author UID is mapped to the corresponding WordPress user. The category ID is mapped to the corresponding WordPress category. The creation date and modification date are preserved. Published and unpublished states are mapped to publish and draft respectively.
K2 Extension: The Hidden Content Layer
K2 is one of the most widely used Joomla extensions for content management. It extends Joomla’s native article system with custom content types, extra fields, image galleries, and a richer frontend display. K2 stores its content in completely separate database tables: #__k2_items for articles, #__k2_categories for categories, #__k2_extra_fields for field definitions, and #__k2_extra_fields_values for field values per item.
None of these tables are read by tools that only know the standard Joomla schema. A migration that processes #__content and ignores K2 tables silently loses every K2 article, every K2 category, and every structured extra field value that was entered into K2 items. For sites that used K2 as their primary content management system, this means losing the majority of the site’s content.
A proper migration reads #__k2_items, creates a WordPress custom post type for K2 content, maps K2 categories to a custom taxonomy, and maps every K2 extra field value to the corresponding ACF Pro field. The result is a WordPress site where K2 content is fully present with all structured data intact.
Joomla Custom Fields to ACF Pro
Joomla 3.7 introduced native custom fields for articles. Custom field definitions are stored in #__fields and the values entered per article are in #__fields_values. These are linked by the field ID and the article ID respectively.
Each custom field type in Joomla (text, textarea, calendar, checkboxes, list, radio, media, integer, URL) maps to a corresponding ACF Pro field type in WordPress. A proper migration reads the field definitions from #__fields, creates the corresponding ACF Pro field group in WordPress, reads the values from #__fields_values, and writes them to WordPress post meta with the correct ACF field key prefix.
Users and User Groups
Joomla’s user system uses a group-based permission model. Frontend users (public visitors who register on the site) and backend users (administrators, editors, authors) are all in the #__users table. Their group assignments are in #__user_usergroup_map. The group hierarchy (Registered, Author, Editor, Publisher, Manager, Administrator, Super Users) is in #__usergroups.
A proper migration reads all rows from #__users, creates corresponding WordPress user accounts, and maps Joomla’s group structure to WordPress’s role system: Registered maps to Subscriber, Author maps to Author, Editor maps to Editor, Publisher maps to Editor, Manager maps to Administrator, Super User maps to Administrator. Custom Joomla user groups require explicit role mapping decisions before migration begins.
Kunena Forum to wpForo
Kunena is the most widely used forum extension for Joomla. Sites using Kunena have potentially years of forum discussion history stored in Kunena’s own database tables. A proper migration reads Kunena forum categories and maps them to wpForo 360° AI forum categories, migrates forum topics with original author attribution and timestamps, and migrates replies nested correctly under their parent topics. The community history accumulated on the Joomla site arrives in WordPress complete, with wpForo 360° AI’s AI moderation, member ranks, and subscription system available from day one.
URLs: The Most Important Migration Detail
Joomla’s Search Engine Friendly URL system produces URL patterns that depend on the Joomla router configuration, the menu structure, and the alias fields on articles and categories. The exact URL for any given article is determined by how the menu items are configured, which category the article is in, and whether extensions like sh404sef are installed to modify the URL output.
A proper migration reads the alias field from each #__content row and uses it as the WordPress post slug. Where the Joomla URL structure includes category paths (e.g. /news/technology/article-title), the migration creates matching parent-child page structures or sets up 301 redirects from the full Joomla URL to the equivalent WordPress permalink. No URL returns a 404 on the new site.
How gConverter Handles Joomla Migrations
gConverter migrates Joomla sites by reading every relevant table in the source database directly. Standard articles from #__content, K2 content from #__k2_items, custom field values from #__fields_values, user accounts with group mapping, Kunena forum history to wpForo 360° AI, all media to the WordPress Media Library, all URL aliases preserved or redirected, and all SEO metadata transferred to Yoast SEO. Before any access, we sign a Data Processing Agreement. Credentials are AES-256 encrypted, transferred over TLS 1.3, and deleted within 30 days of delivery.
Read the data protection documentation →
For the full picture of why organizations are leaving Joomla: Why Businesses Are Moving From Joomla 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
A Joomla site is not a single-table database. It is a distributed content model spread across core tables, K2 extension tables, custom field tables, the user group system, the menu structure, and potentially VirtueMart or Kunena extension tables. A migration that reads only the core tables produces a site that looks complete on the surface while silently missing structured content that may represent the majority of the editorial work done on the original site.