Drupal to WordPress Migration: 2026 Playbook

You will not find a Drupal to WordPress migration that is simply a matter of moving data from one place to another. It is a translation of content models, and the two do not align. Where you have entities, bundles, fields, Paragraphs and revisions in Drupal, WordPress has its own way of doing things with posts, pages, taxonomies and key-value meta. In any serious undertaking, some of that is going to be lost in translation; the only thing worth asking is if you meant for it to be or if it was an accident.

That is the difference between a project that ships on schedule and one that will quietly run you twice the price over the next twelve months. The import script will do its job and put the content where it should be. But then your editors will start to see the problems: old article relationships are missing, internal links are dead ends, multilingual pieces have been separated from their source and organic traffic is down for no apparent reason. We have written this guide for the agency leads, content operators and technical types who are about to make that call. We want to tell you what to plan for, what to give up by design and where you must not cut corners.

Decide What You Are Actually Migrating

The first thing to decide is not a technical one. You have to determine if the new WordPress site is to be a replacement for the Drupal one or a reproduction of it. Most projects are better off with the former, even if they are loath to say so. A Drupal model is often the product of ten years of choices: taxonomies kept out of habit, fields from long-forgotten campaigns, and the like. To clone that into WordPress is to build a more brittle and slower version of a system you were already done with.

If you look at the post-mortems from agencies or the documentation for enterprise migrations, you will find a consensus: redesign the content model as you go. Drupal can handle more complicated relationships than WordPress, and trying to shoehorn them into post types and ACF usually means you end up with plugin sprawl and the same old maintenance headaches. Toolset has a guide for Drupal developers that makes the point in its own way – anything but a marketing site requires you to map things with intent.

So before you write code, the project lead ought to be able to answer four questions without much jargon:

• What content types are being retired and which have earned their keep?
• Are we making a conscious choice to let go of revisions, fine-grained permissions or multilingual variants?
• Who owns the editorial workflow on day one and how does it work?
• How do we define success ninety days in when it comes to traffic and editor buy-in?

Vague answers mean you are not ready. Deciding on the platform is easy. Governance is the hard part: you need a product owner with the power to say no to scope creep and a small team to back him or her up. When a migration fails in public, it has generally failed in private three months prior because no one was in charge.

When migration is the wrong project

There is also the question of whether a move to WordPress is warranted at all. For sites with government or higher-ed constraints, complex workflows or custom modules tied to compliance, an in-place upgrade is often cheaper. Some would be better served by a headless setup that keeps Drupal as the store and puts something else on the front end. We cover the tradeoffs in our headless WordPress decision guide, and the reasoning is the same with a Drupal source.

Put it to the test: if you are chafing at the plugin ecosystem and usability, WordPress is a good fit. If your issue is hosting costs or finding developers, a re-platform won’t fix it.

Map the Content Model Before You Touch an Import Tool

Then there is the importer in WordPress core. It is schema-agnostic and knows what to do with users, terms, comments and the like. It has no concept of a Drupal entity, bundle or view mode. That is why the work is difficult.

Your content map has to be comprehensive. For each Drupal type you need to know:

1. Its equivalent in WordPress: a page, a post, a CPT or something merged in.
2. The field translation: native, ACF, Gutenberg blocks or block patterns.
3. The taxonomy side of things: categories, tags, or if they are to be dropped.
4. Media references: a path like /sites/default/files/... has to be rewritten and you have to provide a home for the rich metadata or you will lose it.
5. Internal links: WYSIWYG content may be pointing to node IDs or absolute URLs and each needs a rewrite.

Do not treat these mapping tables as scratch work. They are project artifacts. You need a table for every entity class (nodes, media, etc.) with the old ID and the new one, and a path mapping for every alias. Those tables will drive your QA and your redirect map. Leave them unattended and you will be hunting 404s in production.

We have seen it with publishers leaving behind legacy CMSes. In our case with Teton Gravity Research, we had to structure-map 10,000 articles from ExpressionEngine before we shipped a line of import code, and in the end we put some content types to rest rather than port them. Our walkthrough on preparing content for a CMS migration goes into the details.

Good migration documentation will be frank about it.

ZZBLOCK3ZZ You will seldom see a full Drupal revision history make it across in a migration. The usual way to handle that is to leave the old Drupal setup as a read-only resource behind the VPN for any historical or audit needs you might have. Then there is the matter of access control; Drupal’s per-bundle and field-level restrictions have no WordPress parallel, so while you can get close with custom roles and capabilities, they are not an exact match. And if you have multilingual content in the form of entity translations on the Drupal side, Polylang or WPML will want to see them as separate linked posts. It is a different structure altogether, and some teams will simply decide to migrate the primary language to save costs.

Whatever you are going to cut, name it before you go live. If your migration has quiet losses, you will be facing a trust issue with your editors in three weeks’ time.

Pick a Migration Method That Matches the Site

There are but three options to consider. Not one of them is right by default.

Plugin-based import This is fine for the simpler sites. Take the FG Drupal to WordPress plugin: it has been put through its paces with current WordPress and Drupal 4 to 11 and will move your articles, pages, stories, images, tags and categories without trouble. For a marketing site with limited custom structure and a handful of content types, it does the job. But be careful not to fall into the trap of applying it to anything non-trivial and then having to hand-build fixes for everything beyond the basics weeks down the line.

A custom pipeline When you are dealing with complex media, multilingual variants or structured content, this is the pattern to follow. You use the Migrate API on the source and WP CLI on the destination. Migrate API is an ETL framework with versioned, rerunnable plugins for source, process and destination. Since WordPress is not a first-class destination for it, you will typically export a normalized JSON or CSV from Drupal and do the transforming and importing over on the WordPress side. It is heavy work, but it is the only way to maintain referential integrity at scale.

