Drupal to WordPress Migration: What Actually Transfers (2026 Guide)

Drupal 7 reached end of life on January 5, 2025. No more security patches. No more community support. No more updates.

If your organization is still running Drupal 7, you're operating on a platform with known security vulnerabilities that will never be fixed.

Extended security support from third-party vendors like HeroDevs or Tag1 exists, but it's an expensive stopgap, not a long-term strategy. You're paying premium prices to keep an aging platform alive, even as your options narrow.

The path forward isn't obvious, and that's the problem. Upgrading to Drupal 10 or 11 is essentially a rebuild. The architecture changed so fundamentally between Drupal 7 and Drupal 8 that there's no smooth upgrade path.

If you're going to invest in a rebuild anyway, the question becomes: rebuild on Drupal, or migrate Drupal to WordPress?

A Drupal to WordPress migration is not an export. That is the single most expensive misunderstanding in this whole process, and it is the one almost every organization arrives with. This guide covers what actually transfers content type by content type, where the migration plugins stop being useful, how to protect the search rankings you already have, and what to test in the weeks after launch.

For most of the organizations we work with, the answer is WordPress. A Drupal to WordPress migration is a conversation we've been having for over a decade.

"Around 10 years ago, maybe even 12 years ago, migrations from Drupal to WordPress were very common. WordPress was starting to win over businesses and associations and proving itself as more than just a blogging platform."

That shift has only accelerated. WordPress now powers 43% of all websites. The plugin ecosystem, talent pool, and long-term cost of ownership all favor WordPress for organizations without dedicated Drupal development teams.

Where This Philosophy Was Forged

Drupal migrations hold a special place in our history. This is where we learned that the "migration" mindset itself is the problem.

Early on, we tried the logical approach. Drupal has modules that promise to export content. There are tools designed to bridge the gap between Drupal and WordPress. On paper, it should work.

In practice, it was a disaster. Every time.

"If anyone comes to me with a Drupal migration, I know it's going to be tough. A lot of times, I'm not even going to want administrator access to that site."

That's not an exaggeration. Drupal's administrative interface, its content structures, and its module configurations create a false sense of possibility. You see the data. You see export options. You think there's a path from here to WordPress.

But the way Drupal organizes content is fundamentally different from WordPress. The export tools either produce unusable output or export content in formats that require more cleanup than starting from scratch.

"Drupal modules promise export functionality. It's going to be a disaster."

"That's probably where I learned almost to ignore the administrative side of things and not look for some kind of export solution. And really try and get this down to a manageable, manual-level practice."

That lesson applies to every migration we do now, across every platform. But it was Drupal that taught it to us.

Why a Drupal to WordPress Migration Is Harder Than It Looks

People underestimate the difficulty of a Drupal-to-WordPress migration because both platforms are open-source content management systems. How different can they be?

Very different.

Content Architecture Mismatch

Drupal's content model is built around Content Types, Fields, Taxonomy Vocabularies, and Entity References. WordPress has Post Types, Custom Fields, Taxonomies, and post relationships. The concepts sound similar. The implementations are not.

The biggest gap is Views. Drupal's Views module is how most Drupal sites generate listings, archives, filtered content displays, and dynamic page sections. WordPress has no direct equivalent.

Every View needs to be recreated using WP_Query, custom templates, or plugins. Each one needs to be evaluated individually.

"The way content is organized is just a very different system than WordPress."

The URL Structure Problem

Drupal's default URL pattern is /node/123. Most Drupal sites use Pathauto to generate clean URLs, but the underlying structure and URL management differ from WordPress's permalink system.

This matters enormously for SEO. Every URL on your Drupal site that has accumulated search authority needs to redirect to its WordPress equivalent.

If your Drupal site has been running for years with clean URLs, the redirect mapping is manageable. If it's a mix of /node/ URLs and Pathauto-generated paths, the mapping gets complicated.

A single 301 redirect passes approximately 85% of link equity. Chain two redirects together, and the loss compounds. Getting the redirect map right the first time is critical.

The Module-to-Plugin Gap

Drupal modules and WordPress plugins serve the same purpose, but their ecosystems differ. A Drupal site using Webform, Rules, Entity Registration, and Commerce has no WordPress equivalents that match those modules feature-for-feature.

