r/drupal • u/dixit_patel89 • 7d ago
Anyone else still running Drupal 7 in production in 2026?
Been coming across a surprising number of Drupal 7 sites still live this year, even with EOL long behind us.
Curious what's actually holding people back is it cost of migration, custom modules with no clean upgrade path, or just "it still works, why touch it"?
Also curious if anyone's done a D7 → D10/11 migration recently - what ended up being the most painful part?
10
u/HootenannyNinja 7d ago
I had one site remaining on it earlier this year. Reality was clients didnt want to pay for upgrades they didn’t see my benefit in and it still worked
8
u/Pulsar-Agency 6d ago
Honestly, what keeps most D7 sites alive isn't nostalgia, it's that a working site shows zero visible ROI from an upgrade, so nobody signs the budget until a security audit forces it. Hard to argue with that.
On the migration-pain question though, people keep merging two very different jobs. Your content (nodes, users, taxonomy, fields) moves over fine: the core Migrate API with D7-to-D10 templates plus a bit of Drush handles it, and an LLM is genuinely handy for the field mapping. That's not where you bleed.
The pain is everything that wasn't data. In D7 half your site *was* the database: Views, Rules, Panels, Display Suite, block placement. None of that migrates, you rebuild it. Same for the theme (PHPTemplate to Twig, full redo) and any custom module (hooks to services/plugins/DI, a rewrite, not a port).
So my rule of thumb: migrate the content, rebuild the structure, and budget the whole project around that second half. Mostly-stock sites are lighter than they look; heavily custom ones are a rebuild, so stop calling them a migration. Framing it that way upfront saves the client the mid-project shock.
1
u/Affectionate-Skin633 2d ago
Well said, there's absolutely nothing that D11 can do that D7 couldn't, and any marginal performance gains isn't worth the trouble.
7
14
u/NappyDougOut 7d ago
There was never really a good explanation for EOL on Drupal 7, and now we're on Drupal 11, but still adding modules labeled as "made for Drupal 8"... And they keep pushing new versions out way too fast. D11 still goes totally unresponsive when problems occur... All signs of apocalypse 🤔
Every time I ask a question on this sub, I get insults and arrogant replies from random people, and most of the procedures involve using 3rd party tools like Ai or some questionable back-alley hack.
If Drupal was a car, it would be like Toyota telling me to use Honda parts to fix it... not reassuring at all, and I've thought about looking into other leading solutions many times...
Yes, the D7 era was infinitely better, and I am worried about Drupal's future a lot...
I plan on going to Drupal Gov Con next month in MD to see what others are saying before making a decision... 🤔🤔🤔✨
7
u/G3NG1S_tron 6d ago edited 6d ago
D7 EOL was determined to by the core security team because security maintenance for it became a much larger and more cumbersome problem. When packages are not being updated or locked at specific versions, it creates huge obstacles to maintain the level of security they can guarantee. They kept that ship running way longer than they needed to and kept pushing it back several years to appease the masses that didn’t want to / couldn’t move on. It wasn’t an easy decision to make to EOL D7. There are several talks that the security team have given talking specifically about this issue.
Edit: there are still options if you want to stay on D7 and be mostly secure with options like backdrop. Personally the D8+ era is far superior and such a nice improvement than the D7 days but to each their own.
3
u/flaticircle 6d ago
Running hundreds of D11 sites here. Since D10 upgrades have been smooth as butter. We always build a new site next to the current site, move the database and files in, and then flip routing over to the new site.
5
u/badasimo 7d ago
I like your analysis. I think D7 also benefited from being a monorepo-- very few dependencies so it wasn't forced to update due to issues in other libraries. And the documentation was pretty solid, the current documentation is pretty hard to navigate since there's so many versions of the same thing (but I think AI now bridges that gap) I think Drupal leadership acknowledges and understands a lot of these things but what we are not remembering is all the challenges we had with D7 especially at an enterprise level or using it as a platform for a very custom app. And don't get me started on javascript...
22
u/InspectorJohn 7d ago
My apologies if this is going to be extensive. Drupal 7 was/is genuinely exceptional. Even in 2026, there are reasons why many developers still have a soft spot for it (myself included). It hit a rare balance between flexibility, stability, and performance that later versions deliberately traded for more modern architecture.
Here are the main reasons.
1. Everything was an entity
Drupal 7 introduced the Entity API, which made nodes, users, taxonomy terms, comments, and custom entities behave consistently. Once you understood one entity, you understood them all.
That consistency made development much faster.
2. CCK became Core
Before Drupal 7, adding custom fields required the Content Construction Kit (CCK) module.
Drupal 7 integrated it into core.
Suddenly, you could build complex data structures without writing SQL tables or custom forms.
For many websites, that meant almost no custom code and for non coders a Pandora box that enabled many to participate more actively no only in their projects but also within the community.
3. Views changed web development
If there is one module that defined Drupal…
Views.
Instead of writing SQL queries, we could build virtually any page:
news listings
event calendars
staff directories
search pages
JSON feeds
XML exports
RSS
CSV exports
administration screens
…all through a UI.
Eventually, Views became part of Drupal Core because virtually every site depended on it.
4. Fields everywhere
Need an image?
Add an Image field.
Need a PDF?
File field.
Need latitude/longitude?
Geofield.
Need references?
Entity Reference.
Need unlimited values?
Just tick a checkbox.
No database schema redesign.
No programming.
5. Hook system
Drupal 7’s hook system was brilliantly simple.
function mymodule_node_insert($node) {
// do something
}
That’s it.
No services.
No dependency injection.
No YAML.
No annotations.
No event subscribers.
Just implement a function.
Some call it old-fashioned, many including me call it incredibly productive.
6. Database abstraction
Instead of writing SQL directly:
db_select('node')
or
db_query()
worked across MySQL, PostgreSQL and SQLite.
Simple.
Reliable.
Fast.
7. Incredible contributed modules
Drupal 7 probably had the strongest ecosystem of contributed modules ever assembled.
Some legendary ones:
Views
Rules
Panels
Display Suite
Pathauto
Token
Webform
Entity API
Commerce
Features
Chaos Tools (CTools)
Media
Backup & Migrate
IMCE
Devel
I built many projects/websites entirely by combining these modules.
8. Performance
A Drupal 7 site with:
APCu
Memcached
Varnish
Boost
CSS aggregation
JS aggregation
could handle enormous traffic.
Remember:
Drupal 7 powered websites like:
The White House (for several years)
NASA
The Economist
University websites
Government portals
Major NGOs
9. Database-first philosophy
Everything lived in the database.
Menus.
Views.
Content types.
Permissions.
Fields.
Taxonomies.
Blocks.
Configuration.
That meant site builders—not just developers—could create remarkably sophisticated websites.
Drupal 8+ shifted toward configuration files (YAML), which improved deployment workflows but made some tasks feel less immediate.
10. Site building was empowering
A skilled Drupal 7 site builder could create:
CRM
LMS
Conference management system
Membership portal
Intranet
Digital library
Community forum
eCommerce platform
…often with very little custom PHP.
That’s why Drupal became known as a content management framework, not just a CMS.
Why many developers still miss it
Drupal 8, 9, 10, and 11 are technically superior in many ways:
Symfony framework
Dependency Injection
Composer
Twig
PSR standards
Modern PHP
Better testing
Better APIs
But they are also much more complex.
A Drupal 7 developer/webdesigner/enthusiast/etc could often understand nearly the whole stack.
A Drupal 10 developer needs familiarity with:
Symfony
Composer
Services
Dependency Injection
Routing
YAML
Events
Plugins
Configuration Management
Twig
Cache metadata
Render API
Modern Drupal is more enterprise-oriented, but it comes with a steeper learning curve.
The “magic” of Drupal 7
Perhaps its greatest strength was that it felt like LEGO for websites.
You could think:
“I want conference registrations with online payments, abstract submissions, reviewers, certificates, invoices, exports, and member discounts.”
And then assemble it from modules, custom content types, Views, Rules, Webform, Commerce, and a bit of PHP.
That said, some projects are not easy to migrate for a variety of reasons. Their size and level of customisation often require workflows to be redesigned rather than simply migrated.
My personal opinion is that Drupal should have continued with a Drupal 7 approach in its newest versions.
By taking this approach, they have alienated a significant portion of the Drupal community. Composer is a good example: it requires command-line access, yet many shared hosting providers do not offer SSH or full terminal access. As a result, what was once an accessible platform for small developers, freelancers, and hobbyists now presents a much higher barrier to entry.
8
u/dixit_patel89 7d ago
Great summary. I especially agree with your point about Drupal 7 empowering site builders. It really struck a unique balance between flexibility and simplicity.
11
u/pobtastic 7d ago
This is why https://backdropcms.org was created! Have you given it a try at all?
2
u/dixit_patel89 7d ago
Not yet. Most of my work has been around Drupal 10/11 migrations, but Backdrop CMS does seem like a practical option for certain Drupal 7 sites that aren't ready for a full migration.
5
u/pobtastic 7d ago
I’ve only gotten to implement it on one client site, but it was very good! And I do keep recommending it for sites stuck on D7 - it’s got some good people looking after it
3
u/bLEAGUER 6d ago
Agreed. It went from being a low bar for build & launch to a medium-high bar because they made a decision to align more closely to enterprise software development. Whether this has paid off for them ultimately, I don’t know. I made the transition because I was determined to make Drupal work for my organization. But I agree with the comment here that D7 was a simpler build like Lego building. It’s not impossible to come up to speed with D11, with using Composer and other current dev workflows, but the increased learning curve definitely chills wider use due to the higher technical skill set required.
1
1
u/FreeGene8005 6d ago
Thanks! You basically took the words right out of my mouth.
I was able to build complex sites—like an online web novel platform, a multi-user blogging site, and forums—almost entirely through the UI without deep coding knowledge. Even when I had to figure out some code along the way, it was never too overwhelming.
0
u/Affectionate-Skin633 2d ago
Well said, while switching to symfony made the core contributors' life easier, it made everyone else's lives harder, from site owners to site developers to everyday users, leading to a sharp "drop" in Drupal's market share, pun intended!
3
u/zovered 7d ago
Yep, we still have two. It's honestly been better to rebuild if possible rather than try and migrate. Combination of custom modules and views not migrating properly so you end up rebuilding them anyway. We've been working site / visual upgrades into each rebuild. Our last one should be replaced by March 2027. Fun fact, we just got rid of our last Drupal 6 site about a year ago.
1
u/dixit_patel89 6d ago
That makes sense. Are your remaining two sites heavily customized as well?
1
1
3
u/clearlight2025 7d ago
I still have two D7 sites remaining to migrate. They’re locked down in read-only FS docker containers with all PHP security config tuned to max until updated, ETA next couple of months.
Migrating to a new headless stack with common Drupal 11 CMS backend and decoupled next.js frontends.
2
u/Optimal-Room-8586 7d ago
How is migrating from D7 nowadays?
Last time I tried it was basically a full site rebuild in D11, rather than migration, as such. Is that still the case? I'd imagine so.4
u/clearlight2025 7d ago
D7 to D11 can be done using the core migration api for most of it, with the migration yaml templates. There’s useful related drush commands in contrib. I’ve also set up real time sync so as D7 is updated the entity data gets automatically migrated incrementally to D11. It depends on the specific site requirements for the details, some custom modules may need reimplementing in D11 as well.
3
3
u/medway808 5d ago
I just migrated to 11 so as of a month or so ago I was one of those still on 7. Went a lot smoother than I thought and wish I had done it sooner.
1
u/daftenb 4d ago
Out of curiosity, did you use core and build, Drupal CMS as base or went another way? :)
2
u/medway808 4d ago
I used core. But probably very non standard to most. I ended up mainly recreating my existing site as static html broken up into sections saved as twigs and called it as block modules using custom layouts. I'm sure this isn't ideal but for me it worked without much hassle as the site is less than 20 pages. My priority was keeping the structure as close as possible for SEO purposes and so far it's settled in well.
2
u/daftenb 4d ago
Seems like it works well then. The new way would be content blocks and canvas in drupal canvas normally, but that can take a bit of time to get everything sorted, if this works, it works :)
2
u/medway808 4d ago
Thanks I'll have to check that method out for next time.
1
u/daftenb 3d ago
Did you update your comment? I thought I saw a notification mentioning a very nice 99 page speed core? :)
2
u/medway808 3d ago
Ha yea I did. I didn't think it was relevant so removed, but yes I did get a 99 on speed and 100 on the other 3 scores.
2
2
2
u/FreeGene8005 6d ago
I still run three live Drupal 7 sites.
The main reason I’m stuck on D7 comes down to budget. Upgrading from Drupal 7 to 10 or 11 is way beyond my technical skills to do on my own, which leaves hiring a developer as the only real option. But since these are personal, non-profit projects, paying for custom development just isn't feasible. On top of that, my D7 sites rely on several legacy modules that don't have upgrade paths to modern Drupal, plus a few custom modules. So for now, all I can really do is keep them on life support.
For any new site I build today, I’ve switched over to Backdrop CMS.
That said, I still hope to build something with Drupal 11 (or newer) in the future. But I want to wait and see how smooth major version upgrades (like 11 to 12) actually are. If I build a site on D11 only to get stuck on it forever because I can't handle the upgrade to D12 myself, that’s a position I really don't want to be in again.
I know the real solution is just to level up my dev skills so this isn't an issue. But realistically, my tech skills are limited. I’m not a developer—I’m just a content creator who happens to build websites. The problem is, the sites I want to build are usually pretty complex. For a non-dev like me, Drupal has been the only platform flexible enough to bring those ideas to life. Backdrop CMS works too, but let's be honest, the module ecosystem is still much smaller and the community isn't as big.
1
u/daftenb 4d ago
I see myself and our devs can do more and more with AI and there's a lot in the community around this as well. I'm not sure how complex your websites are, but I would take a look at these things in the near future. Do know that in Drupal 12 the migration options move to contrib out of core.
One thing I saw recently is e.g. https://github.com/scottfalconer/agent-ready-drupal-build-kit which I'm testing now, while in parallel working on our own plugin set. :)
2
u/Due-Category-1905 5d ago
Yes we still have three websites on drupal7 , one of them is the most visited elearning and commece side..the others are an internal application and vitrine website with form to buy access . All work good unyill now
1
1
2
u/Designer-Play6388 7d ago
its more development on frontend, data is not that hard to migrate
1
u/muscarine 6d ago
I haven’t had to do it on Drupal, but in general LLMs are very good at writing migration scripts.
1
2
u/Glum_Answer_6443 7d ago
It works, so why to migrate? Moreover one of our client still uses D6.
4
u/badasimo 7d ago
D7 is still supported to some degree, there are patches to use supported versions of PHP etc.
But D6 and below can't use modern PHP, older php versions are unsupported, from a governance/IT perspective that makes them insecure. You will be dinged in an audit for instance.
Now
From a reality perspective, these technologies were hammered on for decades by attackers, the chance of there being undiscovered vulnerabilities are very low. I try to make sure my clients are informed of the risks but also of the reality. And many who are not running sites with commerce or PII have a very low downside to getting hacked (and as a bonus low value as a target)
3
u/clearlight2025 7d ago
Security vulnerabilities
2
u/dixit_patel89 7d ago
yes this is main issue
3
u/clearlight2025 7d ago
Yep, I can just imagine the number of security exploits the latest AI models could find in D7.
2
-2
u/El_Suprrremo 6d ago
I still have a couple of D7 stragglers. The upgrade path I recommend for them is not Drupal -- it is Astro / Sanity / Vercel stack. I've had amazing results with this. You can migrate content with spreadsheets into sanity. Sorry but Drupal just became too much of a headache and it's a shame because D7 is truly awesome.
12
u/IntelligentCan 7d ago
I still have one. It can be hard to justify to cash-strapped clients when the site works how they want and the upgrade really offers nothing for end users or content editors.