Drupal 7 reached end of life on 5 January 2025. The Drupal Security Team no longer reviews or fixes it, and contributed modules have stopped releasing Drupal 7 updates. A Drupal 7 site still works the day after end of life, but every new vulnerability found from then on stays open.
What staying on Drupal 7 really costs
- No security fixes. A flaw found in core or a module is public knowledge and stays unpatched.
- An ageing PHP version. Drupal 7 sites often run on PHP 7.4 or older, which stopped getting security fixes in 2022. Hosts are retiring those versions.
- Harder hiring. Fewer developers keep Drupal 7 skills current, so small fixes take longer and cost more.
- Compliance questions. If you handle personal data, running unsupported software is hard to defend in a security review.
The four realistic paths
1. Move to current Drupal (10 or 11)
This is the usual answer for sites that rely on Drupal’s strengths: structured content, user roles, multilingual pages. It is not an in-place upgrade. Drupal 8 and later were rebuilt, so the work is a new build plus a content migration using Drupal’s Migrate API.
What carries over: content, users, taxonomy, files and URLs (with redirects). What is rebuilt: the theme, custom modules and some configuration.
2. Move to Backdrop CMS
Backdrop is a community fork of Drupal 7 with a direct upgrade path and a similar code base. It suits small sites with modest budgets whose modules have Backdrop versions. Check its module list against yours before choosing it.
3. Move to a different platform
If the site is mostly pages and posts, WordPress or a static site may be simpler to run. Content can be exported and imported, but the templates and any custom features are rebuilt from scratch.
4. Buy time with paid extended support
Some companies sell extended security support for Drupal 7. It buys months, not years, and it does not fix the PHP version underneath. Treat it as a bridge to one of the paths above.
How to choose
| If your site has | Usually the best path |
|---|---|
| Complex content, roles or integrations | Drupal 10 or 11 |
| Under 50 pages, few modules, tight budget | Backdrop or a simpler platform |
| A hard deadline before you can migrate | Extended support, with a migration date set |
Planning a Drupal 7 migration
- Audit the site. List enabled modules, custom code, content types, views, integrations and traffic-critical URLs.
- Map each module to its Drupal 10 or 11 equivalent, or decide to drop it.
- Model the content in the new site before moving any of it.
- Run the migration on staging, repeatedly, until a full run is clean.
- Keep every URL working with redirects, so search rankings and old links survive.
- Freeze content briefly, run the final migration, test and switch over.
Most of the risk sits in steps 1 and 2. A clear audit is what turns an open-ended rebuild into a job with a fixed price.
Want this done for you, at one fixed price?
Request a quote