The following post originally appeared on the GoingOn.com blog.

After more than a year of continuous investment in GoingOn’s Drupal 6 platform, the idea of upgrading to Drupal 7 is incredibly daunting. We have custom modules from form behaviors down to the access layer, we have features encapsulating hundreds of exported components, and an aggressive feature release schedule that does not set aside 6 months for a complete rewrite of the codebase just for a new version of Drupal. What to do?

We’ve been playing around with the idea of iterating our Drupal 6 platform toward Drupal 7. By pulling markup, design patterns, APIs, and architecture in Drupal 7 down into platform incrementally, we hope to shorten the final leap that will come when upgrading the entire system.

Driving Current Drupal Version Closer to Expected Drupal Version

Usability metaphors in site architecture and development practices sometimes works.

The extra work involved might well take more aggregate time to develop, but that time will be amortized across small, manageable pieces that can be more intelligently inserted into the development schedule.

Here are the backport opportunities we’ve identified:

Design Patterns

Vertical Tabs, Contextual Links, Toolbar, Elements, Contact

Many of the design patterns in Drupal 7 are available through a combination of backport modules and creative theming. The Toolbar module doesn’t have a backport, but peeking into the repository for the Admin Menu I spy something that makes it look like D7’s Toolbar.

By pulling these patterns from D7, we gain two benefits:

• We can build out the rest of our user interface around D7 design assumptions, instead of D6 assumptions. This will save effort in a theme redesign and upgrade.

• We can trickle D7 designs in front of our users, allowing them to adjust to a few changes ahead of time instead of waking up one morning to find a completely rearranged website.

Our use of Vertical Tabs liberally around node forms is not cutting edge, but has allowed us to package complex forms with a Drupal 7 pattern, instead of resorting to harder-to-maintain multi-step forms.

System Plumbing*

Drupal Queue, Admin Role, Password, File, Mail System, Simpletest

The flow of code that goes on under the hood has a few interface points where it is relatively easy to grab a D6 backport and make your modules look just a little more like Drupal 7 code.

Judging by an IRC chat I just overheard the files[] mechanism might be dropped for something simpler in one of the next few point releases.

I hadn’t realized until writing this that URL Alter was cooked into core. The ability to ignore the special rules around around custom_url_rewrite_inbound()  and go straight for hook_url_inbound_alter() is great. It also makes our custom code using it D7 ready.

* For purposes of this post, plumbing refers to the flow of code and data between its storage and the rendering process. Pretty broad category.

Database & Performance

Pressflow, DBTNG, Cache Backport

You can get a lot closer to Drupal 7 performance behaviors simply by using Pressflow, which has held backports from and experiments for Drupal 7 for years.

Most members of the Drupal community are already well aware that if performance is important for your project, grabbing Pressflow is an easy and non-threatening win. By using it for D6, you will be coding against session handling that is closer to D7’s, as well as being able to make use of other performance enhancing systems, such as serving images via Varnish as an ongoing improvement across your upgrade process.

Contrib Backports

This is a category of another sort. Usually when you think about Contrib modules for D7, you are looking for the upgraded version of the modules you are already using. However, what if there is a D7 module you want to use, or at least, could use? The D6 version of that module has just become a backport to facilitate your upgrade path.

This is a good solution to deal with unmaintained modules that have since been eclipsed by more energetic projects, as well as custom code you don’t really want to see again. We’re pretty excited to start playing with the Boxes module for this reason.

I’m going to skip listing competing modules in which one has an upgrade path and not the other. The Similar Module Review group might have information that will help you find competing modules that may just be a cleaner path forward.

Thanks to Lullabot’s Friday Roundup (June 24th) for pointing out backports of Password, Contact, and File. Thanks to David Reid for creating and maintaining what seems like most of these modules.

So, did this work? We are still putting together the details of this plan. A followup post in a few months will report on how it goes. If you have thoughts about this approach to the upgrade, additional worthwhile backports, or alternate ideas on how to make the time for an upgrade, please post a comment!

Terms: drupaldrupal6drupal7upgrade