Ten years ago, the average organization had one website. Since then, the world has become a more complex place with a diverse set of needs. If you're like most organizations the number of sites you have continues to grow at a rapid clip. You've dipped your toe into the social media waters by setting up one or more blogs, you use microsites for the foundation of your marketing efforts to promote products and events, and community sites to engage with the people who use your products. And of course, you have your corporate website, as well as your intranet and a number of internal collaboration websites for different projects. This is today's reality.

During the past year, I've met with many organizations that have hundreds of sites; some even have thousands of sites. Most of these sites are vastly different in terms of scale, functionality, complexity and longevity. As a result, the level of investment and the time to market requirements are usually very different. Some of the websites are owned by the company's IT department while other websites may be owned by their marketing department.

For most organizations, one tool cannot get the job done, so they keep multiple tools in their toolbox - whether they intend to or not. Unfortunately this is a common scenario in many enterprises. We see many organizations that run on Vignette, but they add WordPress to power their blog, and use SharePoint for their intranet. Managing integration and multiple (proprietary) solutions is not only costly but it acts as a roadblock to innovation and slows time to market when changes are needed.

It can be a complete mess.

Fragmented cms situation

CIOs are now waking up; they're realizing that the cost of running twenty different content management systems on twenty different stack configurations is an expensive, unnecessary burden for the organization. They can see that there are cost savings to be made if they standardize. What they want is something more than a content management system: they need a single platform that meets their needs. They need Drupal.

The New York Stock Exchange is launching 30 sites on Drupal. Turner Broadcasting is migrating 80 sites to Drupal. A large consumer pharmaceuticals company might end up with over 3000 Drupal sites. Why? Because Drupal gives their IT team an agile platform to deliver new sites quickly with the breadth of capabilities to meet their needs, but broad enough in scope to serve as a web platform too.

More and more, I see large organizations standardize on Drupal. Drupal's low-cost entry point and open, modular architecture provides the perfect foundation. Drupal is one of the few solutions that can scale from very small to extremely large, and has the depth and breadth of functionality to support thousands of different use cases. Drupal sites can span a wide range of functionality; from blogs, to marketing microsites, social business community sites, corporate intranets, e-commerce sites and more. There are incredible success stories for each of these use cases already. Plus, we've now reached a point where many open source content management systems outperform proprietary solutions on technical superiority and pace of innovation. Drupal is in a very unique position.

This is an immensely powerful trend. If we navigate this well, Drupal could become truly ubiquitous and go from powering 1% of the web, to quickly powering 5% of the web and even further. It requires us to keep making Drupal a better platform, to crack the code on how to make Drupal distributions truly compete with commercial point solutions, and to build out an even larger commercial ecosystem and community. Needless to say, I'm super excited about Drupal's future and the opportunity ahead of us.


Andy Kucharski (not verified):

Well crafted. We have seen this trend associations are migrating to Drupal to run their main sites and then are using Drupal to run advocacy sites. Let's hope it continues.

The problems that we still do see with Drupal are with staging migration and document management.

Avi Alkalay (not verified):

I'm bookmarking this post so I can constantly use it as an argument to extend our current Drupal framework instead of creating another site for a new app.

My company (hum, IBM) has hundreds of Intranet sites and thousands of Intranet apps (say spreadsheets), each with its own set of taxonomies, rules etc. I'm trying to bring the most of them together under one Drupal instance. Some of them make sense to stay together, sharing at least taxonomies. Others apparently don't, but just the fact they are all together creates future opportunities for extremely easy integration, node referencing etc.

Even with thousand of nodes, the storage required is very small anyway. MySQL is very efficient. Well, but that's not the point anyway.

I truly believe that Drupal is the best option when you weak up. But just remember that usually this multitude nightmare is nobody's fault, it obviously just happened slowly over the years and over organizational management changes.

Drupal's time happens at the infrastructure and middleware consolidation time!

David Clark (not verified):

The metaphor I use to describe such legacy technology - the new england farmhouse

