Drupal 10 Support Ends December 9: A Migration Plan for Publishers and Corporate Sites

If your site runs on Drupal 10, security support ends on December 9, 2026, and Drupal will ship no new Drupal 10 releases after that day. You have two sensible moves: upgrade to Drupal 11, or start a Drupal to WordPress migration. Upgrading to Drupal 11 is the shorter path for a site that is healthy and that you still like. A Drupal to WordPress migration is the better path if the real problem is cost, editor pain or a platform your team does not want to keep paying for. A move started today will probably finish after the deadline, so the plan below covers the weeks in between as well as the move itself.

This is written for the person who has to make the call: a head of digital, a CTO, an editor-in-chief or a marketing director who just got a note from the web team. It is not a developer tutorial. It tells you what the date means, how to decide between staying and leaving, what a Drupal to WordPress move involves for a publisher or a corporate site, and what to do in the gap. If you only want the calendar of other end-of-life dates that land in the same month, we already published that in our open-source maintenance calendar, and we do not repeat it here.

What exactly happens on December 9?

Drupal publishes its own schedule, and we read it for this article. It says: “Drupal 10 will reach end of life on December 9, 2026.” The last minor release of the line is 10.6.0. Security support for 10.6.x ends in the same week, in the week of December 7. After that date there are no new Drupal 10 releases (Drupal core release schedule).

Your site does not stop working on December 10. It keeps serving pages. What changes is that a security problem found next month in Drupal 10 code will not get an official fix for Drupal 10. Attackers can study the fixes shipped for supported versions, so an unsupported version slowly becomes the easy target.

There is a precedent on the same page. It states that Drupal 7 is end of life and that support ended on January 5, 2025. Plenty of organisations still run Drupal 7 today. That is exactly the situation to avoid, and the cost of getting there is a site that nobody wants to touch.

One more fact helps with planning. The same schedule lists Drupal 11.0.0 as released on August 2, 2024, and shows Drupal 11 still receiving releases. We did not find an end-of-life date for Drupal 11 on that page, so we do not quote one.

Who needs to act, and how fast?

Not everyone has the same problem. Sort your sites into three groups.

Group one: sites already on Drupal 11. Nothing happens on December 9 for you. Keep up with minor releases, because each minor version has its own security window, listed on the same schedule page.

Group two: sites on Drupal 10 that are small, current and well kept. The upgrade to Drupal 11 is usually the shorter path. Drupal publishes a guide for the Drupal 10 to 11 upgrade, though how smooth it is depends on your custom modules and contributed modules.

Group three: sites on Drupal 10 that carry heavy custom code, a pile of modules that are not ready for Drupal 11, or an editor team that has quietly stopped using the CMS. This is where a move to a new platform deserves a serious look. The deadline gives you a reason to decide, but it should not be the only reason.

A quick way to tell which group a site is in: ask your developers one question. “If we upgraded to Drupal 11 next week, what would break?” A confident, short answer means group two. A long silence, or a list of modules nobody can name an owner for, means group three.

Should you upgrade to Drupal 11 or move to WordPress?

Be honest about both options. We build on WordPress, so you should treat our view as one side of the table, and we will give the other side its due.

The case for staying on Drupal and upgrading

Drupal 11 is a living, supported release line. If your site uses Drupal features that you rely on every day, such as complex content access rules, a heavily customised editorial workflow or a large multilingual setup that is working well, an upgrade keeps all of that intact. The people who built your site understand it. The risk is lower than a platform change, and the cost is usually lower too.

There is one requirement to check first. Drupal’s own PHP requirements page says Drupal 10 requires at least PHP 8.1, and its support table lists Drupal 11 as working on PHP 8.3 and 8.4, not on 8.1 or 8.2 (Drupal PHP requirements). So a Drupal 11 upgrade is also a server upgrade. If your hosting contract, your other applications or your security team slow down a PHP change, count that time in.

The case for a Drupal to WordPress migration

The reasons we hear from publishers and corporate teams are practical and rarely about code.

