Drupal 7 End of Life: Migrating to Current Drupal or WordPress

Drupal 7 stopped receiving security updates on January 5, 2025, after 14 years in service. Many sites still run it. On October 4, 2026, W3Techs counted Drupal 7 on 29.3% of all Drupal websites, nearly level with Drupal 10 at 29.5%. Only 15.4% of those Drupal 7 sites were on 7.103, the final release.

Drupal’s users lean toward large organizations. W3Techs puts Drupal on 0.9% of sites with a known CMS overall but 6.1% of the top 100,000. If your organization still runs Drupal 7, there are two realistic destinations: current Drupal or WordPress. This guide covers what end of life means in practice, the stopgap options Drupal.org lists, what a migration involves on each path, and how to choose between them. It expands the Drupal section of our guide to website platforms you can start without code and extend later.

Drupal 7 end of life: key facts

Question	Answer
When did Drupal 7 reach end of life?	January 5, 2025. The last release, 7.103, came out on December 4, 2024.
What stopped at end of life?	Security advisories covering Drupal 7 core and its contributed modules and themes, plus compatibility updates. Drupal 7 vulnerabilities may now be disclosed publicly with no fix.
Which PHP versions does Drupal 7 support?	Up to PHP 8.3, with Drupal 7.103. PHP 8.4 is not supported.
How many sites still run Drupal 7?	29.3% of Drupal sites and 0.2% of all websites, per W3Techs on October 4, 2026, down from 34.1% of Drupal sites a year earlier.
Can you buy extended support?	Yes. The Drupal Association’s Extended Security Support Provider Program lists two certified vendors, HeroDevs and Tag1 Consulting.
Can Drupal 7 be upgraded in place?	No. Content and configuration are migrated into a new installation of current Drupal.
Which Drupal version should a migration target?	Drupal 11, which Drupal.org expects to support until mid-late 2028. Drupal 12, due the week of December 7, 2026, removes the modules that read Drupal 7 data.
Can you move to WordPress instead?	Yes. Drupal.org’s own Drupal 7 resources name another platform as one of the two options. WordPress has no built-in Drupal importer, so the move is a custom migration or a third-party tool.

What did Drupal 7 end of life change?

The Drupal Security Team set the date in a 2023 public service announcement, PSA-2023-06-07, and called it “the final extension.” The Drupal 7 End of Life page now says Drupal 7 “will no longer receive security updates or compatibility updates.” Here is what those two losses mean in practice.

Security

According to the PSA, once Drupal 7 reached end of life:

• “The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core, contributed modules and themes.”
• “Security issues for Drupal 7 may be disclosed in public, and zero-days (i.e, security vulnerabilities being exploited in the wild without advance warning) may occur.”
• “External vulnerability scans will flag Drupal 7 as insecure.”

Third-party libraries are a separate gap. Even before the end date, the security team said it would not issue advisories “for any unsupported libraries that Drupal 7 contributed modules or themes rely on, such as CKEditor 4.”

PHP compatibility and hosting

Drupal 7’s PHP requirements page lists PHP 8.3 as supported “as of Drupal 7.103” and says PHP 8.4 “will not get support.” With no more compatibility updates, that ceiling is permanent. A Drupal 7 site older than 7.103 isn’t supported on PHP 8.3 at all, and when a host retires PHP 8.3, the site has nowhere newer to move.

Hosting tooling is affected too. The PSA warned that parts of Drush would stop working with Drupal 7, that Drupal.org would stop packaging Drupal 7 archives, and that “Package tarballs may no longer be downloadable.” That makes rebuilding a Drupal 7 server from scratch harder.

Compliance

Drupal.org’s Drupal 7 End of Life page states the compliance risk directly: “Failure to address these issues can put your website out of compliance with FedRAMP, PCI, HIPAA, SOC 2, and other compliance standards.” For organizations that take card payments, handle health data or sell to government, an unsupported CMS can come up in audits and security questionnaires.

What extended support options does Drupal.org list?

Drupal.org lists three ways to stay on Drupal 7 for now. None of them is a permanent answer, but each can buy time for a planned migration.