Mark Hope (not verified):

I agree with Andy that dev/staging/live is still an issue - difficult even for Drupal devs with a number of years experience.

I know this is an aim for Drupal 8 and with every release I'm amazed at how it's maturing.

Bèr (not verified):

Been there, done that, and returned.

I have helped many organisations in such migrations. After a while, however, they *all* found Drupal-for-everything both expensive and less-effective.

A recent case illustrates this fantastic: Company had a bugtracker integrated in SVN, a microblog for internal *and* external communication, company-brochure site, and homebrewn CRM. Everything moved to Drupal within a year.


  • One site with views, CCK and actions/workflow, acting as bugtracker. SVN was bolted on with some pre-post and so on hooks. It worked -technically- but developer activity in the issue-queues dropped to an alltime low.
  • A microblog that only a few ever used, because it lacked #hastags, the ability to push to twitter and FB and proper @replies.
  • A very well working and nice-looking brochureware.
  • A Drupal with civicCRM bolted on. Resulting in sales department using excelsheets for all their CRM (and no longer the central site).

It was clearly a failure, partly for technical reasons, partly because of poor change-management and partly because of poorly implemented Drupal-instances. (This was the moment they got me involved). We evaluated. Did some proof-of-concepts and concluded that:

  • identi.ca was installed&configured in less then 4 hours. It got us there for 98%, where the previous Drupal-microblog site got about 60%.
  • Track did exactly what the developers needed and wanted with SVN integration. Was a hell to get configured, but compared to the previous 100+ development hours the 16 hours track-hacking were ignorable.
  • the brochuresite stayed and works fine. :)
  • fatfreecrm, again quite cumbersome to get up&running (Ruby, not the easiest to host), but got the sales-people back, centralised and online again.

Funny thing that I was called in as Drupal-expert, but left them with a lot less Drupal (and a lot happier).

Sure, you can build anything in Drupal. But that requires *building* and often gets you only 60% to the goal. Wherelse (FLOSS) turnkey solutions require less hours development, fewer investments and get you there sometimes the full 100% and often close to 90%.


Be careful; I believe you misinterpreted what I wrote. I'm not suggesting Drupal should be used for everything.

At Acquia, our corporate website, our intranet, our HR system, our knowledge base, and various micro-sites all run on Drupal. However, we use Jira as our ticketing system, Salesforce as our CRM system, etc. We don't think of our ticketing system or CRM system as websites, or as part of our web strategy. Plus, in our case, Jira and Salesforce are the best tool for the job. We certainly don't recommend using Drupal when it is not the right tool for the job.

Standardizing on Drupal certainly doesn't mean every single system needs to be Drupal. Going from 20 different systems to 5 different systems still translates to cost savings. It goes without saying that you need to be smart about what to standardize on Drupal, and what not to standardize on Drupal.

I know quite a few organizations that successfully standardized large portions of their websites on Drupal -- but not necessarily every site or system. For example, Turner Broadcasting is moving many large sites to Drupal, but not the main CNN website. I hope to cover some of those stories in more detail as they are truly fascinating.

Last but not least, my blog post talked about both the present and the future. Drupal continues to become better and better. The feasibility for an organization to standardize on Drupal will continue to improve over time.

W^L+ (not verified):

And honestly, I want Drupal and WordPress to natively and naturally work together. Not through fiddling with bridges that break every time there's an upgrade. I want the two systems to coordinate on theming / templating and to make it simple to share user databases.

Drupal is (from my limited experience) head and shoulders above the competition in most areas. WordPress is head and shoulders above all others in the blogging area (although PivotX is rising fast). So I'd like to encourage your organization to reach out to Matt at WordPress about ways to make your two products play well together.

Mike Schinkel (not verified):


I have two (non-concurrent) years of experience on each platform, Drupal and WordPress and I can't see such integration ever happening; the architectures of the two platforms are just two radically different.

Steven_NC (not verified):