• Editors. The people who publish all day want a calm editor, fast media handling and a screen they do not have to be trained on again every year. Many new hires have used the WordPress editor before, so training is shorter.
• Hiring and agency choice. The pool of people who can build on WordPress is far larger than the pool for most other CMSs. That matters when your lead developer leaves.
• Cost of change. A platform with a large plugin and theme market means many requests are a configuration job, not a development project.
• One platform across many sites. If your group runs Drupal for one brand and something else for the next, a move can be the moment to consolidate. We cover that in a separate piece on corporate blog networks.

Our broader comparison of the platforms is in WordPress vs Joomla vs Drupal. It is the better read if you are weighing the platforms themselves rather than planning a move.

The case against moving right now

Moving is not free, and a deadline is a bad reason to rush. If your site depends on a Drupal-only capability that has no clean equivalent in WordPress, say so early and decide with open eyes. If your content model is large and unusual, the mapping work is real work. And if your team has no capacity for a cutover before the end of the year, an upgrade to Drupal 11 now, followed by a calm migration decision next year, can be the wiser sequence.

That sequence is not a failure. It is a plan with a bridge in it.

What does a Drupal to WordPress migration involve, step by step?

Here is the Drupal to WordPress migration work in the order it happens. This is the shape of our own migration service, described on our WordPress migration page. That page lists Drupal among the sources we migrate from, and it splits a project into three phases: audit and map, migrate and stage, then cutover and monitor.

Step 1: Audit what you really have

Most Drupal sites that are ten years old have more content types than anyone remembers. The audit lists every content type, every field, every taxonomy vocabulary, every user role and every URL pattern. It also lists what to leave behind. The old press-release type used by one campaign in 2017 does not need to come with you.

For a publisher, the audit also counts the archive: how many articles, how many have images, how many have broken media, how many authors, and how many old URLs still get traffic. The traffic part decides how much care each redirect deserves.

Our service page puts this phase at one to two weeks and says it ends in a fixed-price quote. For a very large archive the audit itself is a project, so ask for the scope in writing before the work begins.

Step 2: Map the content model

This is the heart of the move. Drupal stores structured content in entities with fields. WordPress stores it as posts, pages, custom post types, taxonomies and custom fields. The mapping document says, for each Drupal field, where the data lands in WordPress.

Some examples of how the mapping reads:

• A Drupal “Article” content type becomes the WordPress post type for posts.
• A Drupal “Event” type with date and venue fields becomes a custom post type with matching custom fields.
• A taxonomy vocabulary becomes a WordPress taxonomy.
• An entity reference field, for example an article pointing to an author profile, becomes a stored relationship that the new site reads back.
• A Drupal paragraph or layout field becomes blocks in the WordPress editor, or structured fields if the layout is really data.

The mapping step is where you decide whether the new site should copy the old structure or fix it. Copying is safer for the first release. Fixing is cheaper over five years. A good migration partner will tell you which one fits your risk appetite.

Step 3: Build the importer

WordPress has a documented import path. It reads a WXR file, a WordPress-format export, through the WordPress importer, and the WP-CLI command wp import gives a command-line version of it (WordPress import documentation and wp import). The same documentation page says “Many resources are available to help you migrate content from Drupal to WordPress” and points to third-party plugins and SQL guides. It does not list a built-in Drupal importer. We read that page to be sure, and we recommend you read it too before anyone tells you there is a one-click button.

For a small site, a plugin may be enough. For a publisher with a deep archive, custom fields and years of editorial habits, we write the importer for the job. It reads from the Drupal database or its exports and writes into WordPress through the same functions the WordPress editor uses, so that revisions, slugs, authors and media all behave normally afterwards. We describe this approach with real examples further down.

Two properties of a good importer matter more than speed:

1. It can run again. You never import once. You import on day one for a test, again after mapping fixes, and once more at cutover. If the importer cannot run repeatedly without creating duplicates, every run is a risk.
2. It reports what it skipped. An import that says “done” while quietly dropping 400 records is worse than one that fails loudly. The report should list counts per content type, source against destination.

Step 4: Move media, authors and users

Media is where migrations slow down. A Drupal site often stores files in public and private folders with its own naming, and the media library may use media entities with their own metadata. The importer copies the files, rebuilds the metadata (alt text, captions, credits) and rewrites every reference inside article bodies to the new location. The WP-CLI import command has options for author mapping and for skipping image resizing during a bulk run, which matters when you load tens of thousands of files.

