Make the Move from Drupal to WordPress Without Losing a Single Ranking

A Drupal to WordPress migration moves your content, users, and functionality from one CMS to another while preserving the URL structure that search engines have already indexed. Get the URLs right, and the rest of the project falls into place. Get them wrong, and you have to spend months chasing 404 errors while your organic traffic bleeds out.

Most organizations reach this decision for practical reasons. Drupal is a powerful CMS, but it demands developer involvement for tasks that WordPress handles through its admin interface. Even with the recent launch of the Drupal CMS (Starshot), which aims to make the platform more accessible to non-technical users, there still remains a significant gap in day-to-day editorial flexibility compared to WordPress.

While moving your site from Drupal to WordPress, the content transfer itself is actually the straightforward part. Plugins and scripts can move posts, pages, taxonomies, and media between databases reliably. The real risk sits in your URL structure. Search engines have spent months or years crawling and indexing your Drupal site’s URLs, building the ranking equity that drives your organic traffic. A mishandled redirect map can lead to missing taxonomy archives, broken image paths in sites/default/files, and pagination URLs that return 404s, and can trigger ranking losses that take months to recover from.

This guide walks through the full migration process, from initial site audit to post-launch monitoring.

Steps to migrate from Drupal to WordPress

A Drupal to WordPress migration follows seven phases: audit, backup, content mapping, staging setup, content transfer, SEO preservation, and post-launch validation. Each phase builds on the one before it, so skipping ahead usually means backtracking later.

1. Run a full site audit

Before you move anything, you need a complete snapshot of your existing Drupal site, including every URL, every page title, every meta description, and every status code. This SEO site audit becomes your SEO baseline, the document you’ll compare against once the WordPress version goes live.

