Tại sao chúng ta skipping upgrading to Drupal 7

This website was created using Drupal 6. Normally Drupal sites get upgraded to each new major version. This can be complex, but manageable with an upgrade path one can follow. Upgrading is important because the Drupal community only supports the current release and the previous one. In other words the day Drupal 8 is released our Drupal 6 site will no longer be supported. My current best guess is that D8 will be released mid 2014.

With the end of support for D6 looming you might expect that we would already have upgraded to Drupal 7, or at least be in the process of doing so. Instead we plan to skip D7 and go straight from D6 to D8. Why? Because upgrading to D7 is difficult and we think D7 will give us too little gain at too high a cost.

When I polled my peers they all had horror stories of upgrades that were more complex, expensive and time-consuming than expected. The differences between D6 and D7 were too pronounced. The result was an increasing consensus that it's faster and cheaper to completely redevelop sites than to upgrade them. They would build the site from scratch in D7, then port over the design and migrate the D6 content to the new site.

In other words the only difference between this upgrade-by-redevelopment process and a brand new "do over" site is the creation and implementation of a brand new design, which in terms of costs is likely about 20% of the overall outlay. Further, there is now also only one difference between upgrading to D7 and upgrading to D8, namely the complexities that arise from being on an unsupported version of D6 for some period of time.

To clarify this, here's one possible optimistic scenario: D8 gets released in July 2014 and D6 is no longer supported, the D8 modules we need catch up around January of 2015 and we start the move to D8, we finish in July, at which point we have been on an unsupported version of Drupal for a year.

Being unsupported means most D6 module developers will stop maintaining their D6 modules (in fact many already have) and more critically it means no more official security patches on both core and most modules if critical issues arise. There is assuredly risk in that.

However, the level of concern I found is low. D6 will still work exactly the same as it does now. Being unsupported does not mean broken. D6 is extremely stable and highly unlikely to fail. In the improbable event that something does go wrong there will almost certainly be unofficial patches contributed by the community.

MMT are far from alone in this conundrum. During the Core developer discussion at DrupalCon Portland earlier this year someone asked whether it was worth upgrading to D7 or if we should wait for D8. A panelist answered that upgrading to D7 could be good. Several other on either side of him shook their heads vigorously in dissent and then chimed in that skipping D7 would probably be best for most folks. (You can listen to the audio for both sides of the argument here at about 52:15).

The problem is so widespread that there is significant discussion about extending support for D6 beyond the usual timeframe. An online discussionspurred so much conversation that the issue was moved to the core queue.

Added to this comes a commitment from Dries, the creator of Drupal, that his firm Acquia would help get Migrate module functionality into core, including support for D6 to D8 migrations. The project he's committing to support is IMP. Drupal-to-Drupal migration being moved into core is a big deal and indicates the seriousness with which the community views this functionality in general, but the D6 to D8 piece also speaks to top-level recognition in the community that skipping D7 is going to be very common.

We still considered switching to D7 because it would give us stability as it will likely remain supported for several more years. It's difficult not knowing when D8 will come out and just how long your D6 site will be unsupported. DrupalReleaseDate.com currently has no prediction and the Drupal 8 page has no estimated launch date.

Then you face an additional six months or so of waiting for the modules to catch up, even before you start planning for resources, time, etc to get the site rebuilt. This makes planning difficult. We can't set a date for the beginning of our new project and we could end up being on an unsupported version of Drupal for two years or more.

D7 also has better responsive themes (designs that work on all devices), better UI and UX, newer functionality, more current support and a few more niceties. In our case our need for these is very low, so this is no more than a bonus. With little functional gain with D7 to offset the staff learning curve and the time and resources needed to get a site that looks like the old one but has all the growing pains of a new one, and you get a net loss for us.

We still almost upgraded to D7 anyway, because Marie is retiring as Communications Director and this site is part of communications. We didn't want her replacement to face such a complex and involved project so soon after taking the role. We hired an experienced vendor to give us an estimate of the work and the result was a huge number that made a D7 upgrade unjustifiable.

We still plan to stick with Drupal, despite these challenges. While we're not thrilled about all this, we do get it. The improvements to D7 that make upgrading so hard are the foundations on which the excellence of D8 is built. This sort of upgrade complexity is common in the software world whenever projects focus on the growth of the software in preference to the bloat and complexity that follows maintaining backward compatibility.

Unlike a D7 upgrade, when we have D8 I'm almost certain that the new Communications Director will be impressed by the differences. D8 is primed for devices, more customizable than ever, has improved UX including inline editing, web services built in, improved accessibility support and more. The useful and positive differences will be obvious.

So there you have it. Our poor new Communications Director who has not yet even been hired will have a big decision to make soon after joining, and it will probably involve a site redesign and a challenging early project. On the flip side it presents the new director with a big opportunity to take real ownership of the site.

Until then we're hoping that the Drupal community will be a big help to us with extended support for D6 and help with that inevitable migration to D8. Failing that we may have to hedge our bets and set up a support contract with an outside vendor as a kind of insurance policy.