Drupal 7 end of life arrived on 5 January 2025, after several extensions of the original date. Since then the project has issued no security updates for Drupal 7 core or for the contributed modules that most Drupal 7 sites depend on. This guide sets out the four options that actually exist, including the two that involve keeping Drupal, and how to work out which one applies to your site.
What Drupal 7 end of life changed, precisely
Before the date, a disclosed vulnerability in core or a widely used module produced a patch you applied. After it, disclosure still happens and the patch does not.
That asymmetry is the whole problem. Vulnerabilities continue to be found and published in contributed modules that Drupal 7 sites run, and the information is public. Automated scanners identify unpatched Drupal installs efficiently, because the version is usually detectable from the outside.
What this does not mean is that your site is compromised or that it will stop working. Drupal 7 sites keep running indefinitely; the software does not expire. The exposure is cumulative, and it matters in proportion to what the site holds and who relies on it. A departmental brochure site and a site holding member records are not in the same position, and treating them identically leads to either wasted money or misplaced calm.
Option one: paid extended security support
A small number of vendors sell continued Drupal 7 patching commercially, and the Drupal Association lists the certified ones rather than leaving you to guess.
This is a real option and it is frequently the right one for organisations that cannot move on someone else’s timetable: a public body mid-budget-cycle, a site scheduled for replacement next year anyway, a team without the capacity to run a migration this quarter.
Understand what you are buying. It is time, not a solution, and the price recurs annually while the platform underneath continues to age and the pool of people who can work on it continues to shrink. Buy it with a replacement date already chosen, or you will buy it again indefinitely.
Option two: rebuild in modern Drupal
Modern Drupal is a genuinely different system from Drupal 7. The architecture changed, so this is a rebuild with content migration rather than an upgrade in the ordinary sense.
It is the right answer when your content model is genuinely complex, when you have Drupal capability in-house or a Drupal partner you trust, and when the things Drupal does well are things you actually use: structured content, granular permissions, multilingual done properly.
The cost is real and the market for it skews enterprise, so quotes tend to reflect enterprise engagements. If your Drupal 7 site is four content types and a contact form, you are not that customer, and a quote shaped for that customer will look absurd against what your site is worth.
Option three: move to a different platform
Once option two is on the table, the comparison changes shape, because a rebuild is a rebuild wherever it lands.
That is the reasoning behind a pattern visible in the data: when Drupal 7 sites moved, far more of them went to WordPress than to modern Drupal. The logic is not that one platform is better in the abstract. It is that an organisation already paying rebuild costs asks which system its own people can publish in afterwards, and for a marketing or association site that answer is often not Drupal.
Nodes, fields, taxonomy and users export cleanly, so content is the tractable part. Views, contributed modules and every URL are the work. If you are weighing this, our Drupal to WordPress migration page sets out what is involved and, importantly, who it is not for, and what actually breaks in a migration covers the risks to price in before you commit.
Option four: retire the site
Worth asking directly, because Drupal 7 sites are old enough that some no longer earn their maintenance.
If the site exists because it has always existed, if nobody has published to it in two years, and if the business it serves now runs elsewhere, then a small static replacement retires the risk permanently and costs less than any of the options above. A content management system nobody manages content in is pure liability.
How to tell which one is yours
- Establish exposure honestly. Does the site take payments, hold personal data, or authenticate users? If yes, the clock is faster and option one becomes a bridge rather than a plan.
- Inventory your modules. Which are contributed, which are custom, and which does anyone still use? Unused modules removed now reduce surface immediately, whatever you decide next.
- Ask who publishes to it. If content is edited weekly by non-technical staff, their fluency should drive the platform choice more than any technical comparison.
- Pull the address list and the traffic. Meaningful search traffic means a redirect plan is mandatory in options two and three. No traffic means you have more freedom than you think.
- Fix a date. Any of the four is defensible. Drift is not, and drift is what actually happens to sites in this position.
Drupal’s own Drupal 7 end of life resources are the primary reference, including the current list of certified extended-support vendors and migration partners.
The honest summary
Drupal 7 end of life is not an emergency for most sites and it is not something to keep deferring either. The failure mode we see is neither panic nor neglect exactly; it is a site that stays on Drupal 7 for another two years because no one owned the decision, and then moves in a hurry after an incident, which costs more and goes worse.
If you want help working out which option fits, start a diagnosis. You will get the answer in writing, including when it is that you should buy extended support and revisit next year, or stay on Drupal entirely. Our published scope shows where we draw the line, and the wider migration overview covers the process if you do decide to move.