1. Paid extended security support. The Drupal Association set up the Extended Security Support Provider Program for sites that could not migrate in time. Its Drupal 7 End of Life page names HeroDevs and Tag1 Consulting as “the certified vendors” in the program, and the Migration Resource Center lists both under its D7 Extended Security Support Program category.
2. Community support. The same resource center lists D7Security, describing it as “the home of an unofficial community movement to provide extended support for Drupal 7.” It is not part of the certified program.
3. A communicated plan. If neither migrating nor extended support is possible yet, Drupal.org advises telling “your customers, managers, CISO, or other stakeholders about your plans for handling support and managing potential vulnerabilities.”

Drupal.org’s DIY migration resources also list two projects for teams that want to stay close to Drupal 7 code. Backdrop CMS is “an independent CMS project based on Drupal 7, offering a direct upgrade path.” Retrofit is “a software library that provides a compatibility layer for Drupal 7 code to allow it to run in any modern version of Drupal,” which can help carry custom code across while it is rewritten.

Extended support covers security fixes. It doesn’t rebuild the theme, replace abandoned modules or remove the PHP 8.3 ceiling, so the migration work is still waiting when the contract ends.

How to migrate Drupal 7 to current Drupal

Moving from Drupal 7 to current Drupal is a migration, not an upgrade. Drupal.org’s upgrade overview explains that “an update can’t simply be applied to an existing Drupal 6/7 site.” You install a fresh copy of current Drupal and pull the old site’s data into it with core’s Migrate modules.

What core migrates and what it doesn’t

Core’s migration reads the Drupal 7 database and recreates:

• Configuration: content types, fields and user roles
• Content: nodes, users and taxonomy terms
• Files: public files, plus private files if the new site can reach the old files directory
• URL aliases, through core’s Path module

Drupal.org says core provides “an upgrade path for all modules that were in Drupal 6 core and Drupal 7 core.” Other pieces need manual work:

• Themes. “Drupal 10 (or later) significantly changed how themes are structured. These changes can’t be migrated.” The theme is rebuilt.
• Views. The upgrade approach guide notes that “Views module doesn’t have an automatic upgrade path in core,” so listings, archives and search pages are recreated by hand.
• Contributed modules. “Not all contributed modules have automatic upgrade paths. This may require a manual or custom migration.”
• Custom modules. Drupal 7 module code doesn’t run on current Drupal and has to be rewritten, or bridged temporarily with Retrofit.

User passwords carry over. Drupal 10.1 switched to PHP’s native password hashing, and the change record explains that Migrate Drupal depends on the Password Compatibility module, which still accepts Drupal 7 hashes. Each user’s hash is converted the first time they log in. Redirects stored by Drupal 7’s Redirect module can be brought over with the Redirect project’s Drupal 7 migration.

Why migrate to Drupal 11, not Drupal 10 or 12

Two dates on Drupal.org’s release schedule shape the plan:

• “Drupal 10 will reach end of life on December 9, 2026,” so it is no longer a sensible target, even though some of Drupal.org’s older Drupal 7 pages still name it.
• “Drupal 12 will be released on the week of December 7, 2026.”

Drupal 12 removes the tools Drupal 7 sites depend on. The change record for Migrate Drupal says the module, “which provides source migrations from Drupal 6 and 7, is deprecated in Drupal 11 and will be removed in Drupal 12.” Migrate Drupal UI, the browser-based upgrade screen, is deprecated as of 11.3.0 with “no replacement.” Drupal.org’s deprecated modules page gives the path forward: “Sites that are on Drupal 6 or Drupal 7 that intend to use the migration API to migrate to modern Drupal, can continue to migrate to Drupal 11. Once on Drupal 11, you can then use the regular modern Drupal upgrade system to upgrade to Drupal 12.”

So the route is Drupal 7 to Drupal 11, then a normal major-version update to Drupal 12 later. The same page says “Drupal 11 will be supported until mid-late 2028,” which leaves time for that second step. Drupal 11 requires PHP 8.3 or later, so the old and new sites can share a PHP version during the project.

How a Drupal-to-Drupal migration runs

Drupal.org’s preparation guide sets out the groundwork:

