This is an illustrative composite scenario. It does not describe any single real organization; it generalizes patterns we see repeatedly across mid-market replatforming projects. Figures are typical ranges, not one organization’s exact numbers.
Context
Picture a mid-market membership organization running an aging Drupal site — a few thousand articles and resources, a handful of content types with dozens of custom fields, and a stack of contributed modules that only one long-tenured developer fully understood. An end-of-life version and a shrinking pool of affordable Drupal talent forced the question. Leadership wanted lower total cost, an authoring experience their non-technical editors could use without training, and a much larger contractor pool to draw from. WordPress was the pragmatic answer.
Drupal to WordPress is often described as a “downshift,” and that framing causes the trouble. Drupal’s content model is usually richer than WordPress’s out of the box, so the migration is less about moving content and more about deciding how much structure to preserve — and rebuilding the parts WordPress does not do natively.
What broke
The failures were consistent and, in hindsight, obvious.
Entities and fields to post types
Drupal’s entities, content types, and typed fields have no native counterpart in vanilla WordPress, where everything is a post or page with meta. The team that tried to flatten structured Drupal content into the WordPress editor lost the structure that made the content reusable. The fix was to model custom post types and structured fields (via a fields plugin) that mirrored the Drupal model deliberately — not to dump everything into the body.
Views has no equivalent
Every listing, filtered index, and related-content block on the old site was a Drupal View. WordPress has no built-in query builder, so each of those had to be rebuilt as a custom query or a plugin-driven listing. This is the single most underestimated line item in a Drupal exit — the pages that look simple are the ones generated by the most Views logic.
Path aliases and SEO
Drupal’s Pathauto aliases produced clean, stable URLs that had accrued years of ranking and inbound links. WordPress’s permalink structure is different, and the aliases do not transfer automatically. Without a complete 301 map from old aliases to new permalinks, the site would have shed organic traffic at launch. A full redirect map was built from a crawl of the old aliases before cutover.
Modules to plugins — and the gaps
Some contributed modules mapped cleanly to plugins; others had no equivalent, and a few pieces of custom module code had to be rewritten. Multilingual content (a Drupal i18n setup) was the sharpest edge: WordPress handles multilingual through plugins with a different model, and the language structure had to be re-designed rather than imported.
What worked
The migration went smoothly where the team scripted it and staged it. Content moved through WP-CLI and a repeatable import script rather than manual re-entry, so it could be run against staging, checked, and re-run. Structured fields preserved the content model instead of collapsing it. And a short, firm content freeze during final cutover kept the two systems from drifting — the “parallel run that never ends” is a real failure mode, and a hard freeze date avoided it.
Lessons
- Preserve structure on purpose. Map Drupal content types and fields to custom post types and structured fields; do not flatten reusable content into the body editor.
- Budget for Views. Every listing and filtered index is a rebuild. Inventory them early — they are the hidden bulk of the work.
- Redirect the aliases. Crawl the old Pathauto URLs and build a complete 301 map before launch to keep rankings and inbound links.
- Re-design multilingual, do not import it. Drupal i18n and WordPress multilingual plugins use different models; treat it as new design work.
- Script it and freeze it. A repeatable import plus a firm content-freeze date beats manual migration and an open-ended parallel run every time.
Before you make this move
The pre-migration checklist that would have de-risked this project:
- Inventory content types, fields, and every View, and decide the WordPress model before importing anything.
- Crawl the current site for all Pathauto aliases and build the old-to-new redirect map.
- List contributed and custom modules, and confirm plugin equivalents or plan the rewrites.
- Design the multilingual approach explicitly if the site is translated.
- Retire thin and stale content before the move — do not pay to migrate what you should delete.
A pre-migration scan makes the scope concrete: the Drupal-to-WordPress path is where content-model debt, Views-driven pages, and alias redirects hide. Replatform Radar maps that surface for your own site before you commit to a timeline.