Open a crawling tool like Screaming Frog or Sitebulb, enter your site’s URL (for example, https://example.com), and let it crawl the entire site. Depending on your site’s size, this could take anywhere from a few minutes to a couple of hours. When it finishes, export the full results as a spreadsheet.

This export should capture:

• Every URL the crawler found, including paginated pages, taxonomy term archives, and author pages.
• The HTTP status code for each URL (200, 301, 404, etc.).
• Page titles and meta descriptions.
• Internal linking structure that describes which pages link to which.
• Any existing redirects that are already in place.

Hold onto this file. It serves two purposes. First, after the migration, you’ll re-crawl the new WordPress site and compare the two exports side by side. You’re checking that the same important pages still exist, still carry their titles and descriptions, and aren’t returning 404 errors. Second, if organic traffic shifts after launch, this baseline helps you pinpoint whether the migration caused the change or whether something else is responsible. Without it, you’re left guessing.

One detail that’s easy to overlook: make sure the crawl includes image URLs and files hosted under paths like sites/default/files/. These paths will change after migration, and you’ll need the original list when building your redirect map in a later step.

2. Create a full backup of your Drupal site

A Drupal backup requires exporting both the database and the file system. Your content, users, menus, and site configuration all live in the database. Your uploaded images, PDFs, documents, and other media are in the filesystem. You need both pieces, or your backup will be incomplete.

Back up the database

The most common method is Drush, Drupal’s command-line tool. If you have terminal access to your server, navigate to the Drupal root directory and run:

drush sql:dump > backup.sql

This creates a .sql file containing every database table, including all your nodes, fields, taxonomy terms, user accounts, menu structures, and configuration. If you don’t have command-line access, you can export the database through your hosting control panel.

Back up the files

Copy the entire sites/default/files/ directory. This folder holds everything your content references: images embedded in articles, downloadable PDFs, uploaded documents, and any other media. If your Drupal site uses additional public file directories, retrieve those as well.

You can download this directory through SFTP using a client like FileZilla, through your hosting provider’s file manager, or from the command line with tools like rsync or scp. The method depends on your hosting setup, but the goal is the same – to obtain a complete local copy of every uploaded file.

Store both backups off the server

Move them to cloud storage, an external drive, or your local machine. If something goes wrong mid-migration, the database to restore your content and configuration, and the files directory to restore every image and document are your full rollback option.

3. Map your Drupal content structure to WordPress

Content mapping documents how every Drupal content type, field, taxonomy, and URL pattern translates to its WordPress equivalent. This step prevents surprises later, as every gap you identify now is one fewer broken page after launch.

Start with your URL patterns

Drupal stores content internally as paths like /node/123, but most sites use path aliases to create cleaner URLs — something like /blog/how-to-migrate or /resources/white-paper-title. WordPress handles this through its Permalinks settings (found under Settings → Permalinks), where you define a URL structure such as /%postname%/ or /blog/%postname%/.

Your goal here is to keep URL changes to a minimum. Compare your current Drupal aliases against the permalink structure you plan to use in WordPress. Where they can match, great, because that’s one less redirect to manage. Where they’ll differ, document the change. Every URL that shifts needs a 301 redirect later, and you can’t build accurate redirects without knowing exactly what’s changing.

Pay close attention to patterns that are easy to miss:

• Taxonomy term pages (e.g., /category/design in Drupal becoming /category/design/ with a trailing slash in WordPress).
• Paginated archive pages (e.g., /blog?page=2 vs. /blog/page/2/).
• File and image paths under sites/default/files/ will move to wp-content/uploads/ in WordPress.
• Author profile URLs, which often follow completely different patterns between the two platforms.

Map your content types

List every Drupal content type your site uses, from Article, Basic Page, News, Event, Case Study, whatever your site has. For each one, decide what it becomes in WordPress:

• Posts work well for date-driven, chronological content like blog articles and news updates.
• Pages suit static content like your About page, Contact page, or service descriptions.
• Custom post types are the right fit for anything that doesn’t fall neatly into Posts or Pages – things like Events, Team Members, Testimonials, or Product listings. You’ll typically create these with a plugin like Advanced Custom Fields (ACF) or Pods.

If your Drupal site uses custom fields (through modules like Field API or Paragraphs), note which fields each content type uses and how they’ll translate. A simple text field maps directly. A Drupal entity reference field pointing to related content will need more thought. As WordPress doesn’t have a native equivalent, you’ll likely use ACF relationship fields or a similar solution.

Plan your taxonomy mapping

Drupal organizes classification through vocabularies (e.g., “Topics,” “Regions”) and terms within each vocabulary (e.g., “Marketing,” “Europe”). WordPress uses the categories and tags taxonomies and supports registering custom taxonomies.

Review each Drupal vocabulary and decide where it fits:

• A primary vocabulary used for broad grouping (like “Department” or “Content Type”) usually maps to WordPress categories, which are hierarchical.
• A secondary vocabulary used for more granular labeling (like “Topics” or “Keywords”) typically maps to WordPress tags, which are flat.
• If you have more than two vocabularies, or if a vocabulary is tied to a custom post type, you’ll want to create custom taxonomies in WordPress to keep the same organizational logic.

Write all of this down in a single document or spreadsheet. Drupal content type in one column, WordPress equivalent in the next, with notes on any fields, taxonomies, or URL changes that need special handling. This becomes the reference your migration tool or developer will work from.

4. Set up a staging environment

A staging environment is a private copy of your WordPress site where you run the entire migration before touching your live domain. Every import, every test, every fix happens here first.

Never migrate directly onto a production server. If an import goes sideways due to corrupted data, missing images, or a plugin conflict, you want that to happen on a site nobody else can see. Your live Drupal site remains untouched and fully operational all this time.

You have a few options for where to set this up:

• A staging subdomain on your host. Many managed WordPress hosts (like Kinsta or WP Engine) offer one-click staging environments. You can also create one manually at something like staging.example.com. This is a good choice because the server environment closely matches your future production setup.
• A local development environment. Tools like LocalWP, DevKinsta, or Docker let you run WordPress on your own computer. This works well for experimentation, though you’ll need to account for server differences when you eventually move to your host.

Once the staging site is ready, install a clean copy of the current WordPress version (6.9 at the time of writing). Keep the installation lean by adding only the theme you intend to use and the plugins you’ve specifically chosen for the migration and your final site setup. Loading random plugins or themes introduces variables that complicate debugging if anything breaks during import.

Content imports, redirect testing, layout checks, and plugin configuration all happen on the staging site. Only once you’ve thoroughly tested the result and confirmed that content, URLs, media, and functionality all look correct, do you point your live domain to the new WordPress installation.

5. Choose your migration method

There are two primary approaches for site migration: plugin-based import and manual migration via database queries and scripts. Most real-world projects end up using a hybrid approach, running a plugin to handle bulk transfers and then manually cleaning custom fields, SEO metadata, or edge cases afterwards.

Here’s how each method works.

Method 1: Plugin-based migration

The FG Drupal to WordPress plugin is the most widely used tool for this job. The free version handles standard content types, categories, tags, and media. The Premium version adds user migration, Drupal password hash handling, custom post type support, menu import, comment migration, and automatic 301-redirect creation. For most sites, the Premium version plus relevant add-ons is worth the investment.

On your staging WordPress site:

1. Install and activate the plugin. Search for “FG Drupal to WordPress” under Plugins → Add New, install it, and activate. If you’ve purchased Premium or add-ons, upload those through the same screen.
   
2. Connect to your Drupal database. Navigate to Tools → Import → Drupal. The plugin will ask for your Drupal database connection details: hostname, database name, username, password, and table prefix. You can find these values in your Drupal site’s sites/default/settings.php file, inside the $databases array. Enter the credentials and let the plugin test the connection to confirm it can read the Drupal data.
   
3. Configure your import settings. This is where your content mapping document from Step 3 pays off. You’ll specify which Drupal content types should import as WordPress Posts, which as Pages, and which as custom post types. Choose whether to bring in media files, how to map Drupal vocabularies to WordPress categories or tags, and whether to import user accounts. If you’re using Premium, you can also enable password migration so users don’t get forced into a password reset on day one.
   
4. Run the import and verify the results. Once the import finishes, check the numbers first. Do the post and page counts match what you expected from your audit? Then spot-check individual pages. Open a handful of articles and confirm that body content came through cleanly, images display correctly, featured images are assigned, and taxonomy terms are attached to the right posts. Pay attention to any content that used Drupal-specific formatting or embedded media, as these are the areas most likely to need manual cleanup.
   

A few things FG Drupal to WordPress does not do, even with Premium: it won’t recreate Drupal Views logic (those filtered, sorted content listings), it won’t migrate complex Paragraphs or Field Collection layouts into structured WordPress equivalents, and it won’t catch internal links that use absolute paths pointing to files under sites/default/files/. These gaps are normal; they’re where manual work or specialist help can be used.

Method 2: Manual migration

If your Drupal site is heavily customized or you need fine-grained control over exactly how data maps to WordPress, manual migration gives you that precision. It’s also significantly more technical and time-consuming, so this path is best suited for developers comfortable with SQL, PHP, and command-line tools.

At a high level, the process involves:

1. Export content from the Drupal database. Write SQL queries to pull data from core tables like node_field_data (for node titles, types, and timestamps), node__body (for body content), and path_alias (for clean URLs). Export taxonomy data from the relevant vocabulary and term tables.
   
2. Export media files and metadata. Copy the entire sites/default/files/ directory to your local machine or staging server. Then export metadata from the file_managed table so you have a record of every file’s original path, filename, and MIME type.
   
3. Import content into WordPress. Write scripts or use WP-CLI commands like wp post create to insert posts and pages into the WordPress database. A useful practice here: store each post’s original Drupal node ID in a custom field (e.g., _drupal_nid). You’ll reference this later when building your redirect map from old URLs to new ones.
   
4. Create and assign taxonomies. Use functions like wp_insert_term to create your categories and tags, then attach them to the correct posts using wp_set_post_terms. Your content mapping document tells you which Drupal vocabulary maps to which WordPress taxonomy.
   
5. Migrate media files. Move the downloaded files into wp-content/uploads/, organizing them into WordPress’s year/month folder structure if you prefer. Run a search-and-replace across the database to update old file paths (e.g., sites/default/files/image.jpg) to new WordPress paths (e.g., wp-content/uploads/2026/03/image.jpg). Then register the files in the WordPress media library using wp media import via WP-CLI or a plugin.
   
6. Fix internal links. Run a final search-and-replace across post content to catch any internal links still pointing to old Drupal URL patterns. Tools like Better Search Replace, or WP-CLI’s wp search-replace command work well for this.

In practice, most migrations land somewhere in between. You run the FG plugin to handle bulk content, media, and taxonomy transfers – the work it does well and quickly. Then you manually address the gaps: cleaning up custom field data that didn’t map correctly, importing SEO metadata from Drupal’s Metatag module into your WordPress SEO plugin, fixing media paths the plugin missed, or writing scripts for any content relationships that need custom handling. This hybrid approach gives you speed where automation works and precision where it doesn’t.

6. Preserve SEO

301 redirects permanently point old Drupal URLs to new WordPress URLs, preserving link equity and search rankings. This step, combined with permalink configuration and metadata migration, is what separates a migration that holds its traffic from one that tanks it.

Configure permalinks to match your Drupal URL patterns

In your WordPress staging site, go toSettings → Permalinks and choose a structure that mirrors your existing Drupal aliases as closely as possible. If your Drupal articles lived at /blog/post-title, set your WordPress permalink structure to /blog/%postname%/. If they sat at the root like /post-title, use /%postname%/.

The closer your new URLs match the old ones, the fewer redirects you’ll need to manage. Every redirect you can avoid is one less point of failure and one less millisecond of latency for both users and search engine crawlers.

Set up 301 redirects for every URL that changes

Despite your best efforts with permalinks, some URLs will inevitably change. Taxonomy term pages, author archives, paginated URLs, and media file paths almost always end up with different patterns in WordPress. Every one of these needs a 301 redirect from its old Drupal path to its new WordPress destination.

You have a few options for managing redirects:

• Plugin-based redirects. Tools like Redirection or Rank Math let you add redirect rules through the WordPress admin. This is the simplest approach for small-to-medium sites with a few hundred redirects.
• Server-level redirects. For very large sites (thousands of redirects) or better performance, add redirect rules directly in your .htaccess file (Apache) or Nginx configuration. Server-level redirects execute before WordPress even loads, which makes them faster and less resource-intensive.

Cross-reference your list of original Drupal URLs against the new WordPress URLs and build your redirect rules from the differences. Don’t forget the paths that are easy to overlook: image and file URLs that moved from sites/default/files/ to wp-content/uploads/, taxonomy archives that gained or lost a trailing slash, and any pagination patterns that changed format.

Migrate SEO metadata

Titles and meta descriptions from Drupal’s Metatag module need to move into the corresponding fields in your WordPress SEO plugin, whether that’s Yoast SEO, Rank Math, or another option. If you used the FG Drupal to WordPress Premium plugin with its SEO add-on, some of this may have transferred automatically. 

Either way, spot-check a sample of your highest-traffic pages to confirm the metadata came through accurately. Missing or duplicated meta descriptions across dozens of pages will show up as issues in Google Search Console and can dilute your click-through rates.

Submit a fresh XML sitemap

Generate a new XML sitemap through your SEO plugin. Most WordPress SEO plugins create and maintain this automatically once activated. Then submit it to both Google Search Console and Bing Webmaster Tools. This tells search engines to crawl your new URL structure right away rather than waiting to discover it organically, which speeds up reindexing.

Rebuild structured data

If your Drupal site used structured data or JSON-LD markup for things like articles, FAQs, breadcrumbs, or organization info, rebuild equivalent schema on the WordPress side. Most SEO plugins include built-in schema generators, or you can use a dedicated tool like Schema Pro. Without this step, any rich results you were earning in search (star ratings, FAQ dropdowns, breadcrumb trails) will disappear after migration.

7. Post-migration monitoring and validation

Post-migration validation compares your new WordPress site against the pre-migration baseline to catch broken URLs, missing metadata, and ranking drops before they compound into larger problems.

Re-crawl and compare

Once the new WordPress site is live on your production domain, run a fresh crawl with the same tool you used in Step 1. Export the results and place them side by side with your original Drupal crawl data.

You’re looking for three things:

• Key pages still exist. Every high-traffic and high-authority page from your Drupal site should have a working equivalent on the WordPress site, either at the same URL or properly redirected to a new one.
• Redirects resolve correctly. Old Drupal URLs should return 301 status codes pointing to the right WordPress destinations. Watch for redirect chains (a 301 that points to another 301) and redirect loops, as both waste crawl budget and dilute link equity.
• No large clusters of 404 errors. A few stray 404s are normal. A batch of 50 or 100 indicates that something systematic was missed, often in taxonomy archives, paginated pages, or media file paths.

Monitor Google Search Console

Over the first four weeks after launch, check Google Search Console regularly for:

• Crawl errors: New 404s, server errors, or redirect issues that Google’s crawler has flagged.
• Indexing drops: Pages that were previously indexed but have fallen out of Google’s index.
• Impression changes: Sudden dips in impressions for your most important pages or queries. A gradual shift is expected as Google recrawls and reprocesses your site. A sharp, immediate drop usually points to a redirect or indexing problem that needs attention.

Track organic traffic for 60 to 90 days

Open your analytics tool and keep an eye on organic sessions, landing page performance, and keyword rankings over the first two to three months. Some short-term fluctuation is normal as Google needs time to recrawl URLs, process redirects, and update its index. What you want to see is overall visibility stabilizing within the first few weeks and your top-performing content holding its positions.

If you spot problems during this window, fix them promptly. Adjust redirects, fill in missing titles and meta descriptions, or correct broken internal links. The faster you address these issues, the less lasting impact they’ll have on your organic performance.

When to bring in expert help

The steps above will carry a standard Drupal blog or news site through to a successful WordPress launch. But certain site characteristics push a migration past the point where plugins and careful planning are enough on their own. If your Drupal site checks any of these boxes, bringing in a specialist is likely the smarter investment:

• Your site uses Paragraphs or Field Collections extensively. These nested, component-based content structures don’t map to WordPress’s flat post table without custom transformation logic.
• Content volume exceeds 10,000 nodes, or your media library runs into multiple gigabytes. Browser-based imports will time out at this scale, and partial imports create messy cleanup work.
• You’re running a multilingual architecture with translation relationships that need to preserve hreflang tags across the migration.
• You have an active user database where forcing password resets would generate support tickets and churn. Drupal and WordPress hash passwords differently, so accounts can’t simply be copied over without a tool or bridge designed for hash migration.
• The site includes e-commerce functionality, such as product catalogs, order histories, customer accounts, and payment or subscription continuity, which add significant complexity.
• You rely on membership tiers or editorial permission structures that go beyond WordPress’s default user roles.
• You’re migrating from Drupal 7, which uses an older database schema that current plugins handle less reliably than Drupal 8, 9, 10, or 11.

An experienced migration developer handles what plugins can’t. That includes building custom Gutenberg blocks that mirror Paragraph layouts, writing WP-CLI and shell scripts that bypass browser-based import limitations, mapping Drupal entity references through custom SQL and wp_postmeta manipulation, creating authentication bridges so users can log in with their existing passwords without a forced reset, and configuring WooCommerce with payment gateway setup and order history migration for e-commerce sites.

Your migration roadmap starts here

The principle that holds this entire process together: treat URL continuity as the spine of your migration, and the content transfer becomes mechanical. Map every Drupal URL to its WordPress destination and set your redirects.

If your site is straightforward with standard content types and moderate volume, start with the content mapping step and work through this guide step by step. The tools and process outlined here will get you to a clean WordPress launch with your rankings intact.

For e-commerce migrations or more complex sites, Codeable offers fixed-price WooCommerce migration packages starting at $2,000 for basic stores, $4,000+ for established stores with larger catalogs, and custom quoting for enterprise operations. Each package includes a free migration assessment, so you understand the full scope and cost before committing a dollar.

For non-e-commerce sites where you’re unsure whether your Drupal setup is too complex for a DIY approach, Codeable handles those too. A 1-hour consultation starting at $69 lets you walk through your specific site architecture with an experienced WordPress developer who can flag risks, estimate effort, and recommend the right approach for your situation.

Either way, you don’t pay for development work until you’ve seen the scope and agreed to the price.

Get your free migration assessment from Codeable and find out exactly what your Drupal to WordPress migration will take, before you touch a single file.

20 000+ businesses of every shape and size have already trusted us to hire WordPress developers and scale their growth.

Find a developer expert