1. List every enabled module and decide whether you still need it, whether it moved into core (as Views did), or whether a current version or alternative exists. The Upgrade Status module can check availability.
2. Update the Drupal 7 site to its latest release first.
3. Give the new site access to the Drupal 7 database and files directory.
4. Install a clean Drupal 11 site with the Migrate modules enabled, and “do not do any configuration of the destination site until after the upgrade process is complete.” The guide calls the Minimal install profile “a common best practice” for this reason.

The upgrade approach guide describes three ways to run it: a single upgrade followed by documented manual steps; an incremental approach, where “migrations are executed again in order to migrate new and updated content” while the old site stays live; and a Drush-based approach that moves configuration through version control and migrates only content into staging and production.

Where Drupal CMS fits

Drupal CMS 2.0, released January 28, 2026, packages current Drupal for marketers and site owners. It is built on Drupal core 11.3, includes the Drupal Canvas visual page builder and site templates, and its announcement says there is “no Drupal knowledge required to get started.”

Drupal CMS is a good fit when the move is also a redesign and editors want a visual builder. Because it installs with its own content types and configuration, it doesn’t match the clean destination site the core upgrade path expects. The preparation guide makes the same point about Drupal’s Standard profile, which “introduces its own configuration that you might not want to use.” In practice that means treating a move to Drupal CMS as a rebuild: set up Drupal CMS, then bring content across with migrations written for its content model.

How to migrate Drupal 7 to WordPress

Drupal.org’s DIY resources give Drupal 7 owners two choices: “You can migrate your site directly from Drupal 7 to Drupal 10, or you can choose another open web platform for managing your website.” WordPress is the most widely used CMS, on 40.2% of all websites according to W3Techs.

WordPress has no built-in Drupal importer. Its Importing Content documentation has a Drupal section, but it points to third-party plugins and write-ups rather than a core tool. Small, simple sites can sometimes use one of those plugins. Sites with many content types, fields or users are better served by a migration written for them: a script that reads the Drupal 7 database and creates WordPress content through WP-CLI or the REST API.

How Drupal concepts map to WordPress

Drupal 7	WordPress
Content types	Posts, pages and custom post types
Fields	Post meta (custom fields) registered by a plugin, or custom blocks
Taxonomy vocabularies and terms	Categories, tags and custom taxonomies
Views	Query Loop blocks in the editor, or custom queries in templates and plugins
Roles and permissions	Roles and capabilities
Contributed and custom modules	Plugins
Themes	Themes (block themes or classic themes)
URL aliases	Permalinks

Planning starts with content structure. A Drupal site with a dozen content types and many fields becomes a WordPress site with custom post types and registered metadata, and that code belongs in a plugin rather than the theme. The Plugin Handbook recommends it: “We recommend that you put custom post types in a plugin rather than a theme. This ensures that user content remains portable even if the theme is changed.” Our guide to where WordPress code belongs explains why.

Content, media and users

WP-CLI has the building blocks for a scripted import. wp post create creates posts, wp media import “Creates attachments from local files or URLs,” and wp user import-csv loads user accounts from a CSV file. The migration script handles the mapping between them: which Drupal node becomes which post, which file becomes which attachment, and which links inside body text need rewriting to new URLs.

Passwords need a decision before launch. Drupal 7 stores password hashes in its own format, prefixed $S$, and WordPress’s wp_check_password() doesn’t recognize them. Since WordPress 6.8, it checks its own bcrypt hashes and older phpass and MD5 hashes. That leaves two options:

• Ask users to reset their passwords after launch. This is simpler, but every account holder has to act.
• Check Drupal 7 hashes with custom code. WordPress’s documentation notes that wp_check_password() “can be overwritten to instead use the other package password hashing algorithm,” and the check_password filter lets a plugin verify a legacy hash at login and save a new WordPress hash. It is the same approach Drupal’s Password Compatibility module takes.

Roles are recreated with WordPress’s roles and capabilities system. WordPress has six default roles, from Super Admin to Subscriber, and a plugin can add more. Map each Drupal role and its permissions to a WordPress role and capabilities before importing users.

Custom modules and themes

Every custom Drupal 7 module becomes a WordPress plugin, rewritten against WordPress’s hooks rather than translated line by line. On a site with a lot of custom code, this can be the largest part of the project, and it is a good time to drop features nobody uses. If you’re using an AI assistant to help rewrite modules as plugins, our guide to using AI to build WordPress plugins safely covers the security rules that code has to follow.

