Drupal is a capable platform, and many organizations chose it for good reasons. But over the past few years a lot of Drupal teams have come to the same conclusion: upgrades are expensive, specialized developers are hard to find and editors struggle with the admin experience. Drupal 7 reached end of life in January 2025, which forced many of those organizations to choose between a costly rebuild on a newer Drupal version or a move to another platform. WordPress is often that choice.
Here is how we approach a Drupal to WordPress migration for a large site.
Inventory everything first
Drupal sites accumulate structure. Before we write any code, we produce a full inventory:
- Content types and every field on each, with field types and how often they are used
- Taxonomy vocabularies and terms, including hierarchies
- Views, which often power listings and need equivalents in WordPress
- Blocks, menus and paragraphs or layout builder structures
- Users, roles and permissions
- Files and media, including private files
- Modules that provide functionality, such as webforms, workflows or integrations
- Every URL, including path aliases and redirects already in place
That inventory becomes the migration map and the scope.
Map content types to WordPress
Drupal content types usually map cleanly to WordPress post types, and vocabularies map to taxonomies. Fields become custom fields or, better, structured blocks. We often simplify along the way. A Drupal site with twenty content types may really need eight in WordPress, with taxonomies doing the rest. Our content modeling approach keeps the new structure clean rather than recreating every historic decision.
Paragraphs and layout builder content deserve special attention. We convert them into Gutenberg blocks during migration so editors get real, editable content instead of a frozen blob of HTML.
Build a repeatable migration script
We never migrate large sites by hand or with a one shot plugin. We write migration scripts, usually with WP-CLI, that read from the Drupal database or exports and write into WordPress. They are repeatable, so we can run them many times as the content model is refined, and incremental, so the final run before launch only brings over what changed. That is how a content freeze shrinks from weeks to hours.
Users and authentication
Drupal and WordPress hash passwords differently. Users can be migrated with their roles mapped to WordPress roles, and we can either support legacy Drupal password hashes on first login so people keep their passwords, or move everyone to single sign on. For public sites with few logged in users, a password reset email at launch is often simplest.
Media and files
Files are copied with their folder structure or reorganized into the WordPress uploads layout, and every reference in content is rewritten. Image styles in Drupal map to WordPress image sizes. We also capture alt text and captions so nothing is lost.
Redirects and SEO preservation
Search rankings follow URLs. Every Drupal path alias gets a mapping to its new WordPress URL, and every change is covered by a 301 redirect. We carry over titles, meta descriptions and canonical URLs, regenerate XML sitemaps and monitor Search Console closely after launch. Our migration SEO guide covers this in detail.
Rebuild functionality, not modules
Rather than looking for a WordPress plugin for every Drupal module, we look at what each module actually does for the organization. Webforms become Gravity Forms or a similar tool. Views become Query Loop blocks or custom blocks. Workflows become editorial roles and review plugins. Some features turn out to be unused and are simply retired.
Test, train and launch
We compare page counts, spot check content side by side, run automated link checks and walk through key journeys. Editors are trained on WordPress before launch. On launch day we run the final incremental migration, switch DNS and watch logs and analytics closely.
Editorial training and the first month
A migration succeeds when editors are comfortable on day one. Before launch we run role based training sessions using the client's own migrated content, so people learn on pages they recognize. We provide short written guides for the tasks each role performs most, such as publishing news, updating a page or adding an event. For the first month after launch, we hold regular office hours and respond quickly to questions, because small frustrations early on shape how a team feels about the new platform. Drupal editors in particular often tell us that the block editor feels like a relief. Making that first impression smooth is part of the migration, not an extra.
Drupal migration checklist
- Full inventory of types, fields, vocabularies, views, users and URLs
- Simplified WordPress content model
- Repeatable, incremental WP-CLI migration scripts
- Paragraphs converted to editable blocks
- User and password strategy decided
- Media copied with alt text and references rewritten
- 301 redirects for every changed URL
- Editor training and a short content freeze
Frequently asked questions
How long does a Drupal to WordPress migration take?
It depends on size and complexity. A simple site can move in weeks; large multi site platforms take longer. Repeatable scripts keep the final cutover short.
Will we lose SEO rankings?
With complete redirects and preserved metadata, rankings usually hold. Short term fluctuation is normal while search engines recrawl.
Can several Drupal sites become one WordPress Multisite?
Yes. See our guide to consolidating legacy platforms.
Ready to plan your move? See our Drupal to WordPress migration service, or browse all of our platform migration services.