Each module needs to be evaluated: What does it do? Is there a WordPress plugin that handles the same functionality? Does it need custom development? Can the feature be retired during the migration?

This evaluation takes time. It's tempting to skip it and assume you'll figure it out during the build. That's how projects blow their budgets.

What Actually Transfers, Content Type by Content Type

"Can you migrate my content?" is the wrong question, because Drupal does not store one thing called content. It stores a dozen different things, and each one moves differently. Here is the honest accounting.

The pattern is consistent. Anything that is stored text moves. Anything that is displayed structure gets rebuilt.

That is why an export-based migration produces a site that technically contains your content and looks nothing like your website. The content was never the hard part.

"The way content is organized is just a very different system than WordPress."

Read that table as a budgeting tool. Count how many rows apply to you, and pay particular attention to the ones marked "not at all." Those are the line items that turn a three-week migration into a nine-week one.

The FG Drupal to WordPress Plugin (and Its Limits)

The FG Drupal to WordPress plugin is available on WordPress.org and supports migrations from Drupal 4 through 10. It's the go-to DIY tool that covers the basics: content, categories, tags, and images.

For a simple Drupal site with blog posts, basic pages, and standard taxonomy, FG Drupal to WordPress can get content into WordPress in a usable format. It's a legitimate starting point.

For complex sites, it's not enough. Custom Content Types with dozens of Fields, Entity References, Views-based listings, and module-specific data don't transfer.

The plugin handles the CMS content. It doesn't handle the CMS architecture.

If your Drupal site is small and simple enough for a plugin-based migration, it might also be small enough that manual copy-paste is faster and produces a cleaner result.

"Nothing's going to have the quality of a hand-done job of copy-paste and reformatting for SEO and ensuring that every attachment is in place."

For enterprise Drupal sites, custom migration scripts are typically required. These scripts export Drupal's database content into structured formats that can be imported into WordPress using WP All Import or similar tools.

Writing those scripts requires someone who understands both Drupal's database schema and WordPress's content model.

The Drupal to WordPress Migration Process

Phase 1: Discovery

"The only question I'm asking a client up front is: 'What does your website do?'"

For Drupal sites, the answer to this question is often more complicated than the client realizes. Drupal's flexibility means organizations have built all kinds of custom functionality over the years.

Event calendars tied to registration systems. Member directories pulling from external databases. Content workflows with approval chains. Custom Views that power entire sections of the site.

We follow the discovery with the question that always reveals something:

"Now, do you have any surprises for me? ... This is the time to tell me that deep inside your website, someone decided that selling T-shirts was a good idea."

Then we crawl the site with Screaming Frog, run a site:domain.com Google search to understand the indexed footprint, and manually click through every section.

The result is a complete inventory: unique page templates, custom functionality, content volume, and URL structure.

Phase 2: Content Mapping and Archiving

Before moving a single piece of content, we map every Drupal Content Type to its WordPress equivalent. Custom Post Types are created. ACF fields are configured. Taxonomies are set up.

For sites with thousands of pages, particularly organizations with years of blog posts, news articles, or event archives, we have the archiving conversation first.

"If we get into the thousands of pages, first, we're going to talk about archiving because this might be a great opportunity to clean things up."

Outdated content, poorly written by modern standards, or generating no search traffic doesn't need to make the journey to WordPress.

Setting a content age cutoff (for example, anything older than five or seven years) dramatically reduces the migration scope without sacrificing anything of value.

For the National Peace Corps Association's migration, we set a seven-year archiving cutoff. Content older than that was not migrated. We communicated this to all stakeholders, and there were no complaints.

Phase 3: Custom WordPress Theme Build

"We are going to build a custom theme just for you."

The existing Drupal site is the design specification. We build a WordPress theme that is a pixel-perfect recreation of the current design. Same layout, same fonts, same colors, same branding. No designer involved. No design comps.

"Their current website is the design scope."

This discipline is important. Design is subjective and opinionated. A migration should not be subjective. If we're creating a copy, the measure of success is whether the new site looks and works like the old one.

If the organization wants design changes, those happen in a separate phase after the migration is stable.

Phase 4: Content Migration

