Drupal to WordPress: the two things you can't afford to break

In 2011 I helped move The Hill Times off Drupal. It's Canada's Parliament newspaper, and it carried two things that couldn't break: tens of thousands of article URLs that committee documents and policy research had cited by address, and a paying subscriber base that was, in every sense that counts, the business. Both survived. I watched the traffic after launch expecting a cliff, and it never came.

I should say up front that I sell this work, so weigh what follows with that in mind. It's the version I'd give you over coffee, including the parts where I'd tell you to stay put, and it comes with its sources because a migration decision gets defended in a budget meeting, and "a developer told me" doesn't survive one.

In short: move when the staffing, an end-of-life date or the daily publishing friction has already turned against you. Protect two things before anything else: every URL that already exists, and every person who logs in or pays. Expect a few weeks of ranking movement even when you do it right, because Google says so. And mind the calendar: Drupal 10 stops receiving security support on 9 December 2026.

What Drupal does well

Drupal earned its place, and I want to be fair about that before talking about leaving it. You can build content types and fields from the admin screens,¹ permissions hang off roles,² and translation gets a full chapter in the user guide instead of being bolted on.³

WordPress has answers here too: a roles-and-capabilities system⁴ and custom post types, which is the documented way to add content types beyond posts and pages.⁵ The difference I'd defend is where the work lives. In Drupal, modelling a relationship between two kinds of content is mostly a configuration task. In WordPress it's usually code, or a plugin you choose and then maintain. That's my judgement from building on both, and no primary source ranks the two platforms. I'd be suspicious of one that claimed to.

In short: move when the staffing, an end-of-life date or the daily publishing friction has already turned against you.

Hiring is a separate question, and the numbers are lopsided. In W3Techs' October 2026 survey, WordPress runs 40.1% of all websites and 58.6% of those with a known content management system. Drupal runs 0.6% and 0.9%.⁶ A smaller pool is consistent with a Drupal vacancy taking longer to fill, but it doesn't prove a price gap, and I couldn't find a labour-market dataset that does. In my experience Drupal developers cost more and take longer to find, and that's all I'd claim for it.

If your site is a genuinely complex data model with a strict editorial workflow and forty distinct roles, Drupal is doing real work for you, and I'd want a good reason before moving any of it.

Drupal's support dates are already set

Drupal publishes its support schedule in the open.⁷ Drupal 9 reached end of life on 1 November 2023. Drupal 10 follows on 9 December 2026, the same week Drupal 12 is due. I checked those dates on 11 October 2026, which put Drupal 10's end of life eight weeks away, and the schedule page I read doesn't give an end-of-life date for Drupal 11.

Drupal 7 is the instructive case. In February 2022 its end of life was extended to November 2023, and in June 2023 it was moved again, to 5 January 2025, which the Security Team called the final extension.⁸ That announcement also warned that after the date Drupal 7 security issues may be disclosed in public and zero-day attacks may occur.⁸ Paid vendor extended support exists through providers the Drupal Association lists.⁹ It buys you time and patches, and it leaves you on a platform drupal.org itself no longer supports.

The documentation for sites still on Drupal 6 or 7 describes the job as migrating content and configuration into a new site. Themes can't be migrated and have to be rebuilt, and not all contributed modules have automatic upgrade paths.¹⁰ Here's what that means in practice: an "upgrade" from Drupal 7 and a move to WordPress share most of their first steps, which are the audit, the content model and a scripted import. The only question is which platform receives it. If you're sitting on an end-of-life major version today, you're already committed to paying for a migration, and what's left open is which one.

Where it starts to cost you

The pinch usually comes from staffing and rhythm. When a Drupal developer moves on, replacing them takes longer, in my experience, than replacing a WordPress developer would, and while you look, small changes queue behind bigger ones. In most of the Drupal sites I've been called into, the communications team can't publish a landing page without filing a ticket. A site configured that way on any platform would do the same, so I count it as a symptom to check rather than a verdict on Drupal. It is, though, the lived reality that eventually starts the conversation.

The two things you can't afford to break

Most things in a migration can be fixed after launch with an apology and a weekend. These two are very hard to win back, so they get planned first and everything else arranges itself around them.

Every URL that already exists