Partner-led migration If the site is what drives your revenue, memberships or day-to-day operations, the cost of a botched cutover is too high to risk doing it once. Budget is rarely the deciding factor; it is whether the team in charge has done this before. That is why we have our website migration practice.

One rule for all of them: idempotency. You have to be able to run the whole thing against staging again without duplicating or corrupting data. Otherwise you have no safe way to deal with the delta between the first import and the final cutover.

Stage, Delta, Freeze, Cut Over

Big-bang migrations have a habit of failing. A staged approach is how you do it.

Start with phase one: put the full migration into a staging WordPress instance while Drupal is still live. Let the team check the editorial workflows, the URL structure, the media and the content. In phase two you run your delta migrations on the same environment – just the changed content since the last pass. This is where you find the edge cases you did not model and the mapping tables prove their worth. The cutover itself is brief: a content freeze in Drupal, one last delta, a DNS switch and the redirect map goes live at the CDN or server.

For the basic mechanics of the source-side handshake and setting up credentials, Kinsta has a good step-by-step for most plugins. But the parts that determine if the project ships well are not in any tool’s documentation.

What to QA on staging

Do not call it QA if you are only spot-checking the homepage. You want to look at:

• Some older content with edge-case fields, and representative samples of every type.
• Taxonomies, menus, archive pages and related-content modules.
• Whether forms are hitting the right destinations and sending the proper notifications.
• User accounts and role-based access that gives each team what they need and nothing more.
• Media at the correct path with its metadata.
• Internal links that resolve to the new URLs, not back to Drupal.

Put every issue on a list. Fix it or mark it as known-and-accepted before you launch. What you will find after cutover are the things you could have seen on staging and chose to skip.

SEO Continuity Is the Whole Ball Game

A badly handled migration shows itself in SEO degradation. You know the drill: 404s spike in the days following, rankings take a hit for a few weeks and then comes the slow debate over whether it is the design, the platform or the redirects. It is the redirects.

To keep your search visibility when moving from Drupal to WordPress:

• Get a complete URL inventory from Drupal before you cutover, from a fresh crawl and the database. You need to map the node IDs and Pathauto aliases.
• Where you can, do a one-to-one path mapping. Where you can’t, put in place some deliberate rules rather than shunting everything to the home page.
• For any site with a lot of URLs, implement 301s at the server or CDN layer. Plugin-based ones add latency and do not scale well once you pass 100,000 or so.
• Do not just move body copy. Make sure meta titles, canonicals, hreflang and structured data come over.
• Run a pre- and post-launch crawl and put them side by side to compare status codes, indexable status and meta output.

Even with good planning you will see traffic dip for a while. Your aim is to make it shallow and short-lived. We go into the redesign side of this in some detail in our guide on redesigning a website without losing SEO, and the principles hold up for a CMS migration.

Performance is not automatic

You will find that a Drupal site is typically sitting on a stack that has been put through its paces: PHP-FPM, Varnish, Redis and the like, with a CDN in front of it. Make the move to an off-the-shelf managed WordPress without putting in place comparable caching and you are asking for a post-migration slowdown. Do a straight module-to-plugin swap on top of that and the new installation is going to be heavier than what it was meant to replace. The answer is to set a performance budget ahead of cutover and load test to it. Caching and CDN setup should be in the migration scope from day one, not something you put off to Phase 2.

Editorial Workflow Is Part of the Migration

If you talk to the teams with the most complaints after launch, they are the ones who left editor enablement to the last minute, treating it as some training to be crammed in the week before go-live. Workflows are already broken by then.

WordPress is great at democratizing the editorial process but where it falls short of Drupal is in fine-grained control. You have to design for that tradeoff. Figure out what capabilities each role requires and make custom ones if the defaults don’t fit. Put together block patterns that suit the way editors actually work and document the new procedures to fill the void left by their old Drupal habits.

We saw this when we put together the new platform for St. Louis Magazine, bringing over 30,000 articles with us. The editorial design was as important as the import code. They had outgrown their CMS because the workflow had hardened around it; the migration was our chance to correct that, not merely to shift the content.

Plan for the Ninety Days After Launch

We like to tell our clients to think of launch as a checkpoint rather than the end of the road. It is only after you are live that traffic will show you which redirects you missed or which plugin is adding unneeded load that went unnoticed in staging.

Make room in the budget for it. For the first month you want to be looking at Search Console and analytics every day, holding weekly sessions to get feedback from editors and churning through a backlog of small fixes. Then in months two and three you can decide if it is worth writing some custom code to put an end to plugin debt or to refine your block patterns. And let the old Drupal instance do some good as a read-only archive. It is cheap insurance to have it behind a VPN for compliance or to check a revision, and it spares the editorial team from having to re-create history in the new system.

One Last Argument Against Hurrying

There is very little substance to the public discussion on moving from Drupal to WordPress. What you see on Reddit or Stack Overflow is either stale or from a vendor with a product to push. It is hard to put any stock in their claims about cost or timeline and all too easy to under-estimate the custom work involved.

The truth of it is that you are undertaking a re-platforming and modernization effort in the guise of a data migration. Picking the platform is the simple bit. The risk and the value are in the governance, the URL continuity, the content modeling and the workflow design. Get those sorted early and the rest is just execution. Leave them to chance and no pipeline will fix it.

Should you be mulling over such a move and need a plan in hand before anything is moved, that is what we do at Refact’s CMS migration practice.