selecting a Content Management System (CMS) – WordPress, Drupal, or something else? part 1

part 1 | part 2 | part 3

Choosing the right CMS for your web applications can be a daunting task. Where do you start? 

Here at miggle, we’re best known for the sites we build in the Drupal CMS. We also build sites in WordPress, and in the past we’ve built sites in MODX as well. For a period we used our own proprietary CMS, miggleCMS. And between 2008-2012 we were managing large amounts of content, via a team of editors, for AOL, Yahoo! and BSkyB. Adam, our Lead Product Manager has worked on integrating technology for national press titles online and in print. Emma, our Head of Ops, was Head of Ad Ops for a large publisher and I spent eight years across two portals. Alongside our team of Acquia Certified Developers we have a huge amount of experience in developing CMS and managing and monetising content especially for travel, media and not-for-profit organisations.So, we’re in a good position to offer some advice I think.

too much information!

Google ‘Drupal versus WordPress [versus Joomla versus etc.]’ and you’ll get a whole heap of results: some good, some bad, some very definitely loaded and biased, based on the writer’s preference.

I’m going to try and give you a different viewpoint, based on the fact that here at miggle we’ve used both Drupal and WordPress – as most often we find the choice is between these two. The opinion offered here isn’t based on a side-by-side evaluation, but on the recommendations we’d make, based on a number of criteria which we’ve described below.

some considerations

The advice is based on these general considerations:

  1. CMSs, like all tools, are only effective when placed in the hands of an expert.
  2. CMSs (like all software) are only secure if you keep security updates applied. This is not a weakness, it’s common sense.
  3. For all CMSs there will be a range of functionality covering what is available out of the box and what is available via extensions (i.e. plug ins and modules) as well as what will only be achievable by custom code.
  4. Where you fall in this range depends on what trade offs you are prepared to make in terms of time, cost and details of functionality.
  5. Custom functionality, by its nature, sits outside of the CMS and as such can’t be judged as part of the CMS. It is only as good as the developers who build it, and the standards and processes they apply towards writing, testing and documenting it.
  6. Most popular CMSs deliver on the majority of features you are likely to need. It is unlikely you will be the first person who has ever requested your feature, and, if you are, no other CMS will be any better placed to fulfill that requirement.
  7. CMS development aside, your product’s development is part of a lifecycle that requires planning, design, testing, deployment and measuring, most of which stand apart from the functionality of a CMS.

WordPress, Drupal or something else?

economies of scale

According to, 45% of the top million content managed sites are built with WordPress. The corresponding figure for Drupal is 5% – so one in 20. It’s logical to assume therefore that there are more WordPress developers than there are Drupal developers and that the cost of the former won’t be as high. However, as quantity is generally no assurance of quality, you may get what you pay for. The fact there are also more WordPress sites may mean that they are quicker and easier to build, and therefore cheaper. This is the view we take at miggle.

Therefore, to start off with, in making a choice we will ask you what your budget is. We will divide that by our day rate and then we will take a view as to whether that number of days is enough to do your project based on your requirements. Because we have more robust planning, design, testing, deployment and measuring processes around Drupal we will make that calculation with Drupal first. If the budget is not enough, this will rule Drupal out. Given that budget often buys time, a short deadline in an environment where you do not want to make reductions in scope may also rule out Drupal.

why do we have better processes for Drupal?

Bluntly, we have better processes for Drupal because we think Drupal is a more flexible, powerful CMS. You can read more about why here. We think it suits longer term projects which require more iterative development over time, like a travel company which is adding booking functionality or a charity which wants to start collecting donations.  WordPress we think is better where the feature set remains relatively static, or where the site is expected to have a shorter shelf life.

one person or a team?

If you are fortunate enough to have a broad range of experts and specialists at your disposal then Drupal is a great solution for a team. Because WordPress is quicker and easier to get started with it's a better solution for ‘jacks of all trades’. This is a common trait of product managers like myself. In general if you asked me what would I get my team to build a charity website in, I’d say Drupal. If you asked me to build it myself, I’d build it in WordPress.

There are companies who have the same processes around WordPress as we have for Drupal, who will see WordPress as a tool that is most effective in the hands of a team. It’s unlikely that they will see WordPress as a budget offering. Pragmatic are a probable example. (In the same way, you will also find individuals who can master all aspects of Drupal. Kevin Elliot of Very Useful Software is an example.) However, in our experience, Drupal is the more flexible and most team orientated; by dedicating most of our time to it and the processes around it we’ve extended our ability to be more flexible with it.

if WordPress is quicker and easier and thus more cost effective, how can we make it cheaper still?

I think we make WordPress even more cost-effective by exploiting what it's good at in terms of looking at effective, quick and easy ways of managing design, functionality, security, maintenance and hosting. In part two of this post I go into each of these areas in more detail. In part three I’ll go over what other options are available other than WordPress or Drupal, before finally closing on how we chose the right solution between the two.

If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.