Decisions, Decisions: When should we upgrade from Drupal 6?

Originally published on drupalconnect.com.

Drupal 6 was initially released in 2008. For reference, Drupal 7 was released in 2011 and the Drupal 8 estimated release is sometime in late-September (subject to change). Because of the effort required to support 3 versions of Drupal at a time, once Drupal 8 is released, Drupal 6 support will end 3 months later. The original plan to spin down Drupal 6 support on Drupal 8's release was revised to help people transition. From drupal.org:

“Unsupported status” means the community will not be providing support or patches in the same way we do now. Continuing to support Drupal 6 would be difficult for many reasons, including a lack of automated test coverage, the requirement for rigorous manual release testing, the slow-down it introduces in the release of security fixes for the vast majority of Drupal users (on version 7+), and the general shift of volunteers in the community moving their attention onto Drupal 8 development.

Drupal 6 end of support

While this is helpful, some Drupal sites can be large enough that a transition to a new site will take longer than 3 months, from scratch to launch. Reported usage of Drupal 7 surpassed Drupal 6 more than 3 years ago and usage continues to diverge.

What are the concerns with using Drupal 6?

There are several improvements that come with Drupal 7 and 8. Among them are better multi-lingual support, better APIs in general, performance optimizations, sensitivity to mobile users, and better content administration (drupal.org). The Drupal community continues to move forward and support newer versions of Drupal, meaning contributed modules and themes are more actively developed, more secure by nature, employ modern design patterns, and provide more bleeding edge support.

Ongoing module support

Over time support of Drupal 6 modules has reduced and will continue at a more rapid pace. It will be more difficult to find resources to maintain Drupal 6 components, as most developers are either focused on or only familiar with newer Drupal development. Read: more expensive.

Drupal security issues are a part of the natural fiber of technology. Website security is critical for anything connected to the internet; including a Drupal 6 website. Reasons include securing e-commerce, updating privacy, protecting authentication credentials from new threats, and regulatory and legal compliance; but qualifying these factors isn't always familiar or straight-forward. This illustrates the nature of security exploits and with diminished community support, again, translates to more work to maintain a Drupal site. Again, more expensive.

All Drupal sites are potential security exploit targets. Running a secure Drupal 6 site requires a way to maintain and patch modules and core to keep up with evolving security threats. At best an exploited website could require spending substantial amounts of money for disaster recovery by a company like Drupal Connect. An organization may even be fined by federal compliance agencies for improperly protecting website data or users.

How do we migrate to a newer version of Drupal?

Migrations can be very time consuming. Don't underestimate this effort.

How do we migrate content?

Migrating content from Drupal 6 starts with an evaluation of the new website in a process called Information Architecture (IA) Discovery. During that process there are three main goals:

  1. Establish the data objects/structure.
  2. Define relationships between data objects.
  3. Create a sitemap that describes navigation, page types, and page templates.

IA discovery provides a clear picture of the destination for content on the new website. Migration Discovery reviews the source content to better understand what content needs to be migrated, how data fields will be mapped between the source and destination data objects, and define data processing functions. That last point can get very complex, including things like cleaning up HTML structure, relinking inline media files, creating or linking relationships to other data objects (e.g. taxonomy terms), and correcting known spelling inconsistencies. It is also advisable to clean up existing content before a migration, which can really make that job easier and less time-consuming.

Migration isn't always doom and gloom. Some site migrations can utilize simple data import methods if they aren't too complex, like a flat list of blog entries. Some sites may skip migration all together and simply recreate content as needed with cheaper data entry resources.

How do we migrate functionality?

Drupal intentionally does not provide backward compatibility for code between versions. Granted, some Drupal functions and contributed code may retain the same function signatures between versions, but this is never guaranteed. Therefore, an evaluation of the Drupal 6 modules and themes is required to determine the development effort required to bring required logic to the newer Drupal website. Anything that isn't needed is simply disregarded. Contributed code that has a newer version equivalent takes little to no effort (e.g. the Google Analytics module). Some contributed code doesn't have a stable equivalent for a newer version of Drupal (e.g. the Ad module) and either needs to be ported or an alternative solution should be considered (e.g.OpenX). Tools like the Coder module can help developers understand some changes that need to be made in their Drupal 6 module if upgrading to Drupal 7.

What should we do when yet another version of Drupal is released?

Prepare for change. Like all software, there is a lifecycle for Drupal. Design and technology changes impact a website's relevance and the cost to maintain it. It is best to plan for a new website every three to five years and to maintain existing websites throughout each period.

How do we train our staff?

Develop a curriculum, which is something where Drupal Connect can assist. There are existing training materials and some material should be created for specific website configurations. The three questions we tend to ask that helps targeted learning:

  1. Who needs to be trained?
  2. What do they need to know or to be able to do?
  3. What do they currently know?

The answers should be detailed, which will help minimize the learning effort to pertinent material. It's also best to "train the trainer". Other people (particularly new staff) will need to be trained in the future, so it's best to empower individuals with the ability to pass on knowledge and procedures.

Prepare to move away from Drupal 6

In short, the time is now. Get ready to move to a new platform. Since we started talking about Drupal 8, that brings us to our next question: Should we use Drupal 8 for our project?