Still Running Drupal 7? Here's Why That's Now a Real Problem
If your website is still running on Drupal 7, the clock didn't just start ticking — it ran out. Drupal 7 reached its final, official end-of-life on 5 January 2025. After more than a decade of extensions, the Drupal community has stopped issuing security updates, bug fixes, or support for Drupal 7 core and its contributed modules entirely.
That doesn't mean your site falls over overnight. It means every day it stays on Drupal 7, it becomes a slightly bigger risk: no security patches, no compatibility fixes, and a shrinking pool of developers who still work in it. If your organisation handles any kind of sensitive data, or needs to meet standards like PCI, HIPAA, or SOC 2, an unsupported CMS is now a compliance problem, not just a technical one.
The good news: the destination is clear. Drupal 11 is the current, actively developed release, built on a modern architecture that's faster, more secure, and considerably nicer to work with than Drupal 7 ever was. The bad news, if you can call it that: getting there isn't a simple "upgrade" — it's a migration, and it's worth understanding why before you start.
Why this is a migration, not an upgrade
Drupal 7 and Drupal 11 don't share a codebase. Somewhere around Drupal 8, the whole platform was rebuilt on the Symfony framework, with a completely different way of handling configuration, theming, and modules. There's no "click update" path from 7 to 11 — content, configuration, and custom functionality all have to be deliberately moved across using Drupal's Migrate API, then rebuilt or reconfigured on the new platform.
That's worth planning for as its own project with its own budget and timeline, not a quick tidy-up task squeezed into an afternoon.
A few tips if you're starting to plan a migration
1. Audit before you touch anything. List out your content types, active modules, and any custom code first. This tells you what actually needs to move, and flags early which parts will need extra attention.
2. Don't assume every module has a like-for-like replacement. Many Drupal 7 contributed modules were never ported forward, either because their functionality was folded into core, or because nobody maintained a Drupal 9/10/11 version. Some functionality may need to be rebuilt rather than reinstalled.
3. Test the content migration on a staging site first. Never run a first-attempt migration against a live production site. Migrate to a staging environment, check the results properly — including edge cases like unusual content types or old embedded media — before going anywhere near production. We have found DDEV a very useful tool to run test sites in local containers.
4. Treat it as a chance to modernise, not just relocate. A forced migration is a rare opportunity to also refresh a tired theme, tidy up years of content debt, and rethink the site's structure — rather than rebuilding the same 2013-era layout on newer plumbing.
5. Skip Drupal 10 if you're only just starting now. Drupal 10 itself reaches end-of-life around the same window as Drupal 12's release. If you're migrating from Drupal 7 today, there's little reason to land on an intermediate version — go straight to Drupal 11.
6. Back up everything, and know your rollback plan. Standard advice, but worth repeating for anything this size: a clear rollback plan turns a stressful migration into a manageable one.
7. Consider a phased rollout for larger or more complex sites. Migrating everything in one go isn't always realistic. Breaking the migration into stages — content first, then custom functionality, then integrations — can reduce risk considerably.
Where to go from here
None of this means a Drupal 7 migration has to be painful. With the right planning — a proper audit, realistic scoping, and a tested migration path — it's very achievable, and it's a genuine opportunity to end up with a faster, more secure, and easier-to-maintain site than the one you started with.
If you're weighing up what a Drupal 7 to Drupal 11 migration would involve for your own site, it's worth getting a proper scoping conversation in before committing to a timeline or budget.