Drupal 7 is over: options for the small business still running it

If your website still runs on Drupal 7, this article is for you - and the timing matters more than it might feel like it does. Drupal 7 reached its official end of life at the start of 2025, yet an enormous number of sites are still running it in 2026, quietly accumulating risk. This is an honest guide to your situation: why staying put is a growing problem, what your real options are, and how to choose between them based on what your site actually is rather than what it was built with.

What "end of life" actually means

End of life is not a marketing nudge to upgrade; it is a hard technical line. It means the Drupal project no longer provides official security fixes for Drupal 7 core. It also means the contributed modules many Drupal 7 sites depend on continue to have new vulnerabilities disclosed - by various accounts on the order of a few each month in popular modules - with no official patch path. In practice, a Drupal 7 site is running software that is no longer being repaired while the world keeps finding new holes in it. That gap only widens with time.

Why so many sites are still on it

The reason tens of thousands of Drupal 7 sites are still live is understandable. They work. They were often built years ago by a developer who has since moved on. Moving off is known to be a big job, so it keeps getting postponed. And nothing appears to be wrong - which is exactly the trap, because an unpatched site looks identical to a safe one right up until it is exploited. Inertia is powerful, but on end-of-life software it is also expensive, because the risk compounds quietly in the background.

The compliance dimension

For any business that answers to a security or data-protection framework, there is a second problem beyond the technical one. Running unpatched, end-of-life software is commonly treated as a failing control in its own right - a box that cannot be ticked - regardless of whether an incident has actually happened. So a Drupal 7 site can be a liability on paper as well as in practice, and that paper liability can surface at awkward moments: an audit, a partner's security questionnaire, an insurance renewal. The clock is not only technical.

The one thing to understand first: there is no simple upgrade

Before weighing options, absorb the fact that shapes all of them: you cannot simply upgrade Drupal 7 to the current Drupal. The architecture changed so fundamentally between Drupal 7 and Drupal 8 (and onward to 10 and 11) that moving is effectively a rebuild - the content is migrated, but the site is built anew. This is why "just update it" is not on the menu, and why the real choice is between different kinds of rebuild rather than between upgrading and moving. Once that lands, the options make sense.

Option one: rebuild in current Drupal

The first option is to rebuild on current Drupal (10 or 11). This is the right choice if your site genuinely uses Drupal's strengths - a complex content model, serious scale, specific integrations, or a team that works in Drupal daily. It keeps your investment in Drupal expertise and capability. The trade-offs are cost and continuity: agency-led Drupal 7 to current-Drupal migrations commonly start around eight thousand dollars and rise from there, and you remain on the Drupal upgrade treadmill, facing the next major migration in due course. For a true Drupal application, that can still be the best answer. For a business brochure site, it is a lot of cost and complexity to stay in the same place.

Option two: move to WordPress

The second option is to rebuild on WordPress, which is a common landing spot for former Drupal sites. It is a step down in complexity and a step up in the size of the community and the pool of available help. The honest caveat is that WordPress brings its own well-known burden: a plugin ecosystem that is the source of the great majority of WordPress security incidents, and an ongoing need for updates, maintenance and hardening. You would be trading Drupal's end-of-life risk for WordPress's maintenance-and-plugins risk - a different problem, not the absence of one. Our guide to why WordPress sites get hacked is worth reading before choosing this path.

Option three: move to a managed platform

The third option is to move to a managed platform, which suits the large number of Drupal 7 sites that are really business websites rather than web applications. Here you get out of the rebuild-and-maintain cycle entirely: security, updates, backups and hosting are handled for you, the site is easy to edit yourself, and it is genuinely yours to export at any time. For a brochure-style site that never needed Drupal's power, this is usually both the calmest and the cheapest long-term answer, because there is no next migration to budget for and no maintenance burden to carry. The platform overview sets out what is included.

How to choose between them

The deciding question is simple: what is your site, really? If it is a genuine application - complex content, real scale, Drupal-specific integrations - rebuilding in Drupal may be justified. If it is a business website that happens to sit on Drupal, then either WordPress or a managed platform will serve you better, and the choice between those two comes down to whether you want to take on maintenance yourself (WordPress) or have it handled (managed platform). Most small-business Drupal 7 sites fall squarely in the second camp, which is why, for them, the managed route tends to win.

Preserving your URLs and rankings

Whichever option you choose, protecting your search visibility is essential and entirely doable. A careful migration preserves your web addresses where possible and puts permanent (301) redirects in place where an address must change, so the rankings and inbound links you have built over years carry across to the new site. Your content and metadata come with you. A rebuild does not have to mean starting from zero in the eyes of search engines - only a careless one does.

