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

part 1 | part 2 | part 3

other CMS options

In part one of this post I offered some advice on how you might go about choosing the right CMS for your business. 

In part two, working on the premise that WordPress is often quicker and easier to work with and where resources, assets and support are more readily available I looked at what else you can do to leverage that to make WordPress development cheaper still. 

In this final part I 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.

what other options do you have?

your solution stack

It’s possible someone in your organisation will dictate that you need a Java solution, or something that runs on Microsoft server hardware (and that running Apache, MySQL and PHP on this isn’t an option). In which case, you might look at something like Umbraco.

your internal resources

Similar to above, you may have a development team well versed in a particular technology, and if there is no appetite to cross train or up skill them (which is a service we offer) that will determine your choices also.

Software as a Service (SaaS)

Perhaps your site can be delivered by an online SaaS service like Wix, Squarespace, Shopify or ecwid. WordPress even offer a SaaS model via With SaaS some level of vendor lock-in is inevitable, but for certain applications the trade-offs might be worthwhile in terms of cost.

build it

You may decide to build something yourself from scratch, using a framework like Laravel for example. If there is a compelling reason for you to own your solution this might be an option. When it comes up, most times we are able to demonstrate this isn’t required, but of course there will always be exceptions.

would miggle help with these options?

If it was the obvious choice – and was for an existing client, or to break into a new market area, then yes, we would. But in most cases it’d be something we’d say no to, as there is enough Drupal and WordPress work for us to stay focussed on that.

so, if we come to miggle, it’s got to be WordPress surely?

Yes, your project is a WordPress project we are interested in if:

  1. The project scope is only achievable within the time and budget if we use WordPress, taking into account all of the cost saving factors and trade-offs mentioned in this post.
  2. The site’s scope is unlikely to significantly increase over its lifetime.

If not we think your project runs the risk of incurring technical debt, where some of the trade-offs we make, or tweaks we have to put in place, or plug-ins we rely on need re-evaluating within the life cycle of the site. The general premise of technical debt is that it always needs to be repaid. But if your site represents a short-term initiative, it may be gone before the debt is due. A good example of this might be a microsite around a particular campaign.

If there’s a risk that your site will incur technical debt that needs to be repaid, or that you want to use WordPress, but have a more robust set of processes around design, testing and deployment in particular, then we’re likely to maintain it as a Drupal project, because our use of best practices across the board there are more attuned – and because the framework is more flexible, so less technical debt is incurred, and less needs to be repaid.

Often, we’ll come across a requirement for a collection of sites, with short life spans, like a series of advertiser funded microsites, with limited functionality, which are all in essence WordPress sites. Would we build these all in WordPress? After all WordPress supports multi-site functionality. No, we wouldn’t. We’d say that what you really want is a multi-site Drupal set up which delivers a family of sites for you from a single codebase, such as we did with Friday Ad’s Spidersnet, or with our NHS distribution. Why? Because changes we make to the core product can be easily and cost-effectively applied across all sites derived from it, maintaining consistency and cutting support costs.

Bottom line is, if we build in WordPress, we’ll be quicker and cheaper, but we’ll hit a ceiling earlier. In making a recommendation to use either Drupal or WordPress you are trusting us to understand where that ceiling is – which is why planning and discovery are so important as part of the product development life cycle.

where have we hit a ceiling with Drupal?

We haven’t as yet, which is why it’s our preferred solution.

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.