Nobody here is real. This is a composite, stitched together from the mid-market replatforming projects we watch over and over until the patterns start finishing each other's sentences. So don't go hunting for the org described below (you won't find it, because it's a bit of everyone). The numbers are typical ranges, not one company's actual spreadsheet.
Somewhere in a planning meeting, someone says it with a little shrug of relief: "It's only Drupal to WordPress, so we're stepping down to something simpler." Everyone at the table nods. The budget gets a bit smaller. Somebody pencils in a launch date, and it feels earned.
That word, downshift, is what nagged at me. Every project I saw wearing it was the one limping across the line with traffic bleeding and editors furious, and I wanted to know why the easy move kept turning hard. So I went and looked at one honestly: a mid-market membership org on an end-of-life Drupal, a few thousand articles, dozens of custom fields, and one long-tenured developer who was the only human alive who understood the module stack. WordPress really was the right destination. The trouble started the moment anyone believed it would be simple.
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.
So here's what I actually think. WordPress was the correct call for this organization, full stop. Cheaper to run, an editor experience their non-technical people could touch without a two-day course, and a contractor pool ten times the size. I would make the same move again. What I would never do again is let anyone at the table say the word downshift, because Drupal's content model is usually the richer one, and pretending otherwise is how you end up flattening reusable content into a body field and rebuilding every listing at two in the morning. Treat it as a rebuild of the parts WordPress doesn't do natively, script the import, freeze the content, and map every alias before you promise a date.
The shrug of relief in that planning meeting is the tell. Anytime a migration sounds like stepping down to something easy, that's exactly where the content-model debt, the Views-driven pages, and the redirects you forgot about are hiding. The Drupal-to-WordPress path is thick with these, and Replatform Radar maps them for your own site before you commit to a timeline.