What if you have lost access?

Drupal 7 sites are especially prone to the "we have lost the login and the developer" problem - they are old, and the people who built them have often moved on. This does not block a move. With your written authorisation, your content can be captured from your live, public site - every page, your images, your structure - so a forgotten password and a vanished developer are not the dead end they seem. An ageing Drupal 7 site that nobody can log into is still perfectly moveable.

The cost comparison, honestly

Cost is often what keeps people frozen, so it helps to compare like with like. A Drupal rebuild is the most expensive route, commonly starting around eight thousand dollars for agency work and continuing to cost through future upgrades. A WordPress rebuild is typically cheaper up front but carries ongoing maintenance and security costs. A managed platform folds hosting, security and upkeep into one predictable fee and removes the future-rebuild cost entirely. For a business website, the managed route is frequently the cheapest over the life of the site as well as the least stressful.

Do not wait for an incident

The strongest argument against "leave it until it breaks" is what "breaks" looks like on an end-of-life site: a compromise brings cleanup costs, downtime, possible data exposure with its legal obligations, and search-ranking damage - the expensive, stressful version of a move you could have made calmly. Moving now, on your own timing, is the cheap and controlled option. Moving after an incident is the costly, forced one. The best time to leave Drupal 7 was at its end of life; the second best time is before the incident that would otherwise decide it for you.

A realistic timeline

For a typical small-business Drupal 7 site, a move takes a matter of weeks rather than months, and your existing site stays live throughout so there is no gap. The bulk of the work - capturing content, rebuilding on the new platform, setting up redirects, testing - happens in the background while you carry on as normal. The only moment you actively take part is the sign-off before go-live. It is a bounded, scheduled project, not the open-ended ordeal a stuck site can make it feel.

Who should stay on Drupal

To be fair to Drupal: if your site is a genuine application that uses its power - a complex content model, real scale, integrations that depend on Drupal specifically, or a team fluent in it - then rebuilding in current Drupal is a legitimate choice, and moving to a simpler platform would cost you capability. The managed-platform route is for the very large number of Drupal 7 sites that are business websites in enterprise clothing, not for the minority that are true Drupal applications. An honest audit will tell you which yours is.

The security reality on an unpatched site

It is worth being concrete about what running end-of-life Drupal exposes you to. Automated scanners crawl the web looking for known-vulnerable software, and an unpatched Drupal 7 site with unpatched modules is exactly what they are built to find. The danger is not that someone is personally targeting you; it is that the whole internet is being swept continuously, and a site with published, unfixed vulnerabilities is a soft target for that sweep. Every month that passes adds newly-disclosed module vulnerabilities with no patch, so the exposure grows rather than holds steady. This is the quiet cost of "it still works."

What migrating your content involves

People imagine migration as a terrifying black box, so it helps to demystify it. In essence, your existing content - pages, articles, images, structured fields - is extracted and mapped onto the new platform's structure, and your addresses are preserved or redirected so search engines follow you across. On a managed move, much of this is done for you from your live site. It is careful work rather than magic, but it is well-trodden: former Drupal 7 sites are migrated all the time, and the content that took years to build is exactly what comes across.

Which features carry over

A fair question is what happens to the functionality your Drupal site provides. Basic content - pages, news, galleries, contact forms - maps cleanly onto any modern platform. More specialised Drupal modules may have a direct equivalent on the new platform, a built-in feature that replaces them, or occasionally something that needs rethinking. Part of a good assessment is exactly this inventory: what your site does today, and how each capability is provided after the move. For most business sites the answer is reassuring; for genuine applications it is where the real planning goes.

Design: a chance to modernise

Many Drupal 7 sites look their age, because their design dates from when they were built. A migration is a natural moment to refresh that - not because the content is lacking, but because presentation standards have moved on. Moving your proven content into a modern, mobile-friendly, faster design often delivers a visible improvement your visitors notice immediately, turning a forced technical move into a genuine upgrade. The end-of-life problem becomes the occasion for a site that looks current again.

Involving your current developer - or not

If you still have a relationship with whoever built or maintains your Drupal site, involve them - they hold useful knowledge. But a defining feature of stuck Drupal 7 sites is that the original developer is often long gone, and this stops nobody. Because content can be recovered from the live site with your authorisation, a migration does not depend on tracking down the person who built the thing a decade ago. Lost relationships and lost logins are ordinary starting conditions, not obstacles.

