Drupal's Upgrade Path and the Product Approach

Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.

It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.

If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.

The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.

There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.

Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.

While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.

Enter Drupal 8.

With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.

Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.

With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).

With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.

With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?

Resources and Related Reading:

Original Article: