How to Migrate from Drupal to WordPress: Step-by-Step Guide

You have already decided to move from Drupal to WordPress. Now comes the hard part: actually doing it without losing your content, your search rankings, or your sanity.

I recently evaluated a Drupal site with a CRM integration for a nonprofit that was struggling with developer costs and content editor frustration. The decision to migrate was clear. But the migration itself needed a real plan. This guide walks through what I learned and the process I follow when helping organizations make this move.

If you are still weighing whether Drupal or WordPress is the right fit, I wrote a separate Drupal to WordPress comparison article that covers the decision-making side. This article assumes you are ready to go and need the practical steps.

Step 1: Pre-Migration Audit and Content Inventory

Before you touch anything, you need to know exactly what you have. Skipping this step is how migrations go sideways. I have seen organizations start migrating content only to realize halfway through that they forgot about 200 archived event pages or a custom member directory.

Here is what to document:

• Every content type - Drupal calls them "node types." List every one: articles, basic pages, events, staff profiles, resources, whatever your site uses. Note how many items exist in each type.
• Taxonomy vocabularies - Tags, categories, departments, topics. List each vocabulary and how many terms it contains.
• User roles and accounts - How many users do you have? What roles exist (admin, editor, member, etc.)? Which ones actually need to migrate?
• Media files - Images, PDFs, videos. How many? What is the total file size? Where are they stored?
• Custom functionality - Forms, search features, member portals, donation systems, CRM integrations. This is where complexity hides.
• URL structure - Document every URL pattern. Drupal often uses patterns like /node/123 or /content/page-title or custom path aliases.

A thorough website audit at this stage also gives you an opportunity to clean house. Not everything on your current site deserves to make the trip. Outdated blog posts from 2014, duplicate pages, and content nobody visits can stay behind.

Step 2: Choose Your Migration Approach

There are three ways to move content from Drupal to WordPress. Each has tradeoffs.

Automated Migration

Plugins like FG Drupal to WordPress or services like CMS2CMS can pull content directly from your Drupal database into WordPress. This works well for basic content types (posts and pages) and simple taxonomies. It is fast and handles bulk content efficiently.

The catch: automated tools struggle with custom content types, complex field relationships, and embedded media references. If your Drupal site is a straightforward blog or brochure site, automation might get you 80-90% of the way there. If you have custom content types with multiple fields, expect to do significant cleanup.

Manual Migration

Copy and paste, page by page. This sounds tedious and it is. But for smaller sites (under 50 pages), it can actually be the most reliable approach. You get to review every piece of content, clean up formatting issues, and optimize as you go.

I have worked with churches and small nonprofits in the Louisville area that had 20-30 pages of content. Manual migration took a few days but the result was cleaner than any automated tool could produce.

Hybrid Approach (Recommended for Most Sites)

Use automated tools for the bulk transfer of posts, pages, and taxonomies. Then manually review and clean up each piece of content. Handle custom content types, complex layouts, and media files with targeted manual work or custom scripts.

This is what I recommend for most organizations. It balances speed with quality.

Step 3: Map Your Content Types

Drupal and WordPress think about content differently. Drupal has flexible content types with custom fields. WordPress has Posts, Pages, and Custom Post Types. You need a clear mapping before you start moving anything.

Drupal Content Type	WordPress Equivalent	Notes
Article / Story	Posts	Direct mapping, use categories/tags
Basic Page	Pages	Direct mapping
Event	Custom Post Type or Events plugin	The Events Calendar plugin works well
Staff Profile	Custom Post Type or Team plugin	May need ACF for custom fields
Webform submissions	Do not migrate	Rebuild forms in Gravity Forms or WPForms
Taxonomy terms	Categories and Tags	Map vocabularies to WP taxonomies

For Drupal sites with many custom fields, Advanced Custom Fields (ACF) on the WordPress side is your best friend. It lets you recreate the same field structure without writing code. Plan your field groups before you start importing content.