Authors need a decision. Do the old editors become WordPress users with logins, or do they become author profiles without logins? For a news site, every byline needs a stable author page. For a corporate site, many authors left years ago, and creating a login for each is a waste. Make this choice once and write it down.

If you have members or subscribers in Drupal, treat them as a separate project with a privacy review. Passwords are stored as hashes, and whether they can be carried over depends on the hashing method. Plan a reset email as the fallback and tell your users before it happens.

Step 5: Build the URL map and redirects

Every old URL that ever earned a link needs to land on the right new page. This is the step that decides whether your search traffic survives. Our service page promises a redirect map covering every old URL, validated against the old sitemap and tested before cutover.

Drupal sites often carry URL patterns made by a path-alias module, plus legacy paths like /node/1234 that still resolve. Both need handling. We also keep the old taxonomy and author URLs in mind, because search engines index those pages too.

If the new site keeps the same URL structure, the redirect list is short. If the structure changes, the list is long and each line needs a check. A large publisher should treat redirects as a data set to be tested in bulk, not a list to be typed by hand. We go deeper on this in our piece on moving a news portal without losing search traffic.

Step 6: Stage, test, then cut over

The new site lives on a staging address while editors review it. Test with real content, not samples. Ask the editors to publish, schedule, edit and unpublish an article. Check search, forms, newsletters, analytics and ad tags. Our service page says the redirects are tested against live URLs and that staging sign-off comes before cutover.

Cutover happens in a low-traffic window, with a rehearsed way back. After cutover, the site needs close watching. The service page lists 30 days of Search Console, Core Web Vitals and error log monitoring, and fixes for issues flagged in that window within the migration scope.

Step 7: Delta sync for the last day

While you build, the old site keeps publishing. An editor posts forty articles during the three weeks of the build. A delta sync copies only what changed since the last run, so that the final import before cutover takes minutes, not hours, and nothing published in the meantime goes missing. Plan a short content freeze at the very end if the numbers are high.

How long will it take, and what do you do before it ends?

Our migration page states the audit as one to two weeks and the migrate-and-stage phase as two to six weeks depending on content volume. Cutover and monitoring come after that. Add them up and a project that starts in mid-November will most likely cross December 9 before it finishes. The holiday period, with its thin staffing and frozen change windows, makes it tighter.

That is the honest answer, and it is useful, because it tells you to run two tracks at the same time.

Track one: reduce the risk on the old site

Until the new site is live, the Drupal 10 site still has to be defended. You can do the following:

• Update to Drupal 10.6, the last minor release, if you are not on it. Apply every security update released up to the end date.
• Put the admin area behind a second layer, such as a VPN or an IP allow-list, so fewer people can even reach the login page.
• Turn on a web application firewall and rate limiting in front of the site. A firewall does not fix an unpatched hole, but it blocks a lot of the automated attacks that go looking for known ones.
• Remove modules you do not use. Every enabled module is attack surface.
• Check backups by restoring one. A backup that has never been restored is a hope, not a plan.
• Write down who is on call over the holidays.

None of this makes an unsupported platform safe. It buys time for a controlled move.

We did not look for paid extended support offers for Drupal 10 from third parties, and we found none on drupal.org’s schedule page, so we cannot tell you whether any exist or what they cost. If you are considering one, ask the vendor for the scope in writing, including what they promise to patch and for how long.

Track two: run the migration properly

Start the audit now. Fix the scope and the budget while the audit runs. Decide whether you copy the old structure or fix it. Pick the cutover window with the editors, not around them.

If the timing cannot work, consider a two-step plan: upgrade to Drupal 11 as a bridge so you are supported again, then migrate on a calendar that suits the business. It is more total work. It is also less risk, and the bridge may be a smaller job than it sounds if your site is in good shape.

What should a publisher check that a corporate site can skip?

Publishers carry extra weight in a move, and it is worth listing what changes.

• Archive size. Hundreds of thousands of articles need batching, resume support and a verified count. At that size, every list page, every admin screen and every export must be paginated and indexed, or the new site gets slower the day it launches.
• Search visibility and news features. Structured data, news sitemaps and author pages all have to survive. We cover these in our piece on moving a news portal to WordPress.
• Editorial workflow. Drupal sites often have custom states such as draft, review, approved and scheduled. WordPress core has fewer states, so workflow plugins or small custom code fill the gap, and the roles need mapping.
• Ad stack and tracking. Ad tags, consent tools, analytics and paywall scripts must be re-tested on the new templates.

