Drupal → WordPress
Back up the Drupal database and files, then import content into a staging WordPress site. The FG Drupal to WordPress plugin is the importer WordPress.org documents. Views, layouts, and most module data are a rebuild.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Drupal
- Content types, fields, and a deep module ecosystem fit complex publishing sites
- Editors get a purpose-built publishing workflow instead of raw files
- Views, custom fields, and module data need an explicit map before they mean anything in another CMS
- Themes, extensions, and content models add maintenance and portability constraints
WordPress
- Unmatched ecosystem breadth and content ownership support almost any publishing model
- Editors get a purpose-built publishing workflow instead of raw files
- Plugin, hosting, security, and performance maintenance accumulate over time
- Themes, extensions, and content models add maintenance and portability constraints
WordPress: Unmatched ecosystem breadth and content ownership support almost any publishing model. This removes a major source-side concern: Views, custom fields, and module data need an explicit map before they mean anything in another CMS.
What you lose: Content types, fields, and a deep module ecosystem fit complex publishing sites. What you inherit: Plugin, hosting, security, and performance maintenance accumulate over time.
Jump to a section
Know the shape of the move.
This timeline assumes
- You have a restorable copy of the Drupal database, the sites directory, and the upload directory.
- WordPress is on a staging host that can reach a read-only copy of the Drupal database if you use the FG plugin.
- You are moving articles, pages, taxonomies, and files first. Views, layout, and module features are a separate rebuild.
- The Drupal site stays online until media and the important URLs are checked.
- You will change passwords or force resets. Do not expect Drupal password hashes to become WordPress passwords.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Articles, stories, and basic pages | partial | critical | The FG plugin page says it migrates Drupal articles, Drupal 6 stories, basic pages, categories, tags, and images, and that it has been tested with Drupal 4 through 11. It reads the Drupal database and does not modify it. The WordPress import handbook still describes an older compatibility range, so trust a pilot on your major version. | Pilot your exact Drupal version. Compare node counts by type. |
| Files and image links | partial | critical | The plugin page says it uploads post media into the WordPress uploads directory, can fetch external media, rewrites media links, and can set a featured image. Image styles and derivatives are not the original files. | Copy sites/default/files yourself as well. Check that bodies point at the WordPress files. |
| Users | partial | high | A content import can create authors. It does not move Drupal password hashes into WordPress. | Create accounts you still need and send password resets. Check roles by hand. |
| Custom fields and references | partial | critical | The free plugin description is about articles, pages, categories, tags, and images. Reviews on the plugin page talk about separate CCK and Entity Reference add-ons for fielded sites. Those add-ons are not part of the base description. | Inventory fields and entity references. If you need them, confirm the add-on on a staging node before the full run. |
| Paths and aliases | manual | critical | Drupal path aliases and WordPress permalinks are different systems. The plugin page says it modifies internal links. It does not publish a redirect map for you. | Build a redirect from each live alias you care about. Request the old URL after cutover. |
| Views, layouts, and theme | manual | critical | Views, block layout, and the theme do not become a WordPress theme or a set of blocks. | Rebuild the templates that matter. Compare the important URLs in a browser. |
| Comments | partial | medium | The base plugin description does not list comments. If comments matter, check whether your importer version brought them, using one node that has comments. | Count comments on a sample of nodes. Move a third-party comment system separately if that is what you use. |
| Module data | manual | high | Webforms, commerce, memberships, and search configuration live in module tables. A node import does not recreate them. | List each module that stores data people still need. Give it a destination or an archive. |
| Multilingual content | partial | high | The plugin page does not document language handling in the feature list. A multilingual site needs its own check. | Import one node in each language and confirm the URL and the body. |
| Revisions and search indexes | lost | medium | Old node revisions are not a WordPress revision history unless you build that. Search indexes are rebuilt. | Keep the Drupal database if you still need an old revision. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Article or story | Post | transform | Confirm the type on your Drupal version. |
| Basic page | Page | transform | Check the parent and the slug. |
| Taxonomy term | Category or tag | transform | The plugin lists categories and tags. |
| File on a node | Media library item | transform | Also keep the original files directory. |
| Body HTML | Post content | transform | Look for image URLs that still point at Drupal. |
| Path alias | Permalink plus a redirect | manual | Build the redirect list from the live aliases. |
| Custom field | Post meta or a block | manual | Not in the base plugin feature list. |
| User | WordPress user | manual | Reset the password. |
| View or block layout | No destination | unsupported | Rebuild the presentation. |
Make the move recoverable.
Create the source-of-truth backup
Keep a full Drupal backup that the importer cannot change.
- Copy the database. The user guide says a full database backup is the safe choice, even if some cache tables can be skipped.
- Copy sites/default, including settings.php, and the upload directory shown under Configuration, Media, File system.
- Copy custom modules and themes.
- Restore that backup onto the staging database the importer will read, not onto a database you still edit.
Proof to capture: A staging copy of Drupal boots from the backup, and the production site was not written to.
Staging import
Read Drupal from a copy and write WordPress on a host that is not the live domain.
- Install WordPress on staging and add the importer.
- Point it at the copy of the Drupal database. The plugin says the source database is only read.
- Run a small content type first.
- Compare counts, then run the rest.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Redirect map
Keep the public URLs that already have visitors.
- Export path aliases from Drupal.
- Record the WordPress permalink for each one.
- Install redirects before DNS changes.
- Request a sample of old URLs and confirm the status code.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
The importer is aimed at production Drupal
A tool writes to the live database, or a credential has write access.
- Consequence
- Content changes under you.
- Mitigation
- Use a restored copy, and a database user that can only read.
Stop if: The Drupal write count moves during the import.
Fields the base plugin does not list are assumed present
Custom fields and references are missing in WordPress.
- Consequence
- The staging site looks complete and is not.
- Mitigation
- Compare a fielded node before the full run.
Stop if: A required field is empty.
Aliases change without redirects
Old URLs 404 after DNS moves.
- Consequence
- Incoming links break.
- Mitigation
- Test the redirect sample before cutover.
Stop if: A priority URL does not resolve.
Do the work in this order.
- Days 1 to 4 · inventory
List types and modules
8 to 16 hours active2 to 4 days elapsedEditors waiting- List content types, fields, languages, and modules that store data.
- Choose what is in the first import.
Depends on: Drupal admin, Staging host
Stop / go checkpointTake the backup?
Go when: Each type has a destination or an explicit skip.
Stop when: A module that holds production data is unnamed.
- Days 4 to 6 · backup
Back up and restore a copy
4 to 10 hours active1 to 3 days elapsedDatabase restore waiting- Back up the database, sites directory, and files.
- Restore a read-only copy.
Depends on: Approved inventory
Stop / go checkpointImport the pilot?
Go when: The copy serves the same node counts.
Stop when: The backup will not restore.
- Days 6 to 14 · pilot
Import a slice
12 to 30 hours active4 to 8 days elapsedMedia copy waiting- Import one type.
- Check fields, files, and one alias.
- Start the theme rebuild.
Depends on: Restored copy
Stop / go checkpointImport everything in scope?
Go when: The slice matches Drupal.
Stop when: Fields or files are wrong.
- Days 14 to 20 · cutover
Final import and DNS
8 to 20 hours active2 to 6 days elapsedDNS waiting- Freeze Drupal edits.
- Re-import the delta.
- Turn on redirects and switch DNS.
Depends on: Passed pilot
Stop / go checkpointSwitch DNS?
Go when: Counts match and the redirect sample works.
Stop when: Drupal is still being edited, or a priority URL fails.
- Days 20 to 30 · observe
Watch the live site
6 to 16 hours active5 to 10 days elapsedSearch and editors waiting- Watch 404s.
- Keep the Drupal backup.
Depends on: Verified cutover
Stop / go checkpointRetire Drupal?
Go when: No blocking check fails.
Stop when: A content type or redirect regresses.
Cut over with a way back.
Cutover
Serve the site from WordPress, with Drupal frozen and the backup still restorable.
- Put Drupal in a read-only mode your editors understand.
- Import the final delta into staging and recheck counts.
- Deploy that WordPress database and the uploads to production.
- Enable redirects, then change DNS.
- Request the old URLs from outside your office.
Proof to capture: WordPress answers the production host, counts match the frozen Drupal copy, and the redirect sample returns the pages you named.
Rollback
Point DNS back at Drupal.
- Stop edits in WordPress.
- Restore the previous DNS or web root.
- Export any WordPress posts created after the switch.
- Review that export before you put it into Drupal.
- Confirm Drupal serves the important URLs.
Proof to capture: Drupal is the live site again, and post-cutover WordPress edits are listed.
- A content-type count is short
- Required files 404
- A priority old URL 404s
- Editors cannot sign in
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Node counts | Compare Drupal types with WordPress posts and pages. | Scoped types match. | Count sheet | |
V-02Blocking | Fielded node | Open a node that uses custom fields. | The values you required are present. | Field sample | |
V-03Blocking | Media | Open images in a sample of bodies. | They load from WordPress, not from a dead Drupal path. | Media sample | |
V-04Blocking | Redirects | Request the old aliases you listed. | Each one lands on the right WordPress URL. | Redirect log | |
V-05Blocking | Authors | Check bylines and try a reset. | Authors match, and a reset mail arrives. | User sample | |
V-06Blocking | Translations | Open one node per language, if you have them. | The body and URL match Drupal. | Language sample | |
V-07Blocking | Publish | Publish a staging post as an editor. | The role can do the work you promised. | Role note | |
V-08Blocking | Restore | Confirm the Drupal backup still restores on a spare host. | A node opens from the backup. | Restore note |
Remove the scaffolding safely.
Safe after: WordPress has served a normal publishing week and the Drupal backup still restores.
- Archive the database dump and the files directory.
- Remove the importer's database credentials.
- Delete staging copies you do not need.
- Keep Drupal until the date you set for redirects and rollbacks.
- Cancel Drupal hosting only after that date.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
On 23 January 2025, the WordPress.org user oculeumllc reviewed FG Drupal to WordPress. They say they used that plugin, plus the author's CCK and Entity Reference plugins, to move 12 Drupal 7 sites. Some of those sites had many content types and more than 5,000 nodes, with custom fields and complex entity reference fields. They describe themselves as a site builder rather than a PHP back-end developer. The review says the move needed edits to php.ini and wp-config.php, and that the plugin author walked them through those changes. URL redirects and which individual fields failed are outside what they wrote.
- Plan on the CCK and Entity Reference plugins when the site has custom fields. This review used both, on sites with complex entity references.
- Budget time for PHP limits. This review needed php.ini and wp-config.php changes before the import would finish.
- A site builder without a PHP background reports finishing 12 Drupal 7 moves, including sites above 5,000 nodes.
- The account is a plugin review, so it names scale and server edits and leaves the redirect map unstated.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- WordPress: importing content, including DrupalAccessed 2026-11-05
- WordPress.org: FG Drupal to WordPressAccessed 2026-11-05
- Drupal User Guide: data backupsAccessed 2026-11-05