Step 4: Plan Your URL Structure and Redirects

This is the single most important step for preserving your SEO. Get this wrong and you will lose search rankings. Get it right and Google will barely notice the switch.

Drupal and WordPress use different URL patterns by default:

• Drupal: /node/42, /content/about-us, /blog/2024/03/article-title
• WordPress: /about-us/, /2024/03/article-title/, /?p=42

Your goal is to either match the old URLs exactly (ideal) or set up 301 redirects from every old URL to its new location (necessary).

Building Your Redirect Map

Create a spreadsheet with two columns: Old URL and New URL. Every single page on your Drupal site needs an entry. This includes:

• All content pages and their path aliases
• Taxonomy term pages (e.g., /tags/fundraising)
• Author/user profile pages if they were public
• Any custom paths or views pages
• Feed URLs (RSS)

In WordPress, you can implement redirects using the Redirection plugin, Yoast SEO Premium's redirect manager, or server-level redirects in your .htaccess file. For large redirect lists (500+ URLs), server-level redirects perform better than plugin-based ones.

Step 5: Migrate Taxonomies and Users

Taxonomy Migration

Drupal vocabularies map to WordPress taxonomies, but the structure may not be one-to-one. Drupal allows unlimited custom vocabularies. WordPress has Categories and Tags built in, plus custom taxonomies via plugins or code.

For most migrations:

• Map your primary Drupal vocabulary to WordPress Categories
• Map secondary vocabularies to Tags or custom taxonomies
• Preserve parent-child relationships in hierarchical vocabularies
• Clean up unused or duplicate terms before migrating

User Migration

Decide which users actually need to migrate. For a nonprofit or organization site, you might have thousands of user accounts but only 10-20 content editors. CRM contacts are not the same as Drupal users and need to be handled separately.

Key considerations for user migration:

• Passwords will not transfer. Users will need to reset their passwords on the new WordPress site. Plan a communication strategy for this.
• Role mapping - Map Drupal roles to WordPress roles (Administrator, Editor, Author, Contributor, Subscriber). WordPress roles are simpler than Drupal's permission system.
• Profile data - Custom user profile fields in Drupal will need equivalent fields in WordPress, likely via a plugin like BuddyPress or custom user meta.

Step 6: Migrate Media Files

Drupal stores media files differently than WordPress. Depending on your Drupal version and configuration, files might live in /sites/default/files/, in a database blob, or on an external CDN.

The migration process for media:

1. Download all files from your Drupal site's files directory
2. Upload to WordPress using the media library or directly to /wp-content/uploads/
3. Update internal references - This is the tedious part. Every image embedded in content, every PDF link, every file download needs to point to the new WordPress location.
4. Verify file paths - Run a broken link checker after migration to catch any missed references

Automated migration tools handle basic image migration, but they often miss files referenced in custom fields, embedded in WYSIWYG content with absolute URLs, or stored using Drupal's file entity system. Plan for manual cleanup.

Step 7: Select WordPress Plugins to Replace Drupal Modules

This is where you rebuild your site's functionality. Every Drupal module needs a WordPress equivalent. Some are straightforward. Others require rethinking how the feature works.

Drupal Module	WordPress Plugin
Metatag	Yoast SEO or Rank Math
Webform	Gravity Forms, WPForms, or Contact Form 7
Views	Built-in queries, custom loops, or plugins like SearchWP
Pathauto	WordPress permalink settings (built-in)
CiviCRM	CiviCRM for WordPress, FluentCRM, or HubSpot
Drupal Commerce	WooCommerce
Paragraphs / Layout Builder	Gutenberg blocks, ACF Flexible Content, or page builders
Redirect	Redirection plugin

A word of caution on CRM integrations: if your Drupal site uses a CRM like CiviCRM for membership management, event registration, or donor tracking, this is the most complex piece of the migration. Most CRMs do have WordPress integrations, but the setup and configuration are different. Budget extra time for this. I have seen CRM migration alone take as long as the rest of the site combined.

