Skip to main content

Blog Post

Managing the Drupal Maintenance Challenge - Part 1

by Jay Callicott
April 19, 2012

One of Drupal’s greatest strengths is it’s huge catalog of modules and themes. At the time of this writing, Drupal boasts over 15,000 modules and almost 1,500 themes on The challenge is knowing which modules, themes to use and how to maintain them with custom code and other customizations throughout the life-cycle of a website. While there are tutorials and blogs out there that can help, there isn’t exactly an instruction manual on which modules to use and which to avoid for production sites. The truth is that out of the large catalog of themes and modules, there is a much smaller subset of modules that are used over and over again by the community. When planning a new Drupal project there are many pitfalls out there that can cause real maintenance problems down the line and that is the problem is what I want to address in this article. It is my belief that many developers can gloss over this problem because ‘we can worry about that later’ and many CIO-types and business owners are unaware that the decisions today can dramatically affect the longevity of a website.

From my time as a developer, I have learned the hard way that not planning ahead can cause headaches later on down the line. I want project owners and developers alike to have a ‘maintenance first’ approach when scoping out their next project.

This blog will attempt to answer the following questions:

  1. How do I implement a project that can survive the next major Drupal upgrade?
  2. How much thought should we put into maintenance in general when we are planning a project or a new feature?
  3. Should we create a custom theme or sub-theme from 'framework' themes like Omega, Fusion?
  4. What modules should we use on this project? Which modules carry more risk related to maintenance and upgrades? What about custom code?

How We Got Here

When I was at Drupalcon Denver this year, one of the presenters noted how in the early days you could go onto and download every module to try out it. If you did that now you would be flipping through almost 400 pages of modules (This was the page I landed on which I clicked ‘last’ page. I got on board with Drupal somewhere around 2005 and I distinctly remember being able to flip through every page in the modules area. We no longer have that luxury. Now it’s google a module ‘idea’ or maybe search on

We also weren’t enabling 100+ modules, it was a much smaller number. Now on enterprise websites, a Drupal site can easily have 100-200 modules installed (Many distributions in fact enable 100+ modules on install). How in the world can we make sure all of these modules are going to work together?

Another key difference for me is that the rate of change for Drupal major versions has gotten much larger in scope. A lot more stuff changes now from version to version. I predict the jump from 7 to 8 will be at least as big from 6 to 7.  Drupal 7 was a turning point for me. Prior to 7 the upgrade cycle in my opinion was not as difficult. I do not recall the upgrade from 4 to 5 or 5 to 6, being nearly as dramatic as 6 to 7. Perhaps this is revisionist history, but I think it would be difficult to argue that a combination of the module expansion paired with the dramatic rate of change from version to version has made maintaining Drupal through version upgrades a difficult proposition.

Re-doing the Website is not Always an Option

I would love to see some data on the average life-cycle of a website in the sense of maintaining a consistent codebase. For instance has been around for years, but like most websites Amazon has a makeover every several years.

Somewhere north or south of 5 years is probably a typical life-cycle for a site when you think about a website’s codebase as well as the overall look, content architecture, etc. If you look at the Drupal project life-cycle of late, you can sense that a new version will come out every 3 or so years, with a year buffer for the new version to get adopted, and a couple years to phase out the old version. If a Drupal site is built in year 1 of a new version then you might get another 5 years of support before the site falls 2 versions behind, which means it is no longer community supported.

For some, there might be a temptation to just ‘wait it out’ a few years until the client wants a new redesign, site architecture, etc. and just completely revamp the entire site then. This is not always an option. Also, I think clients would be justifiably annoyed to find that the codebase cannot be upgraded without a complete overhaul.

Is this situation avoidable? Can a large Drupal implementation be constructed in a way that insulates it from ‘overhaul’ madness? This important question I will address in my next blog post.


Meet team member, Jay Callicott

An enthusiastic Drupal developer of ten years, Jay spent six years as Mediacurrent’s Lead Architect before transitioning to his current role in 2015. As the Vice President of Technical Operations, Jay helps to foster best practices and shape processes for Mediacurrent's development team. An active contributor to the Drupal community, Jay has developed dozens of custom modules, coded themes, and written install profiles for projects from Drupal 5 through Drupal 8.

Prior to Mediacurrent, Jay worked as a PHP developer in Little Rock, AR. During that time, Jay worked on several large PHP builds including the Arkansas Drug & Alcohol Testing Database, the Arkansas State Police FBI Civil Harvesting Application and the Arkansas Governor Newsroom which won his agency an e-government award that year.

During his 8 years at Mediacurrent, Jay has led teams on dozens of projects including more recently, Jamaica Star, and University of Georgia. He maintains several key marketing automation modules (Pardot, Silverpop, Eloqua, Hubspot, and Automate) that have helped solidify Mediacurrent as a thought leader in the marketing automation space. Jay created and actively maintains one of the most popular distributions on Drupal,  OpenChurch, which has over 100,000 downloads. A Drupal 8 version (relying almost entirely on core modules) was recently released.

Outside of work Jay enjoys family time with his wife and two young children. He stays involved with his local Little Rock church and also volunteers time on occasion to help build faith-based charity and church websites.

Learn more about Jay >

Related Insights