For content exported from Drupal into structured formats, WP All Import handles bulk transfers. But every piece of imported content needs manual review.

We're copying content page by page, verifying that images transfer correctly, that internal links point to the correct WordPress URLs, that formatting is intact, and that no attachments are missed.

Under a thousand pages, this manual process is absolutely within reason. It's also where we do our best SEO work.

"We're going to put eyes on every page and think about its technical SEO structure."

Heading hierarchies that jump from H1 to H4 get corrected. Images get proper alt text. Metadata gets configured in Yoast SEO. The manual migration process is an SEO cleanup disguised as content transfer.

Phase 5: SEO Preservation

This is where DIY Drupal WordPress migration attempts fail, and the statistics are harsh. Fifty percent traffic loss is common in poorly executed migrations. The average recovery from a botched migration is 523 days.

Only 10% of migrations actually improve SEO.

"A migration, though it is a disruption, should only improve SEO."

Redirect mapping starts before the build. We crawl the entire Drupal site with Screaming Frog, document every URL, and create a complete mapping to WordPress equivalents. Before the new site goes live, every 301 redirect is configured through either the Redirection plugin or server-level .htaccess rules.

The expected dip. Even with perfect redirects, Google sees the structural change and re-evaluates the site. Rankings will fluctuate for a few weeks. This is normal, and we communicate it clearly to every stakeholder.

"Even though you've already set all your 301s and you've ensured everything is mapped appropriately and optimized, Google does see the structure change. It sees the markup. And that little shift is going to force Google to re-evaluate it."

We advise compensating for marketing activities in the first weeks after launch, including increased social media presence, email campaigns, and other channels, to offset the temporary softness in organic traffic. For a step-by-step guide to the full process, see our WordPress migration checklist.

Timeline and Cost

The time it takes to migrate Drupal to WordPress varies with site complexity:

• Small Drupal sites (under 50 pages, minimal custom functionality): 1-2 weeks
• Medium Drupal sites (50-500 pages, some custom Content Types and Views): 3-5 weeks
• Enterprise Drupal sites (500+ pages, complex Content Types, custom modules, integrations): 6-10 weeks

Professional costs range from $2,000 to $20,000.

The primary drivers are content volume, the number of custom Content Types and Views that need recreation, custom module functionality that requires WordPress plugin equivalents or custom development, and the complexity of URL redirects.

Extended security support from third-party vendors costs thousands per year and doesn't solve the underlying problem. At some point, the cost of maintaining Drupal 7 exceeds the cost of migrating.

For most organizations, that point has already passed.

The Drupal 10 Alternative

We should address this directly: Drupal 10 and 11 exist. They're modern, well-built platforms with active development communities.

Upgrading from Drupal 7 to Drupal 10 is a viable option if your organization has Drupal development expertise, your team is committed to the Drupal ecosystem, and the features you rely on are available in modern Drupal.

But here's what many organizations don't realize: the upgrade from Drupal 7 to Drupal 10 is essentially a rebuild. The underlying architecture changed so fundamentally between Drupal 7 and Drupal 8 that there's no automated upgrade path for custom themes, most contributed modules, or custom code.

You're rebuilding your site either way.

If you're going to invest in a rebuild, the question is whether you want to rebuild on a platform with a smaller ecosystem, a smaller talent pool, and higher development costs. Or whether you want to rebuild on the platform that powers 43% of the web.

For organizations with dedicated Drupal development teams and significant investment in the Drupal ecosystem, staying on Drupal may make sense. For everyone else, particularly associations and organizations without in-house development resources, WordPress is the practical choice. Organizations on other enterprise CMS platforms face similar rebuild-or-migrate decisions. Our guides on Sitecore to WordPress and Umbraco to WordPress cover the platform-specific considerations for those transitions.

When Not to Migrate

We'll tell organizations not to migrate when it doesn't make sense.

"If you have a brochureware site and you don't want to become a weekend warrior of web development in WordPress, then for $35 to $100 a month for various Squarespace plans, just do it."

If your Drupal site is small and simple and you don't need the flexibility of WordPress, a hosted platform like Squarespace or Wix may be a better fit. Less overhead, less responsibility, lower cost.