Step 8: Build and Test on a Staging Environment

Never migrate directly to a live server. Set up a staging environment where you can build the new WordPress site, import content, and test everything without affecting your current Drupal site.

Run through this checklist on desktop and mobile. Click every link. Submit every form. Check every page. The time you invest in testing saves you from panicked fixes after launch.

Step 9: The Go-Live Process

When your staging site passes testing, here is the launch sequence:

1. Schedule during low-traffic hours. For most Kentucky businesses and nonprofits, that means early morning or late evening. Check your Google Analytics for your quietest window.
2. Take a final backup of your Drupal site. Database and files. Keep this backup for at least six months.
3. Freeze content changes on Drupal. No new posts or edits after this point. Any changes made on Drupal after the cutoff will not appear on WordPress.
4. Deploy WordPress to your live server. Update DNS if you are changing hosts, or swap the site files if staying on the same server.
5. Activate all 301 redirects.
6. Submit your new XML sitemap to Google Search Console. Remove the old sitemap.
7. Test everything on the live site. Run through your checklist again on the production URL.
8. Monitor for 48-72 hours. Watch for 404 errors in Google Search Console, broken links, or user-reported issues.

Realistic Timeline and Expectations

Every migration is different, but here is a general timeline based on site complexity:

• Small brochure site (10-50 pages): 4-6 weeks. Content audit through go-live. Most of the time is spent on design and testing, not content migration.
• Mid-size organizational site (50-500 pages): 6-10 weeks. Custom content types, taxonomy mapping, and redirect setup add significant time.
• Large site with CRM/ecommerce (500+ pages): 10-16 weeks. CRM migration, complex user roles, and extensive testing push the timeline out.

These timelines assume you are working with someone who has done this before. DIY migrations on complex sites tend to take 2-3x longer because of the learning curve and unexpected issues.

A few things that commonly extend timelines:

• Content that was never properly organized in Drupal (messy taxonomy, duplicate pages)
• Custom Drupal modules that need WordPress replacements built from scratch
• Stakeholder review cycles, especially for nonprofits with board approval processes
• Discovery of additional integrations during the audit phase

If you are noticing signs your site needs a redesign along with the migration, consider doing both at once. You are already rebuilding in a new CMS. It is the perfect time to rethink your design, content strategy, and user experience rather than recreating the same problems in a new system.

Common Mistakes to Avoid

After working on CMS migrations for organizations across Louisville and Kentucky, these are the mistakes I see most often:

• Skipping the redirect map. This is the number one cause of post-migration SEO drops. Every old URL needs to point somewhere.
• Migrating everything. Just because content exists in Drupal does not mean it needs to exist in WordPress. Use the migration as a chance to prune outdated content.
• Forgetting about Drupal's /node/ URLs. Even with clean path aliases, the raw node URLs are often indexed and linked to externally.
• Not testing on mobile. Your new WordPress theme might look great on desktop and break on phones. Over half your traffic is likely mobile.
• Underestimating CRM complexity. If you use a CRM like CiviCRM, give it its own dedicated migration phase. Do not treat it as an afterthought.
• Going live on a Friday. If something breaks, you want a full work week ahead of you to fix it. Launch on a Tuesday or Wednesday.

The Bottom Line

Migrating from Drupal to WordPress is a significant project, but it is a well-traveled path. Thousands of organizations have made this move successfully, and with proper planning, yours can too.

The key is preparation. A thorough content audit, a complete redirect map, and a realistic timeline will prevent most of the headaches. Do not rush it. Do not skip the testing phase. And do not be afraid to ask for help on the complex pieces.

If you are a nonprofit, church, or organization in the Louisville area facing this migration, I am happy to talk through your specific situation. Every Drupal site is different, and sometimes a 20-minute conversation can save you weeks of frustration. Call or text me at (502) 305-4043.