Addresses decay on their own. Pew Research sampled just under a million pages from the Common Crawl archive across 2013 to 2023, and found that 38% of the pages that existed in 2013 were no longer accessible by October 2023.¹¹ Tim Berners-Lee made the argument for keeping them in 1998: "URIs don't change: people change them."¹² If you've been on Drupal for years, your content is indexed, cited, bookmarked and linked from places you will never fully inventory. On the Hill Times that included House of Commons committee documents. It's like the change-of-address card at the post office: the mail keeps arriving at the old house for years, and somebody has to forward it.

The work is unglamorous. Drupal stores a path alias as its own entity that maps a friendly address to the system path underneath.¹³ Those get extracted and re-created as WordPress rewrites, canonical article URLs are preserved exactly instead of regenerated from whatever permalink structure the new site would have chosen, and tag, author and category archives are mapped pattern for pattern. The inventory goes wider than articles: images and document files that other sites hotlink, feed addresses that partners consume, and pagination. One more thing I'd test on any real site: the same article normally answers at its alias and at its system path, so an inbound link might use either, and a map built from aliases alone would miss the second kind. That's my reading of how the alias entity works, so check your own server logs before you trust it.

Google's guidance for a move is specific. Decide where each old URL should land, and redirect to that exact destination. Use server-side permanent redirects. Keep chains short, ideally no more than three hops and fewer than five. And keep the redirects "for as long as possible, generally at least 1 year."¹⁴ For a news archive I'd treat a year as the floor and plan on permanent, because the archive is the thing other people cite. At tens of thousands of entries, also ask where the redirect map lives. In my judgement it belongs in the web server's configuration, not in a plugin table that PHP walks on every request.

Here's the part nobody likes. Google also says to "expect temporary fluctuation in site ranking during the move," and that for a medium-sized site it can take a few weeks or more for the new URLs to show up gradually.¹⁴ Handled well, the movement is short and recoverable, and it's still real. Anyone who promises you rankings will simply hold is promising more than the search engine does. On the Hill Times there was no cliff in our numbers. In my experience a missed URL pattern shows up in analytics as a step down within days, so I watch the traffic closely after launch. That's one migration, so treat it as a story and not a rate.

Anyone who logs in or pays you

If your Drupal site has accounts, and especially paid ones, that list is the asset. The site is just how people reach it, which is the shape of most of my work with publishers. A naive migration asks everyone to re-register and re-enter a card. I can't give you a percentage lost to that friction, because I couldn't find a study that measures it. Re-entering a card is exactly the step where "I'll do that later" becomes "I never did," and a subscription business can't afford to find out how often.

Passwords are part of the same question. Whether stored passwords can be carried across or every subscriber gets a reset email is something to settle early whichever way it goes, because a reset email to a whole subscriber list is a support wave you'd want to staff for. Access rules deserve the same early look: metered or institutional access, print-subscriber links and anything keyed to an IP range tend to live in custom code, and custom code is the part of a migration that gets rebuilt.

If your payment processor stays the same, most of the work is mapping existing customer and subscription IDs onto the new user records and rebuilding the membership logic. If it changes, the mechanics are public, and Stripe's documentation is the clearest worked example I know. Card numbers never travel through you: a data import is a transfer from your old processor to the new one through a secure, PCI-compliant channel (the card industry's security standard), and Stripe is blunt that you should never send card details to it directly.¹⁵ Stripe says imports typically complete within ten business days of receiving correct data, and warns that the previous processor can take a few days to several weeks to hand it over. That's a dependency outside your control, so it goes on the critical path first.

Stripe names two traps. Confirm your old processor has cancelled automatic billing; the documentation asks for exactly that check, and the risk it guards against is customers being billed by both. And any card change made at the old processor between export and import is lost.¹⁵ Subscriptions are imported as a separate step, and the billing anchor and start date have to reflect the correct mid-cycle term, which is why the documentation recommends schedules you can review before billing begins.¹⁶ Complimentary accounts for staff, board members and journalists who never went through billing come across as WordPress users with the right roles and stay out of the billing flow entirely.

On the Hill Times the tools were those of 2011, and the job had this shape: subscribers' stored payment details moved to the new billing system with subscription state preserved, so nobody was double-charged and nobody skipped a renewal. If your Drupal site is brochureware with no logins, skip this section happily. If it isn't, this is the part that decides whether the project is remembered as a success.