But if your Drupal site has custom Content Types, member portals, API integrations, event management, or more than a handful of pages, WordPress is where you should be heading. The ecosystem supports it, the talent pool is there, and the total cost of ownership over five years is lower.

"You can find cheaper developers than us. We are doing this at a professional enterprise scale."

If your website is critical to your organization's operations, member communication, or revenue, the cheapest migration option is rarely the best one.

We've seen too many organizations attempt a budget migration and spend the next 18 months recovering from the SEO damage.

After the Drupal WordPress Migration: What Happens Post-Launch

This is the part every migration guide skips. And based on our experience, it's the part that matters most.

"Once the flip is switched and the new WordPress site is live, that's when we as a support and maintenance company thrive."

Post-Migration Testing: The First 72 Hours

Post-migration testing is not a final sign-off checklist you run once and file away. The problems that matter surface when real people use the site, and they surface in a predictable order.

Immediately after the DNS switch:

• Spot-check redirects from the live site, not from a spreadsheet. Pull your top 50 URLs by traffic and confirm each one lands on a 200, not a 404 and not a chain of two hops.
• Submit the new XML sitemap in Google Search Console and confirm the property is reading it.
• Confirm forms actually deliver. Submit every form on the site and check that the notification email arrives, because form delivery breaks silently and nobody reports it for weeks.
• Verify analytics and any conversion tracking are firing on the new templates.

In the first week:

• Re-crawl the whole site with Screaming Frog and diff it against your pre-migration crawl. Missing pages, broken internal links, and orphaned images all fall out of that comparison.
• Watch Search Console's Coverage report for a spike in crawl errors. A handful is normal. A pattern is a redirect map problem.
• Check that images and PDF attachments resolve. Attachments are the most commonly missed item in any migration, and they rarely appear in automated tests.

In the first month:

• Track rankings for your top terms and expect fluctuation. Compare against the pre-launch baseline you captured, not against last week.
• Collect the internal complaints. Staff will find the pages that did not transfer correctly faster than any crawler will.

The organizations that skip this phase are usually the ones who discover in month four that a section of the site has been returning 404s since launch.

The Overlap Period

We ask clients to keep their old Drupal hosting active for one to two weeks after launch. That old site becomes an archive we can reference when someone discovers a page that didn't transfer correctly, a PDF that was missed, or a feature that works differently than expected.

Launch day is when the full organization, not just the project team, sees the new site for the first time. Issues always surface.

The Administrative Adjustment

Coming from Drupal to WordPress is a significant change in how content is managed.

"The number one complaint is often they don't like how complex the administration is. So obviously we're going to try and smooth that out for them."

WordPress's administrative experience is simpler than Drupal's. Most organizations see this as a major improvement. But "simpler" doesn't mean "identical," and staff need time to learn the new workflows.

"We like to let that just sit and chill for a few weeks before we start making any major changes."

Ongoing Care

A migration agency finishes the project and moves on to the next one. If something breaks in month three, you're opening a new project.

We're still there. Hosting the site. Applying updates. Monitoring security. Supporting the team as they settle into WordPress.

The migration is where our relationship with an organization begins. Everything we build during the migration is designed for long-term maintainability, because we'll be the ones maintaining it.

That alignment of incentives produces a better migration and a healthier website.

Choosing a Drupal to WordPress Migration Company

Most organizations doing this have never done it before, and will never do it again. That makes evaluating a Drupal to WordPress migration company genuinely hard, because you're being asked to judge work you have no reference point for.

These are the questions that separate the firms who have done this from the ones who are about to learn on your site.

"How will you handle our Views?" If the answer is vague, or if the question seems to surprise them, stop. Views is the single largest rebuild item on most Drupal sites. A migration company that has not asked about your Views has not scoped your project.

"What is your redirect strategy, and when do you build the map?" The right answer is that redirect mapping starts before the build, from a full crawl, not after launch from memory. If redirects are treated as a launch-week task, your rankings are the thing being gambled.

"What are you not migrating?" A good answer here is a sign of experience. Every migration should have an explicit archiving conversation and a defined content cutoff. A firm that promises to move everything either has not looked closely or is planning to bill you for moving content nobody has read since 2016.