For a corporate site, the heavy items are usually different: forms that feed a CRM, single sign-on for staff, multiple languages, legal pages that must not change wording, and brand templates that must match exactly. Make the list yours before you ask for a quote.

What does it cost, and how do you compare quotes?

We are not going to print a number here, because a number without your content volume, your integrations and your calendar is a guess. What you can do is compare quotes on the same items.

Ask every vendor to state, in writing:

1. What is migrated: content types, fields, media, users, comments, redirects.
2. What is not migrated, and why.
3. How many test imports are included, and who signs off on each.
4. How redirects are built and tested, and against what list.
5. What the monitoring period is after launch, and what fixes it covers.
6. Whether the quote is fixed or hourly, and what changes it.

Our own page says we give a fixed-price quote within 48 hours of a free discovery call, after the audit has defined the work. A quote that arrives before anyone has looked at your site is a number for a different site.

Proof that we build importers, not just plan them

A migration lives or dies on the importer, so here is what we have built and shipped, all documented in public:

• We wrote a free importer that moves a forum from bbPress to Jetonomy, with posts, members and search traffic kept. The write-up is Moving Off bbPress Without Losing Your Community.
• We built the path from LearnDash to Learnomy, which moves courses, quizzes, enrolments and progress dates, and we say plainly in Migrate From LearnDash to Learnomy what it leaves behind.
• We also cover leaving Magento for the store owners who face a similar choice.

Those are different source systems, and the pattern is the same each time: map first, write a repeatable importer, report the counts, test on staging, then cut over. We will not claim that a Drupal importer already exists on a shelf. Each Drupal site is different enough that the importer is written for the site.

A decision checklist for this week

Print this and take it to your next meeting.

1. List every Drupal site you own, with its Drupal version and its PHP version.
2. Mark each as group one, two or three from the section above.
3. For each group-two or group-three site, write the single biggest thing that would break in an upgrade to Drupal 11.
4. Ask your host whether PHP 8.3 or later is available for the Drupal 11 route.
5. Decide whether you are upgrading, moving, or bridging, one site at a time.
6. Start the audit for any site that is moving. Do not wait for the budget cycle to finish, since the audit is what produces the budget.
7. Assign an owner for the old site’s defence from now until the day it is switched off.
8. Pick a cutover window that avoids your own busiest weeks, and tell the editors now.

Questions people ask

When does Drupal 10 end of life?

December 9, 2026, according to Drupal’s own core release schedule. Drupal 10.6.0 is the final minor release, and security support for 10.6.x ends in the week of December 7.

Is Drupal 10 safe to use after December 9?

It will keep running, but it will no longer get new releases, so any new security problem will not receive an official Drupal 10 fix. Treat it as a short-term situation to be closed, not a place to stay.

What PHP version does Drupal 11 need?

On Drupal’s PHP requirements page, Drupal 11 is listed as supported on PHP 8.3 and 8.4, and not on 8.1 or 8.2. Drupal 10 requires at least PHP 8.1.

Is there a one-click Drupal to WordPress migration tool?

WordPress’s own import documentation lists no built-in Drupal importer. It points to third-party plugins and SQL guides, which can work for a small site. A site with a large archive, custom fields and relationships usually needs a purpose-built importer.

Will I lose my search traffic?

A Drupal to WordPress migration keeps your search traffic if the redirect map is complete and tested, structured data and titles are carried over, and the first weeks are monitored. These are the controls that protect traffic, and they are why the audit comes first.

Can we upgrade to Drupal 11 first and migrate later?

Yes. It costs more in total work and carries less risk in the short term. It is a good option when the deadline is closer than the migration can safely finish.

The next step

If you run Drupal 10 and you are not sure which group you are in, start with a short conversation. Tell us how many sites you have, how big the archive is and which integrations matter, and we will tell you honestly whether an upgrade or a move makes more sense, then scope the audit. You can read how we run these projects on our WordPress migration service page and book a free discovery call from there.