Deadline day, for a publication that files every day

A newsroom doesn't pause for a cutover, so the plan has to say what happens to the story filed at 3:47 on the last afternoon. This is the method I'd use, and it's mine rather than a documented standard. Import everything in a rehearsal, then run a delta import at cutover that picks up what was published or edited since the last full run. Freeze authoring for the shortest window the rehearsal says you need, and tell the desk the exact times in advance. Keep the old site intact and reachable for a period after launch so a rollback is a DNS change and nothing more. And plan for the reporters' side: the authoring screen is different, scheduled publishing, embargoes and corrections need to be checked by someone who files for a living, and the first weeks will be slower than the old system was. Staff for that slower stretch and it won't surprise anyone.

What survives the move

The straightforward part: articles and pages, images and documents, taxonomy structure, authors, publication dates, and most of your content model if someone maps it deliberately rather than hoping an importer guesses right. WordPress has an importer for its own export format, available as a plugin and from the command line, so scripting the load is routine once the content has been reshaped into that format.¹⁷ That reshaping is the real job, and it's where the mapping decisions sit.

The part that needs real work is Views, Drupal's query builder, which has no direct WordPress equivalent in practice, so each one becomes a template or a custom query. Paragraphs, the module that lets editors compose a page from reusable blocks, and complex field structures are the same story: they map onto blocks and custom fields perfectly well, but "map onto" means a person sits down and decides the mapping. The part that usually gets rebuilt is webforms, custom modules, and any workflow built on Drupal-specific contributed modules. Two platforms with genuinely different content models will always split the work this way, and it's the same conversation I have about moving off Moodle.

How each part of a Drupal site travels to WordPress

How it travels	What it covers	What it takes
Moves routinely	Articles and pages, images and documents, taxonomy structure, authors, publication dates, and most of the content model	A scripted load through WordPress's own importer once the content is reshaped. The reshaping and the mapping decisions are the real job
Needs real work	Views, Paragraphs and complex field structures	Each View becomes a template or a custom query. Paragraphs and fields map onto blocks and custom fields, but a person decides the mapping
Usually rebuilt	Webforms, custom modules, and workflows built on Drupal-specific contributed modules	Rebuilt rather than migrated

What the migration looks like in practice

Audit before anyone prices anything. List the content types in the Drupal admin, pull the most-linked URLs from Search Console and your server logs, and count your content by shape, not by page. Twenty thousand articles that are all the same shape is a smaller project than four hundred pages with fifteen different field structures between them. The audit also surfaces what nobody wants to bring along: content types unused since 2016, and sections everyone forgot were published. Deciding what stays behind is one of the cheapest hours in the project, and it's cheapest at the start.

After that, roughly in order: build the content model on the WordPress side, script the content migration and run it against staging until it's boring, build the redirect map alongside the content while every pattern is in front of you, migrate accounts, then rehearse the cutover end to end with real data, and time it. The first time you run it shouldn't be the time that counts. On a large catalogue, Google's guidance allows moving one section at a time, which makes problems easier to spot and fix, while small and medium sites should move everything at once.¹⁴ For a daily publication the live feed and the archive don't separate cleanly, so I'd split the move by content type.

What it costs, honestly

I won't give you one number, because the honest range is wide and anyone quoting a Drupal migration off a page count is guessing. What moves it: how many distinct content shapes you have, whether accounts and payments are in scope, how many URL patterns need mapping, whether a redesign is happening at the same time, and how much of today's functionality lives in custom modules. On the redesign question I'd sequence it separately, for the reasons on the migration service page.

My rule of thumb, and it is only that: expect to rebuild somewhere between a fifth and a third of the functionality rather than migrate it. I count that in features, so a Views-heavy or module-heavy site pushes it up. If you want a number for a budget meeting before hiring anyone, count your content shapes and your URL patterns yourself. They do most of the work in any quote, and having them lets you compare two proposals on the same basis. Then run the three-year test, which is also mine: if the move doesn't pay for itself inside three years through staffing, hosting, or the work your team can finally do without filing a ticket, it's a want rather than a plan.

When staying on Drupal is the right answer

Stay if the content model is complex and in daily use. Thirty interrelated content types with real referential integrity and an approval workflow that matches how your organisation signs things off is work WordPress can do, but you'd be rebuilding something that already works to get there.

