Drupal to WordPress: when it is the right move, and what you give up.

What transfers from Drupal to WordPress, and what does not?

Your standard content types, categories, tags, and media transfer with the free FG Drupal to WordPress plugin. Some items do not. Your users, password hashes, custom post types, menus, comments, and automatic 301 redirects require the Premium version. If you leave users behind (and plenty of sites can), the free version can handle the job, as Kinsta notes.

Your theme will not transfer. You rebuild it from scratch because Drupal 8 and later runs on Twig while WordPress runs on PHP templates. Your Paragraphs take the most work: you map each type to a custom Gutenberg block or an ACF field, then write the replacement blocks. Then comes cleanup. After the bulk export, you manually fix custom field data, Metatag values, broken media paths, and entity relationships. Budget real time for that manual pass. And you will only spot those omissions once you audit the old pages against the new build.

How do you plan the URL map and redirects so your search traffic survives?

Map your paths in a spreadsheet where column A lists every Drupal URL, column B holds the target WordPress URL, and column C tracks the status: exact match, redirect needed, consolidate, or delete. Pull the aliases directly from the path_alias table. Include Pathauto records, and export your Redirect module rows so you avoid chains. If you drop redirect mapping for Pathauto URLs, ClonePartner reports that sites typically lose 20 to 40% of their organic traffic in the first 90 days. Some paths slip through often. Check assets moving from sites/default/files/ to wp-content/uploads/, taxonomy archives with added or dropped trailing slashes, and altered pagination schemes. Term pages frequently pull long-tail search traffic, so rebuild your taxonomy templates and redirect the legacy routes. (Nobody remembers to check those until the traffic dips.)

Configure server-side 301 or 308 redirects without chains, following Google Search Central guidance. Keep watching. Track search metrics across both properties in Search Console, submit your new sitemap, and leave those redirects active for at least a year. But don't treat launch day as the finish line.

How is content moved from Drupal: export, API or crawl?

Migrate your database with a plugin run for bulk records and manual patches for edge cases. Crawl public pages to audit the cutover, not to scrape source data. Codeable details this split approach: let the FG plugin migrate posts, media assets, and terms, then manually repair unmapped custom fields, missing file paths, and scripts that link custom entity relationships.

A crawl captures browser-facing data: rendered HTML, HTTP response headers, heading tags, schema markup, and canonical tags. It misses the back office. Draft nodes, database field schemas, and role permissions stay out of view, which means you cannot reconstruct your content architecture from front-end scans alone. Before running migrations, pull database exports of every path alias, your Redirect module table, rendered Metatag output, and alternate hreflang tags. A public crawl will not reveal private API endpoints. So verify backend access with your engineers before architecting the pipeline.

What do your editors get on WordPress compared with Drupal?

Your editorial team gets a standard dashboard with two built-in types: Posts, which carry publish dates, categories, and tags, and Pages, which remain hierarchical and unclassified. That covers the basics. But when you need custom structures, register dedicated post types and taxonomies. The Custom Post Type UI plugin, active on more than 1,000,000 sites, sets up those definitions through the admin without custom code.

You surrender relational rigor, and you see the difference in your fields. Drupal entity fields, vocabularies, access permissions, and translation graphs have no core counterparts in clean WordPress installs. Build the model first. You recreate that data model with custom post types and ACF field groups before migrating raw data. Skip this preparation and your content dumps into the wrong tables, as shown in Gautam Khorana's case study where 800 article nodes imported directly into standard Posts. Your Paragraphs turn into Gutenberg blocks or ACF Flexible Content layouts, requiring React experience to write custom block interfaces. (That is a skill gap, not a setting you can toggle.)

If your site is small and editorial with a few content types, you will accept that trade.

How long does a Drupal to WordPress migration take, and what drives the effort?

Your project schedule hinges on five factors: total URL volume, content type diversity, media library size, third-party integrations, and active locales. No external benchmark can quote you an exact delivery date. Each retained content type adds work. Every content type you retain requires a custom post type registration, ACF field schemas, and dedicated template code. And your front end demands a full rewrite, not a stylesheet port.

Higher page counts produce larger URL inventories and heavier redirect QA. Multiple locales require distinct hreflang exports and manual parity audits across staging domains. Paragraphs change the estimate. If your pages rely on Paragraphs, allocate extra sprint capacity for block engineering. Pagepro's SEO checklist lays out 8 steps, from initial benchmark to post-launch monitoring, and every single one needs a slot in your budget.

The free assessment grounds your estimates in technical data. It fetches your homepage and up to eight sampled pages, returning one score out of 100 across eight pillars. You see the surface. That scan checks script payload sizes, response headers, and schema markup before you commit to sprint estimates. It cannot inspect private analytics, so you must still inventory your own content types.

When should you not move from Drupal to WordPress?

You should not move if your Drupal site is content-heavy, because you will usually lose more in fields, taxonomies, permissions and multilingual structure than you gain. You should also stay if your site is stable, your editors like it and your pages read well in the assessment.

Check your core release: Drupal 7 hit end of life on January 5, 2025, and Drupal 10 reaches official end of life on December 9, 2026. Do not drift. And you need an active roadmap for an in-place upgrade or a full platform migration.

For static editorial and marketing sites, evaluate Astro. For dynamic web apps, personalized user sessions, or large editorial teams, consider Next.js paired with Sanity or Contentful. There is a tradeoff. Astro drops the visual page builder and plugin runtime your editors know; a headless architecture requires building and paying for a separate backend. I evaluate technical architecture, map cutover plans, and migrate legacy installations and WordPress setups to these modern runtimes, but I route standard WordPress development contracts to agency partners.

Questions, answered.

Your next read.

1. 01Drupal alternativesUpgrade, decouple or move, judged by your pages.
2. 02Drupal to Next.jsDecouple or replace, with the content model intact.