The theme is rebuilt either way. On WordPress, the Theme Handbook says: “Themes control the presentation of content.”

How do you keep old Drupal 7 URLs working?

Changing platforms changes URLs. Drupal 7 serves content at paths like /node/123 plus any aliases editors set, and WordPress builds permalinks its own way. Search rankings and inbound links depend on the old addresses, so every one needs a permanent (301) redirect to its new home.

• On current Drupal, URL aliases come across with core’s migration and existing redirects with the Redirect module, so many old URLs keep working as they are.
• On WordPress, export every Drupal 7 alias and redirect before the move and build a redirect map from old path to new URL. The redirects can live at the web server or in a small plugin that uses wp_safe_redirect().

On either path, test the full list of old URLs on staging before launch and watch for 404 errors in the weeks after it.

Drupal 7 migration: current Drupal vs. WordPress

Part of the site	Current Drupal (Drupal 11)	WordPress
Content types and fields	Recreated automatically by core’s migration	Rebuilt as custom post types and registered metadata in a plugin
Content and taxonomy	Migrated by core	Imported by a custom script or third-party tool
Files and media	Migrated by core	Imported into the media library, with links in content rewritten
Users and roles	Migrated by core	Imported; roles mapped to WordPress roles and capabilities
Passwords	Keep working through Password Compatibility	Reset, or verified by custom code at first login
URL aliases and redirects	Migrated by core and the Redirect module	Rebuilt as a 301 redirect map
Views	Rebuilt manually	Rebuilt as Query Loop blocks, templates or plugin code
Custom modules	Rewritten for Drupal 11	Rewritten as WordPress plugins
Theme	Rebuilt	Rebuilt

Should you move Drupal 7 to Drupal or WordPress?

Both paths involve a new theme and rewritten custom code. The difference is how much of the content model and user base carries over automatically, and what the site needs to do afterward.

Current Drupal is the better fit when:

• The site has many content types, structured fields and relationships between content
• Editorial workflows and permissions are detailed, with many roles
• The site is multilingual; Drupal.org documents a dedicated upgrade path for multilingual Drupal 7 sites
• Many users log in, and you want their passwords to keep working without custom code
• The team already knows Drupal, or wants Drupal CMS and Canvas for editors

WordPress is the better fit when:

• The site is mostly pages, news and blog posts
• Editors want a simpler editing experience, and the site is being redesigned anyway
• Custom code is small, or the features it provides are available as well-maintained plugins (the WordPress.org directory lists more than 70,000)
• The organization wants the most widely used CMS: W3Techs puts WordPress on 58.6% of sites with a known CMS

If the answer isn’t clear, inventory the site first. Counting content types, fields, Views, custom modules and logged-in users shows which path involves less rebuilding.

A Drupal 7 migration checklist

1. Inventory the site: content types and fields, taxonomies, Views, enabled modules (core, contributed and custom), user roles, public and private files, URL aliases, redirects and integrations with other systems.
2. Secure the current site: update to 7.103, and if the migration will take months, arrange extended security support and tell stakeholders the plan.
3. Choose the destination: Drupal 11 (or Drupal CMS) or WordPress.
4. Export URLs: save every alias and redirect so nothing is lost.
5. Build on staging: run the migration, rebuild the theme and custom code, and repeat the content migration as the old site changes.
6. Test: logins, forms, search, permissions, media and every old URL.
7. Launch: freeze content edits, run the final migration, switch DNS and monitor 404 errors.
8. Retire Drupal 7: keep an offline backup of the database and files, and take the old site off the public web.

When to bring in a developer

A Drupal 7 site that has run for a decade may have custom modules, contributed modules that never got a modern version, and URLs other sites still link to. A developer can audit those, estimate the work on each path and handle the parts that can’t be automated: custom code, password handling and redirects.

If WordPress is the right destination, Connor on the Web builds custom WordPress plugins and themes, including plugins that replace custom Drupal modules. Our WordPress category collects related guides. The process and pricing are published, and you can get in touch to talk through your Drupal 7 site.