The most expensive Joomla to WordPress migration problems are the ones nobody notices until after the domain switch. K2 articles that were never in #__content and therefore never imported. SEF URL paths that changed silently because the migration tool generated slugs from titles rather than the Joomla alias field. VirtueMart products that exist only in the old database because the migration tool did not have the add-on to read them. This checklist catches those problems on staging, before they reach production.
How to Use This Checklist
Run through every item on a staging environment that represents the final pre-launch state of the WordPress site. The domain should not be switched until every item passes. The checks are ordered by impact: content completeness first, then URL and SEO integrity, then technical health, then go-live. A problem discovered at item 3 is far cheaper to fix than one discovered a week after launch when it appears in Google Search Console.
Phase 1: Content Completeness (6 Checks)
1. Article count matches the Joomla source
Run this query on the Joomla database: SELECT COUNT(*) FROM #__content WHERE state=1 (where 1 = published). Compare this to the published post count in the WordPress admin. Any discrepancy means articles were silently skipped. A common cause: the migration only imported articles in the default category and ignored articles assigned to subcategories that were not fully mapped.
2. K2 content is present, if K2 was installed
Check whether K2 is installed on the Joomla site by querying: SELECT COUNT(*) FROM #__k2_items WHERE published=1. If the count is greater than zero, those items must exist as WordPress posts or custom post type entries. K2 content in #__k2_items is separate from standard articles in #__content. A migration that processed only #__content will show a normal article count while every K2 item is missing. Cross-check the K2 item count against the corresponding WordPress custom post type count.
3. Custom field values are present on articles
If Joomla’s native custom fields were used (Joomla 3.7+), verify that the values are present in WordPress. Open five articles that had custom fields set in Joomla and check that the corresponding ACF Pro fields are populated in the WordPress post editor. Run this query on the Joomla database to check how many field values exist: SELECT COUNT(*) FROM #__fields_values. If the number is significant and the ACF fields are empty in WordPress, the custom field values were not migrated.
4. User accounts and roles are correctly mapped
Compare the user count in Joomla (SELECT COUNT(*) FROM #__users WHERE block=0) with the WordPress user count. Then check roles: open five user accounts in the WordPress admin and verify their assigned role matches their Joomla group. Joomla Publishers should be WordPress Editors. Joomla Authors should be WordPress Authors. Joomla Registered users should be WordPress Subscribers. A migration that did not configure role mapping will assign all imported users the Subscriber role regardless of their Joomla group.
5. Media files imported with alt text
Open the WordPress Media Library and check the total file count against the number of image files in the Joomla /images/ folder. Open five imported images and check that the alt text field is populated. Joomla stores alt text as an attribute in the article body HTML rather than in a centralized media table. The migration must parse image tags in article body text to extract and write alt text to the WordPress attachment alt field. Empty alt text across all imported images indicates this step was not handled.
6. VirtueMart or WooCommerce products match, if VirtueMart was installed
If the Joomla site used VirtueMart, query SELECT COUNT(*) FROM #__virtuemart_products WHERE published=1 on the Joomla database. Compare this to the WooCommerce product count in WordPress. Any gap means VirtueMart products were not migrated. Check that product categories exist in WooCommerce, that product images are attached, and that product attributes and pricing are present. VirtueMart data migration is not handled by the standard FG plugin and requires either the VirtueMart add-on or a custom migration process.
Phase 2: URLs and SEO Integrity (5 Checks)
7. Article slugs match the original Joomla aliases
This is the most important single check in the entire list. Take 20 article URLs from the live Joomla site and test each one on the WordPress staging environment. The Joomla alias field on each article (stored in #__content.alias) should be used as the WordPress post slug. If the migration generated slugs from article titles rather than the alias field, many slugs will be different. Every different slug needs a 301 redirect before go-live. Missing redirects at this stage become 404 errors for every inbound link and indexed search result pointing to those URLs.
8. Category URL paths are preserved or redirected
Check category archive URLs. Joomla category pages have URL patterns that depend on the menu structure (e.g. /news/category-name). WordPress category archives have different default URL patterns (e.g. /category/category-name). Every Joomla category URL that is different in WordPress must have a 301 redirect. Test category URLs from the original site on the staging environment and verify they return a 301 response pointing to the correct WordPress category archive.
9. SEO metadata is present on representative pages
Open five article posts in WordPress and check the Yoast SEO panel. The SEO title and meta description fields should be populated with values from the Joomla article metadata fields. If both fields are auto-generated (showing the article title and the first excerpt respectively) rather than set explicitly, the Joomla metadata was not transferred. Articles with no custom SEO title in Joomla will legitimately show auto-generated Yoast titles, but articles that had explicitly set metadata in Joomla should show those values in Yoast.
10. 301 redirects cover all changed URLs
Using a tool like Screaming Frog or a spreadsheet of the original Joomla URLs, test each URL on the staging environment. Any URL that returns a 404 needs a 301 redirect. Any URL that returns a 200 should be confirmed as pointing to the correct content (not a redirect loop or a wrong destination). Pay particular attention to the category-path URLs that are specific to Joomla’s router: /component/content/article/category-alias/article-alias format URLs are common on older Joomla sites and do not translate to WordPress permalink structures automatically.
11. Canonical tags are correct
Check the canonical tag on five representative pages using browser developer tools or a page source inspection. The canonical must point to the final clean URL on the new WordPress site with the correct live domain, correct protocol (https), and no trailing inconsistencies. Canonical tags pointing to the old Joomla domain, to a staging URL, or to the wrong page will distribute ranking signals incorrectly and can persist undetected for months.
Phase 3: Technical Health (2 Checks)
12. Page speed is comparable to or better than the original site
Run the homepage and two representative inner pages through Google PageSpeed Insights and compare the scores to the original Joomla site. A significant regression indicates unoptimized images from the migration, a heavyweight theme, or missing caching configuration. Resolve speed issues before the domain switch. Page speed affects rankings, and a regression immediately after migration can amplify the impact on organic traffic during the adjustment period.
13. Contact forms and registration forms are functional
Submit a test entry through every form on the site. Verify that the submission appears in the WordPress form plugin’s inbox, that confirmation emails are sent from the correct address, and that notification emails reach the intended recipient. Joomla form extensions (Akeeba forms, Fabrik, JotForm integrations) use different notification configurations than WordPress form plugins. Notification routing must be explicitly reconfigured on the new installation.
Phase 4: Go-Live (2 Checks)
14. Redirects survive the domain switch with correct live URLs
After pointing the live domain at the WordPress installation, re-run the URL tests from check 10. Redirects configured with the staging domain hardcoded in the Location header will break after the domain switch. Verify that every redirect uses a relative path or the correct live domain, not the staging URL. This check must be run on the live environment after the DNS change propagates.
15. Google Search Console property verified and sitemap submitted
Verify the live WordPress domain in Google Search Console, submit the XML sitemap generated by Yoast SEO, and monitor crawl errors over the first two weeks after launch. A Joomla site may have had a manually managed sitemap or an extension-generated sitemap that Google was familiar with. Submitting the new Yoast-generated sitemap immediately after launch gives Google a complete URL list for the new site and accelerates its processing of the migration. Monitor the Coverage report for any unexpected 404 or 301 patterns in the first 14 days.
Why Most Joomla Migrations Miss These Checks
The most common root cause of failed checks on this list is the same in every case: the migration did not read the source database completely. A tool that processed only #__content missed K2 content, custom field values, and the alias fields needed for accurate URL preservation. A developer unfamiliar with Joomla’s extension table structure did not know which tables to check.
gConverter migrates Joomla sites by reading every relevant table in the source database directly. Every check on this list is covered before the staging environment is presented to the client. The domain switch does not happen until the client confirms every item on this list.
How gConverter Handles Your Data
Your Joomla database contains personal data subject to GDPR. Before any access, gConverter signs a Data Processing Agreement. Credentials are AES-256 encrypted, transferred over TLS 1.3, and deleted within 24 hours of project completion. All client data is permanently deleted within 30 days with written confirmation. We provide 72-hour breach notification under GDPR Article 33.
Read the data protection documentation →
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 to WordPress migration that passes all 15 checks on this list has no silent content loss, no broken URLs, no missing SEO signals, and no surprise 404 errors in the first month of traffic. That outcome requires reading the full source database, including K2 tables, custom field tables, VirtueMart tables, and the alias fields that determine the correct slug for every article. It requires verification on staging before the domain switch. It does not happen automatically by running a plugin.