"Who owns the site in month three?" Migration-only shops finish the project and move on. If something breaks after handoff, you are opening a new engagement with someone who has already reassigned your team.

That last one is the difference in how we work. A migration is where our relationship with an organization starts, not where it ends. We host the site, apply the updates, monitor security, and support your staff while they settle into WordPress, which means everything we build during the migration is built for someone who has to maintain it later. That someone is us.

We've handled Drupal migrations for associations, nonprofits, and member organizations for over a decade, including multi-site networks like the National Peace Corps Association. If you want to talk through what your own Drupal site would actually involve, get in touch and we'll walk it with you.

The Clock Is Running

Drupal 7 end-of-life isn't a future event. It happened over a year ago. Every month that passes increases the security risk, narrows the available support options, and makes the eventual migration more urgent.

A migration is a multi-week project that requires planning and budgeting. It's not something you can decide to do after a security incident forces your hand and execute quickly.

The organizations that planned ahead are already on WordPress. The organizations that waited are now making this decision under pressure.

"This is your chance to make sure that your website is built well. Because you want this investment to last for quite a while."

If your organization is still on Drupal 7, or if you're on a newer Drupal version and questioning whether the ecosystem still serves your needs, the Drupal to WordPress conversation is one worth having sooner rather than later. Our WordPress migration services overview covers how we approach transitions from any platform, and our WordPress development team handles these projects every week.

Frequently Asked Questions

Is there a plugin to migrate Drupal to WordPress?

Yes. The FG Drupal to WordPress plugin supports Drupal 4 through 10 and handles the basics: posts, pages, categories, tags, and images. For a straightforward Drupal site made mostly of articles and basic pages, it is a legitimate starting point. It does not handle custom Content Types with many Fields, Entity References, Views-based listings, or module-specific data, which is precisely what makes enterprise Drupal sites complicated. The plugin migrates content. It does not migrate architecture.

Can a Drupal to WordPress migration be fully automated?

No, and treating it as an automation problem is the most common way these projects go wrong. Roughly half of what a Drupal site does lives in Views, Panels, and module configuration, none of which have an automated path into WordPress. Automated tools can move stored text. Everything that controls how that text is displayed gets rebuilt by hand.

Does Drupal taxonomy transfer to WordPress?

Vocabularies and terms map reasonably well onto WordPress categories and tags, and this is one of the cleaner parts of a migration. The two things to watch are deep hierarchies, which tend to flatten unless they are rebuilt deliberately, and term-to-content relationships on custom content types, which usually need to be re-established through ACF rather than transferring on their own.

How long does a Drupal to WordPress migration take?

Small sites under 50 pages with minimal custom functionality take one to two weeks. Medium sites of 50 to 500 pages with some custom Content Types and Views take three to five weeks. Enterprise sites of 500 pages or more with complex Content Types, custom modules, and integrations take six to ten weeks. Content volume matters less than the number of Views and custom Content Types that need recreation.

Will migrating from Drupal to WordPress hurt my SEO?

It should not, but it frequently does when handled poorly. Fifty percent traffic loss is common in badly executed migrations, and average recovery takes 523 days. The determining factor is redirect mapping: every URL that has accumulated search authority needs a single 301 to its WordPress equivalent, mapped from a full crawl before the build starts rather than reconstructed after launch. Expect a few weeks of ranking fluctuation even when everything is done correctly, because Google re-evaluates the site when it sees the structural change.

Should I upgrade to Drupal 10 instead of migrating to WordPress?

It is a reasonable option if your organization has in-house Drupal expertise and is committed to the ecosystem. Understand that it is not really an upgrade. The architecture changed so fundamentally between Drupal 7 and Drupal 8 that custom themes, most contributed modules, and custom code have no automated path forward. You are rebuilding either way, so the real question is which platform you want to rebuild on.

What does a migration company do that a plugin cannot?

The work a plugin cannot touch is the majority of the project: recreating every View as a custom query or template, rebuilding Panels and Layout Builder pages, evaluating each Drupal module for a WordPress equivalent or custom development, building a complete redirect map from a full site crawl, and reviewing every migrated page for formatting, images, attachments, and internal links. A plugin gets content into the database. It does not produce a working website.