Move your Drupal content types, nodes, taxonomy, and users to WordPress with the FG importer, mapping content types to custom post types along the way.
Drupal to WordPress migration, in one paragraph
Drupal scares people. It shouldn’t. Moving your nodes, content types, taxonomy, users, and media out of Drupal and into WordPress is far more achievable than the platform’s reputation suggests. The standard tool is the free FG Drupal to WordPress importer. It connects straight to your Drupal database and brings articles, pages, categories, tags, and images across in a single pass. The craft lives elsewhere. It’s in mapping Drupal content types to WordPress custom post types (CPTs) and carrying over custom fields, and that’s where the Premium add-on and a little planning earn their keep.
Drupal is one of the platforms I’ve moved clients off of for years, alongside Wix, Squarespace, and Joomla, and each one stores content differently enough that you can’t reuse the same recipe twice. The structured ones are a different animal though. The hardest migration I’ve ever done, the Scattergood Foundation, wasn’t Drupal, but it was the same shape of problem this guide is about. A legacy CMS packed with research publications that each belonged to a thick web of classifications at once. The content copied over fine. Rebuilding that classification structure inside WordPress is what cost me days. Drupal content types are that exact modeling puzzle, which is why I lead with it. So this guide walks the whole thing. What migrates, how Drupal’s content model maps to WordPress, the exact import steps, and how to keep your SEO intact. If a content-type-heavy Drupal site feels like a lot to take on alone, jbe.works offers a managed WordPress migration service that handles the import, the CPT mapping, and the redirects for you.
Why move from Drupal to WordPress
Drupal is powerful. Enterprise-grade, even. But the same handful of reasons keep pushing teams toward a Drupal to WordPress migration anyway.
Lower total cost and easier hiring
Specialized Drupal talent is expensive, and the pool is small. WordPress runs a large majority of CMS-based sites, which means developers, agencies, and freelancers are everywhere and they compete on price. Every future change to your site costs less as a result.
Friendlier content editing
Drupal’s admin was built for developers and structured-content teams. Marketers and non-technical authors tend to find the WordPress editor far easier to live in. Day-to-day publishing just moves faster.
Major-version upgrade fatigue
Historically, Drupal’s major-version jumps have demanded serious re-platforming work. Plenty of teams hit one of those forks and reason that if they’re rebuilding from scratch anyway, they’d rather land on WordPress.
A massive plugin ecosystem
Much of what needs a custom module in Drupal already ships as a maintained WordPress plugin. Outgrow the theme model later? You can run WordPress headless with a Next.js frontend and get Drupal-class performance with WordPress-class authoring.
The FG Drupal to WordPress importer: what it migrates
For this particular move, the free FG Drupal to WordPress plugin is the tool everyone reaches for. It carries 700+ active installations and a 4.6-star rating on WordPress.org. It connects directly to your Drupal database and supports the MySQL, PostgreSQL, and SQLite drivers.
What the free version migrates
Out of the box, the free plugin brings across the everyday content most sites are built on.
- Drupal articles, stories, and pages as WordPress posts and pages
- Categories and tags (Drupal taxonomy) into WordPress taxonomies
- Images and media, uploaded into WordPress directories with alt text preserved
- Internal links rewritten and post content modified to keep media links working
- Featured images set automatically, with image resizing to WordPress sizes
It’s been tested with Drupal 4 through 11 and the latest WordPress, so it covers legacy and modern installs alike.
What the Premium add-on adds
Then there’s what the free version quietly skips. It does not touch custom content types or custom fields, which makes Premium close to mandatory for any non-trivial Drupal site. What you get on top.
- Custom post types and custom taxonomies, the core of mapping Drupal’s content model
- Custom fields, plus support for CCK (Content Construction Kit) and ECK (Entity Construction Kit) via add-ons
- Users and authors migrated with their Drupal passwords, plus user pictures
- Navigation menus and blocks migrated as (inactive) widgets
- SEO 301 redirects from Drupal URLs to the new WordPress URLs
- Selective imports (only specific node types), Drupal 8+ Media entities, and WP-CLI support for large sites
My rule of thumb is simple. Anything beyond basic pages and articles. Custom fields, custom content types, more than one author. The moment a site has any of that, I budget for Premium from day one. Skip it and the free version quietly leaves your structured data behind, which is a brutal thing to discover after you’ve already cut over.
Mapping Drupal content types to WordPress custom post types
This is the part that sets a Drupal migration apart from every other platform move. Drupal is built around content types (node types) carrying structured fields. WordPress expresses the same idea through custom post types (CPTs) and custom fields, usually via Advanced Custom Fields (ACF).
I keep coming back to the Scattergood Foundation here because it taught me what this step really costs. A legacy archive of research publications, and every publication was filed under a stack of overlapping classifications at the same time. Modeling that inside WordPress is where I lost most of the project. I would map a content type, register the taxonomy, wire up the field group, then go to verify it and find a publication that was cross-filed in some way the model didn’t account for. Fix that, and another cross-classification would surface behind it. It went like that for days. Not glamorous work. Just a long grind of building the structure, breaking it against a real edge case, and rebuilding it until WordPress held the relationships the way the old system had. Drupal’s content-type and taxonomy model hands you that same puzzle. Usually smaller, but the same shape, and the import means nothing if the structure underneath it is wrong. That is why I treat the modeling as the actual job and the import as the part that takes an afternoon.
The core mapping
| Drupal concept | WordPress equivalent | Notes |
|---|---|---|
| Node type: Article | Post | Maps to the default blog post type |
| Node type: Basic page | Page | Static content becomes a page |
| Custom content type | Custom Post Type (CPT) | Premium feature; one CPT per Drupal type |
| Fields (CCK / ECK) | Custom fields (ACF) | Each Drupal field becomes an ACF field |
| Taxonomy: Vocabulary | Custom taxonomy | e.g. a Drupal vocabulary becomes a WP taxonomy |
| Taxonomy: Term | Term | Categories/tags map directly |
| Users / roles | Users / roles | Passwords preserved (Premium) |
| Blocks | Widgets (inactive) | Migrated but need placement (Premium) |
| Views / modules | Plugins / queries | No transfer; rebuilt in WordPress |
How to plan the mapping
Start with a list. Every Drupal content type, every field on it. Then decide where each one lives in WordPress. Some map to a built-in post type. Others need a new CPT plus an ACF field group that mirrors the Drupal fields. Register those CPTs and ACF groups in WordPress before you run the import, so the incoming data has somewhere structured to land.
Plan around one thing early. Drupal Views, custom modules, and theme logic do not migrate at all. You rebuild them from scratch with WordPress queries, plugins, and a theme. Treat that as separate work from the content import and budget for it on its own, because it’s exactly where Drupal projects tend to blow their estimates.
Prepare before you run the importer
Drupal rewards planning more than any platform move I’ve handled. Get these in place first.
Back up both sites and snapshot the database
Back up your Drupal database and files. Snapshot the new WordPress install too. The FG importer reads from Drupal and writes into WordPress, so you want rollback points sitting on both ends.
Get your Drupal database credentials
You’ll need the Drupal database host, name, username, password, and driver (MySQL, PostgreSQL, or SQLite). All of it lives in Drupal’s settings.php.
Audit content types and fields
Document every content type, field, and taxonomy in Drupal. That audit is exactly what you translate into CPTs and ACF field groups later, and it doubles as your QA checklist when you’re verifying the import.
Inventory URLs and benchmark SEO
Crawl your live Drupal site. Export every URL. Record current rankings and traffic so you can later prove the migration was clean. A quick free pre-migration audit captures that baseline for you. Then install WordPress on a staging environment. Never migrate onto a live domain. For the fundamentals underneath all of this, start with the complete WordPress migration guide.
How to migrate Drupal to WordPress, step by step
Below is the full FG Drupal importer workflow, start to finish. Clean WordPress install on one end, live and redirected site on the other.
1. Register your CPTs and fields first
On staging, register the custom post types and ACF field groups that mirror your Drupal content types and fields. Doing this before import gives the structured data a destination.
2. Install WordPress and the FG importer
Install the FG Drupal to WordPress plugin (plus Premium and any CCK/ECK add-ons you need) and open it at Tools > Import > Drupal.
3. Connect to your Drupal database
Enter your Drupal database host, name, username, password, and driver. Test the connection so you know the plugin can read your Drupal data before importing.
4. Map content types and configure options
In Premium, map each Drupal node type to its WordPress post type or CPT and align fields to your ACF groups. Choose media handling and whether to import all or only selected node types.
5. Run the import
Start it. The plugin scans your Drupal database and pulls over nodes, taxonomy, users, and media. On large sites, lean on WP-CLI for stability and let the whole thing finish before you touch anything.
6. Modify internal links and set up redirects
Run the internal-link modification step. Then enable Premium’s Drupal-to-WordPress 301 redirects, or build a manual redirect map yourself, so every old Drupal URL resolves to its new WordPress equivalent.
7. Rebuild design, Views, and navigation
Apply your WordPress theme, recreate Drupal Views as WordPress queries or with a plugin, place migrated blocks/widgets, and rebuild menus.
8. QA on staging, then go live
Verify CPTs, fields, taxonomy, images, internal links, and redirects. When it all passes, point DNS at WordPress, verify SSL, and submit a fresh sitemap in Google Search Console.
One thing carries this whole section. Register CPTs and fields before importing, and map every node type deliberately. Skip the modeling step and you turn a clean Drupal migration into a data-loss cleanup job. I’ve watched people learn that the expensive way.
Preserving SEO and rankings after migration
Drupal sites often carry years of accumulated authority. Don’t throw it away in the move.
- Map every URL. Drupal’s path structure (and node IDs) differ from WordPress permalinks. 301-redirect each old URL to its new slug, or use Premium’s redirect feature.
- Preserve metadata. Carry over titles and meta descriptions so search engines see continuity.
- Use 301, not 302. Permanent redirects pass link equity; temporary ones don’t.
- Install an SEO plugin (Yoast or Rank Math) to manage titles, descriptions, and your sitemap.
- Watch your CPT URLs. Custom post types add a slug prefix by default, so match your old structure or redirect to avoid mass 404s.
- Resubmit your sitemap in Google Search Console immediately after launch and monitor crawl errors.
Here’s the part people miss. On a structured site, your URL map is only as good as the content model sitting under it. When I finally had Scattergood’s classifications rebuilt correctly in WordPress, the redirects had somewhere coherent to point and the category and archive pages resolved the way Google already knew them. Get the modeling wrong and no redirect list saves you, because the pages those URLs are supposed to land on don’t carry the same meaning anymore. That’s the real lesson from structured Drupal sites. Moving the content is the easy half. Keeping the structure and the authority attached to it intact is the hard one.
Migration risk on a Drupal site lives in two places. The content model and the URL map. Get both right and the rankings follow you over.
Dozens of content types and a lot of organic traffic to protect? That’s precisely the work jbe.works’ WordPress migration service handles. CPT modeling, field mapping, URL redirects, and post-launch monitoring, all of it.
Common Drupal migration pitfalls
A handful of mistakes account for most of the pain on a Drupal to WordPress migration. These are the ones I keep hitting on real Drupal jobs, plus one I’ve walked into myself. On a direct client move the Views were the trap. The old site leaned on a dozen of them for its listing pages, and since Views don’t migrate, half the site looked empty after a clean import until I rebuilt each one as a WordPress query. Watch for these.
- Using the free version for a complex site. It skips custom content types and fields, so your structured data won’t come across without Premium.
- Not modeling CPTs first. Importing before registering CPTs and ACF fields means custom data has nowhere structured to land.
- Skipping redirects. Drupal and WordPress URL formats differ; without 301s, every old URL 404s.
- Forgetting Views and modules. Listing pages and custom functionality must be rebuilt. They don’t migrate.
- Wrong database driver or credentials. Confirm the driver (MySQL/PostgreSQL/SQLite) and details from
settings.php. - Import timeouts on large sites. Use WP-CLI and raise PHP limits for big databases.
For a deeper troubleshooting reference covering 404s, 500 errors, database connection failures, and missing images, see common WordPress migration errors and how to fix them. The FG-importer workflow here mirrors the Joomla to WordPress migration guide closely, so that’s a useful companion read.
Your next step
None of this is out of reach. The FG importer pulls nodes, taxonomy, users, and media straight from your Drupal database, and Premium handles the custom post types, fields, and redirects that let a structured Drupal site land intact. Model your content types first. Map every URL. Verify the whole thing on staging before you cut over.
If the content modeling and redirect mapping feel like more than you want to own, jbe.works delivers done-for-you WordPress migration with CPT modeling, field mapping, SEO preservation, and zero-downtime cutover. Start with a free pre-migration audit to benchmark your Drupal site, then hand the move to a specialist.
Frequently asked questions
Is there a plugin to migrate Drupal to WordPress?
Yes. The FG Drupal to WordPress plugin migrates articles, pages, taxonomy, and images for free by connecting to your Drupal database (MySQL, PostgreSQL, or SQLite). A paid Premium add-on adds custom post types, custom fields, users, menus, and 301 redirects.
How do Drupal content types map to WordPress?
Drupal node types map to WordPress post types or custom post types (CPTs), and Drupal fields (including CCK/ECK) map to WordPress custom fields, usually via Advanced Custom Fields. Register the CPTs and field groups before importing so the data lands in the right structure.
Does the free FG Drupal importer migrate custom fields?
No. The free version handles basic content like pages, posts, categories, and users. Custom content types and custom fields require the Premium version.
What Drupal versions does the FG importer support?
The plugin has been tested with Drupal 4 through 11 and the latest version of WordPress, covering both legacy and modern Drupal installs.
How long does a Drupal to WordPress migration take?
A simple Drupal site can migrate in a day or two; a complex site with many content types, custom fields, Views, and redirects can take several weeks. The import is fast. Content modeling, rebuilding Views, and QA are where the time goes.