Stay if you've just finished a major version upgrade, and check which major you finished. You've paid the expensive part, but a site that landed on Drupal 10 has a security-support date eight weeks out from the day I checked, so "get some good years out of it" depends on the next hop being a small one. I haven't priced that hop here.

Stay if the real complaint is that the admin looks dated. That's a theme problem, and it comes with a much smaller invoice than a migration does. It's also the one reason I'd refuse to take a move on: moving a working site to buy a newer-looking admin screen spends real money on a feeling. The good reasons are the ones in this post, and "it feels old" needs one of them standing behind it.

Move when the staffing arithmetic has turned against you, when an unsupported version is forcing the decision anyway, or when the public side of your site is doing strategic work your own team can't touch without booking a developer.

Common questions about moving off Drupal

Will my URLs really survive? Yes, if URL preservation is written down as a requirement at the start instead of handled in the last week. Every legacy pattern gets mapped, the long tail gets fallback rules, and the most-linked URLs get walked after launch to confirm each one resolves to the same content it used to. That's the approach behind the Hill Times migration.

What happens to our search rankings? Expect movement, and plan for it to be temporary. What you control is the redirects: map every old URL to its new home and keep them in place for generally at least a year. A permanent redirect is the signal that the new address should replace the old one.¹⁸

How long does it take? Longer than the content move suggests, because the content move is the easy half. Let the audit, the redirect map, the account migration and a rehearsed cutover set the schedule; the article count is the wrong clock. If you'd like a realistic timeline for your own catalogue, tell me what you're running and I'll give you a straight answer.

Can we run both systems during the transition? For a period, yes, and it's often calmer. The usual shape is WordPress serving the public site while Drupal keeps running whatever hasn't been rebuilt yet, with the redirect layer in front of both. For a newsroom the awkward part is authoring: a story written in Drupal has to reach the public WordPress site somehow, so that sync is a piece of work to scope.

What's sourced and what's mine

Drupal's support dates, Google's redirect guidance, the Stripe import mechanics and the market-share figures are documented, and each carries its reference below. What I say about the Hill Times is my own account of one migration, not a study. Relative cost, hiring, the fifth-to-a-third rule of thumb, the three-year test, how Drupal's alias system behaves in the wild, where a large redirect map should live and the deadline-day method are my judgement from the work. I looked for a primary dataset on traffic lost to missing redirects and found only agency blog posts, which I haven't cited. I read pages on 11 October 2026, and dates and versions move. If something here is wrong, tell me, and I'll add a dated correction at the foot of the post rather than editing it in silently.

References

1. Drupal.org, Drupal User Guide, "Adding a content type".
2. Drupal.org, Drupal User Guide, "Concept: users, roles, and permissions", April 2025.
3. Drupal.org, Drupal User Guide, "Chapter 10. Making your site multilingual".
4. WordPress.org, Plugin Handbook, "Roles and capabilities", 17 November 2022.
5. WordPress.org, Plugin Handbook, "Registering custom post types", 17 November 2022.
6. W3Techs, Usage statistics and market share of content management systems, snapshot 11 October 2026.
7. Drupal.org, Drupal core release schedule, last updated 27 August 2026. Read 11 October 2026.
8. Drupal Security Team, End of life announcement and changes to Drupal 7 support (PSA-2023-06-07), 7 June 2023.
9. Drupal.org, Drupal 7 end of life. Undated; read 11 October 2026.
10. Drupal.org, Upgrading from Drupal 6 or 7 (overview), Drupal upgrade documentation, last updated 13 January 2025.
11. Chapekis, A., Bestvater, S., Remy, E., and Rivero, G., When online content disappears, Pew Research Center, 17 May 2024.
12. Berners-Lee, T., Cool URIs don't change, W3C, 1998.
13. Drupal.org, Change record: path aliases have been converted to revisionable entities, 1 October 2019.
14. Google Search Central, How to move a site, last updated 20 August 2026. Read 11 October 2026.
15. Stripe Docs, Request a payments data import. Undated; read 11 October 2026.
16. Stripe Docs, Migrate subscriptions to Stripe Billing using Stripe APIs. Undated; read 11 October 2026.
17. WordPress.org, WP-CLI handbook, "wp import".
18. Google Search Central, Redirects and Google Search, last updated 14 April 2026.