Agree. But as important as a single platform is for large enterprises, they are just as important for small businesses that have limited (or no) resources or that can contract with only one outside resource.

snufkin (not verified):

If you have trouble monitoring several sites while going easy on the setup and client side I recommend checking out Drupal Sentry (yes, its my module, so apologize for the shameless self-advertising).

Arne (not verified):

I think it is an ongoing growth and expanding thing about migrating ones sites to Drupal. It starts with (sub)-sites/parts that are well driven and managed with Drupal. Using other frameworks or apps from different sources and/or leaving parts untouched which are running well now is a good way. As Dries said "from 20 ... to 5..." is a cost lowering way.

After the time you may migrate more and more to Drupal, just as Drupal grows, the core (D8), the modules, the distributions, ... and the experience with Drupal.

Maybe there could have been more of what Bèr mentioned migrated to Drupal if there were more experience with Drupal. Maybe D7 would have been the better choice if it were ready at that time.

I hope that the way of the Drupal community make Drupal more capable of more functions and serving for cases so it will lead to a "Drupal-for-all-alternative", so that you CAN choose Drupal for all but you needn't to.

I'm wishing Dries all the best for the future and that more and more people are having fun and success with Drupal.

Joe Whelchel (not verified):

I too, have bookmarked your post for future use in making the case for "why Drupal", as it is articulate, detailed, and compelling. I also sense an important and timely change of tone in this post. One of the things I have admired about the Drupal community is its public objectivity about the platform's soft spots, and its openness about areas needing change. That said though, coming from an "enterprise" background myself, I have been struck by a lack of "positive spin" marketing materials for the Drupal platform. In the corporate enterprise market, I saw a steady barrage of hyperbole-laden marketing materials from proprietary vendors, and we just accepted that we had to sort out the BS from the truth ourselves.

I wouldn't want to advocate a similar personality for Drupal, but it has reached a level of substance and power that you deserve to "strut your stuff" a bit more aggressively. Thanks for your leadership!

Jesper Vingbor… (not verified):

For Drupal to gain credibility at the center of things (a worthwhile proposition, indeed), it must open itself up a lot more. It must become a lot easier for "foreign" development platforms to manipulate Drupal entities at a very basic level. I'm not thinking web services or some such, but direct access to the database without actually bootstrapping the whole stack for each and every operation. Ideally, I want to CRUD nodes, users etc in a consistent and orderly fashion, bypassing the Drupal code base entirely.

Also, I want to do it in the language of my choice! Not just PHP ...

Case in point:
I'm developing a classic community site (using Drupal, of course), and I want to add a chat feature. Now, I could probably hack out a module for that, but Drupal isn't really good at real-time stuff, so I settle on nodejs, which is a perfect match for that kind of application. After all, it's intensely focused on the real-time, low-latency operations that's essential to a happy, snappy chat feature.

But I don't want to loose the Drupal dimension. Accessing users, nodes and all (maybe even views) would provide a much better experience for my visitors while they were chatting. It would also make my own life a lot less stressful.

It's a tall order, I know, and the ways one could tackle this are endless. But a step in the right direction could be to develop Schema API into a fully fledged data dictionary. One that is amenable to exploration from any toolkit, one that provides the rules of engagement if I want to update a user status from said nodejs application.

Such a beast would, incidentally, be immensely useful for any kind of import/export/migration/integration tasks, be they real-time or batch-oriented.

Imagine, say, a Ruby gem for Drupal ...

omahm (not verified):

This is exactly what I've been trying to do for the last couple of years, bringing legacy websites onto the Drupal platform and providing a standardised system for development and administration with the limited resources we have in-house.

Where Drupal falls apart for me is the lack of modules or API calls to store nodes, CCK etc securely on the database. Data protection legislation mandates that we encrypt data of a sensitive nature collected via Drupal even though the site is running on a dedicated server.

I have looked at various options (hook_nodeapi,custom MySQL database provider, custom CCK fields) but have run into issues with each.