Most Drupal to WordPress migration problems are not discovered during the migration. They surface two weeks after go-live when a client notices that their category pages return 404 errors, or that the blog shows content from 2019 but nothing published this year, or that a contact form has been silently losing submissions since launch. This checklist is not about how to migrate. It is about how to verify that a migration was done correctly before you switch the domain.
How to Use This Checklist
This checklist applies whether you are verifying your own migration, evaluating a staging environment delivered by a developer or agency, or auditing a live site after a migration that went poorly. Work through it top to bottom on the staging environment before the domain is pointed at the new WordPress installation. If you are verifying a live migration after the fact, most checks still apply. The earlier you identify an issue, the cheaper it is to fix.
Phase 1: Content Completeness (4 Checks)
1. Total content count matches
Count the published nodes in Drupal by content type: run SELECT type, COUNT(*) FROM node WHERE status=1 GROUP BY type in the Drupal database. Compare this to the post counts per post type in the WordPress database. A significant discrepancy means content was silently skipped during migration. This is the most common failure mode, and it is easy to miss if you only spot-check rather than count.
2. Custom field values are populated
Pick ten content items at random that had Drupal custom field values (dates, related content, file attachments, number fields). Open each in the WordPress admin and verify that the corresponding ACF Pro fields are populated with the correct data. Field data is stored in Drupal’s field_data_ tables and requires explicit database-level migration to appear in WordPress. HTML scrapers miss it entirely. If these fields are empty, the migration relied on rendered HTML output rather than a direct database migration.
3. Media library is complete
Check the total file count in Drupal’s file_managed table and compare it to the WordPress Media Library count. Open several representative posts and click every image and file download link. All should resolve. Broken image references indicate that media was not imported or that the paths were not updated after import.
4. User accounts are present
Check the user count in Drupal’s users table (excluding the anonymous user at UID 0) and compare to the user count in WordPress. Open several user profiles and verify that author attribution on posts is correct. User metadata fields (first name, last name, any custom profile fields) should be present in WordPress user meta.
Phase 2: URLs and SEO Preservation (5 Checks)
5. URL structure is preserved or redirected
Take twenty URLs from your Drupal site (a mix of pages, blog posts, taxonomy archive pages, and user profile pages). Test each on the new WordPress installation. Each URL should either resolve correctly at the same path, or return a 301 redirect to the equivalent WordPress URL. A 404 response means the URL is broken with no redirect in place. Check with a tool like Screaming Frog or simply use curl -I on each URL.
6. Drupal URL aliases were read correctly
Drupal stores human-readable URL aliases in the url_alias table (Drupal 7) or path_alias entity (Drupal 8+). These aliases are what users and search engines see. If the migration used default WordPress slugs generated from the post title rather than the original Drupal URL aliases, the URLs will be different and no redirects will have been created. Verify that the slug on each migrated post in WordPress matches the Drupal URL alias for the same content item.
7. SEO title and meta description are set
Open five representative posts in the WordPress admin and check whether the Yoast SEO (or equivalent) title and meta description fields are populated. On Drupal, these are typically stored in the Metatag module’s data. If the migration did not read those fields and write them to the WordPress SEO plugin, every page will default to the auto-generated SEO title, and any custom meta descriptions from the Drupal site will be lost.
8. Taxonomy archive pages resolve
Category and taxonomy archive pages are some of the most commonly broken after migration. Test the archive URL for each category and custom taxonomy. The page should load and display the correct posts. Also verify that the category slug matches the Drupal vocabulary term name or URL alias that was in use.
9. Canonical tags are correct
Use a browser developer tool or a site auditing tool to check the canonical tag on five representative URLs. The canonical should point to the final clean URL on the new WordPress site, not to the old Drupal URL or a staging domain. A wrong canonical is an SEO error that can persist for months without anyone noticing.
Phase 3: Technical Health (4 Checks)
10. No 404 errors in Google Search Console
If the new site is already indexed (or if you are doing a post-migration audit), check Google Search Console for 404 errors. Any URL that Google had previously indexed and that now returns a 404 is a ranking signal being wasted. These should all be 301 redirected to the closest equivalent page on the new WordPress site.
11. Page speed is comparable or better
Run the homepage and two inner pages through Google PageSpeed Insights or GTmetrix. Compare the scores to the original Drupal site if you have a record. A significant regression in page speed after migration usually indicates that media files were not optimized during import, that a heavyweight WordPress theme was applied, or that caching is not configured. Address these before the domain is switched.
12. No mixed content warnings
Open the browser developer console on several pages and check for mixed content warnings (HTTP resources being loaded on an HTTPS page). These are common when media file URLs from the old Drupal site were embedded directly in post content as absolute HTTP URLs and were not updated during migration.
13. Forms are functional and submitting
Submit a test entry through every contact form, quote form, and survey on the site. Verify that the submission appears in the WordPress admin, that confirmation email is sent to the right address, and that any notification email arrives correctly. Form functionality is frequently broken after migration because the form plugin is not configured with the correct email address or SMTP settings.
Phase 4: Forum and Community Content (2 Checks)
14. Forum history is present and attributed correctly
If the Drupal site used the Forum module or any community discussion system, all topics and replies should be present in the WordPress forum plugin (typically wpForo). Open several topics and verify that the original author name and post date are preserved. Check that the forum category structure matches the original Drupal forum container hierarchy.
15. Member roles match expected access levels
Log in with a test account that had a non-administrator role in Drupal (for example, an editor or moderator). Verify that the role mapping to WordPress user roles was done correctly and that the access level matches what that role should have in the new WordPress environment.
Phase 5: Go-Live Verification (2 Checks)
16. 301 redirects survive the domain switch
After the domain is pointed at the new WordPress site, re-run the URL test from check five. The 301 redirects should continue to work with the live domain, not just on the staging URL. Some redirect configurations break when the domain changes if the redirects were configured with the staging domain hardcoded.
17. Old Drupal URLs still resolve via CDN or hosting
If the old Drupal site was cached by a CDN, the CDN may continue to serve the old site on old URLs even after the domain is switched. Purge the CDN cache for the domain and verify that old Drupal URLs correctly resolve to the new WordPress site with the expected 301 redirects. Stale CDN cache is a common source of post-launch confusion where some visitors see the old site and some see the new one.
Why Most Migrations Fail These Checks
The majority of failed checks on this list have a common root cause: the migration relied on scraping the rendered HTML output of the Drupal site rather than reading the source database directly. Scraping-based migration captures what the page looks like but misses everything stored in the database that does not render on the page: custom field values, URL alias configurations, SEO metadata, user profile data, and unpublished content. A database-level migration reads each piece of structured data directly from its Drupal source table and writes it to the correct WordPress destination.
gConverter migrates Drupal sites at the database level. Every check on this list is covered as part of the standard migration process: content counted and verified, custom field values mapped to ACF Pro, URL aliases read directly from the Drupal database, SEO metadata transferred to Yoast SEO, user accounts imported with role mapping, forum history migrated to wpForo, and a full 301 redirect map in place before the domain is switched.
How gConverter Handles Your Data
A Drupal database contains your registered users’ personal data, form submission records, and potentially years of community forum history. Before any access to your site’s credentials or database, gConverter signs a Data Processing Agreement. Credentials are stored in AES-256 encrypted vaults, transferred over TLS 1.3, and all client data is permanently deleted within 30 days of project completion. We are a registered US company with full EU GDPR compliance and a documented 72-hour breach notification process.
Read the GDPR and data protection documentation →
For the full technical picture of how Drupal content, fields, and modules map 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
A migration that passes all 17 checks on this list is a migration you can go live with confidence. One that fails on URL preservation, custom field values, or SEO metadata is a migration that will cost you rankings and content integrity over the months that follow launch. The work to do it right happens before go-live, not after.