A staged approach for larger sites

If your Drupal site is large or complex, a move does not have to be a single terrifying leap. It can be staged: assess and plan first, migrate content in tranches, test thoroughly, and cut over in a controlled way with the old site live until the new one is signed off. Breaking the work into stages turns an intimidating project into a sequence of manageable steps, each with a clear checkpoint. Size is a reason to plan carefully, not a reason to stay on unpatched software.

Common myths about leaving Drupal 7

A few beliefs keep people frozen unnecessarily. "We will lose all our content" - no; content is exactly what migrates. "We will lose our Google rankings" - not with proper redirects and metadata. "It will cost a fortune" - a Drupal rebuild can, but a managed move need not, and doing nothing has its own rising cost. "We cannot move because we lost access" - you can, via capture from the live site. Most of the fear around leaving Drupal 7 is made of assumptions that do not survive contact with how migration actually works.

Getting an honest assessment first

The sensible first step is not to commit to anything but to get a clear assessment: what your site is, what it does, which option fits, what it would cost, and how long it would take. A free audit gives you that picture with no obligation, replacing a vague dread with a concrete, costed plan you can act on or shelve. Given that the alternative is leaving unpatched software running indefinitely, the assessment is worth having even if you ultimately decide to rebuild in Drupal after all.

The safety net during a move

One reassurance worth stating: a well-run migration is not a trapeze act without a net. Your existing Drupal 7 site stays live and untouched throughout the build, so there is always a working site to fall back on, and the new site is tested thoroughly before anything is switched over. The cut-over itself is quick and scheduled for a quiet moment, with the ability to revert if anything looks wrong. You are not gambling your live site on a single risky flip; you are moving to a tested replacement in a controlled way.

What your visitors will notice

From your customers' side, a good migration is close to invisible in all the right ways and visible only in the good ones. Your addresses keep working, your content is where they expect it, and the site simply carries on - except that it now loads faster, works properly on phones, and looks current. The years of an ageing Drupal 7 site fall away, and what remains is your proven content in a modern setting. For most businesses that is the pleasant surprise of the whole exercise.

The decision, distilled

If you strip everything back, the choice comes down to this. Staying on Drupal 7 is the one option that gets worse over time, because the security gap only widens. Of the three ways off it, a Drupal rebuild suits genuine applications, a WordPress rebuild trades one maintenance burden for another, and a managed platform suits the many business websites that never needed Drupal's power and would rather stop maintaining a CMS altogether. Identify which your site truly is, and the right path is usually obvious.

The bottom line

Drupal 7 is over: unpatched, increasingly a liability, and impossible to simply upgrade. Your three real options are a Drupal rebuild, a WordPress rebuild, or a move to a managed platform - and for most small businesses whose Drupal 7 site is really a business website, the managed route is the calmest and usually cheapest answer. Whatever you choose, choose it soon and deliberately, before an incident makes the choice for you. Our Drupal migration guide covers the managed route in detail.

Frequently asked questions

Is Drupal 7 still safe? No. It reached end of life in January 2025, so core no longer receives official security fixes and popular modules keep accumulating unpatched vulnerabilities.

Can I upgrade Drupal 7 to the latest Drupal? Not as an upgrade - the architecture changed fundamentally, so moving to current Drupal is effectively a rebuild.

What are my options? Rebuild in current Drupal, rebuild in WordPress, or move to a managed platform. The right one depends on whether your site is a true application or a business website.

We have lost access to the site - can we still move it? Yes. With your authorisation, content can be captured from the live site, so lost credentials are not a blocker.

How much does it cost? A Drupal rebuild commonly starts around eight thousand dollars; a managed-platform move starts far lower and removes future rebuild costs.

How long does moving off Drupal 7 take? For a typical small-business site, weeks rather than months, with your existing site staying live throughout so there is no gap for customers.

Will moving lose my search rankings? Not if it is done carefully - addresses are preserved where possible and permanently redirected where not, so your rankings and inbound links carry across.

What if my Drupal site is genuinely complex? Then a Drupal rebuild or a carefully planned, staged migration may be right. An honest assessment tells you whether your site is a true application or a business website, and points you to the option that fits.

Thinking about leaving Drupal 7?

If a move looks like the right answer, it is more straightforward than you may expect. On the CMS Pros Platform your content and rankings come across, the site is easy to edit yourself, and it is genuinely yours to export at any time - with security, updates and hosting handled for you. See how a move works in our migration guide, or request a free migration audit and we will give you an honest recommendation for your particular site.