I am just taking on responsibility for a Drupal 6.2 site. It has some custom modules and some quite poorly organised code which I am working with developers to improve alongside developing new features to the site. And being fairly new to Drupal I am just getting my head around how it all hangs together.

One of the things I want to assess is when we should be planning to migrate to Version 7.

  1. Is it a reasonable assumption that, as a commercial website, we should upgrade to version 7 as support for 6 drops away over the next year or so?

  2. Is it possible to develop and refactor on version 6 in such a way to make that migration as painless as possible when we get to it?

  3. Is there anything else I should consider as I plan the development roadmap over the next 12 months?

  • I posted some quick thoughts below. I could probably expand a bit, but let me know if you have any questions on my answer, and I'll try to take them into account as I update.
    – Letharion
    Nov 26, 2012 at 11:23
  • Unrelated to the actual migration. If your site is actually running 6.2, you have some serious security problems you need to handle ASAP.
    – Letharion
    Dec 3, 2012 at 12:14

1 Answer 1


Should you upgrade?

All contrib modules will slowly shift major version. If you don't follow suit, you risk needing to re-invent the wheel more often than otherwise necessary. Most module maintainers have since long ago shifted focus to D7. A few have even begun maintaining their D8 version.

D6 will become unsupported, and have no more security updates after D8 is released.

How do we make it painless?

I don't think there's an answer that can be applied across all sites, but here are some general guidelines.

  1. Features needs to be "released" (warning, lots of reading), and then upgraded by their providing module, and finally re-added to their respective features.
  2. Use the Migrate module to easily test getting content over.
  3. If possible, run both versions at the same time. Hide the fact as well as you can, possibly using a reverse proxy. This is non-trivial to accomplish, but ensures that when you move your last piece of functionality from D6 to D7, parts of your D7 site has been live for a long while already, and you know that it's stable. As one quick example of a relatively general measure one can take to ease this, Entity API can allow you to redefine where an entity reads/writes its data.
  4. Often Contrib-space will solve a common problem that Core later decides to incorporate. Switching to these techniques for problem solving everywhere it's relevant will allow you to "partly" upgrade a current DX site to DX + 1, making the gap during the complete upgrade much smaller. Two examples of this are below, but this list could probably be much longer:
    1. Use Panels and Page manager instead of modules like Context and Spaces. The Pm+P approach to site building is the foundation of a huge re-write of core for D8.
    2. Use Guzzle instead of Http Client. Guzzle is the official http-client for Drupal 8.

Anything else?

Nothing that comes to mind at the moment.

  • Thanks for the reading .. interesting stuff. Yes, I have been thinking about running both versions. Whether using a reverse proxy as you suggest or other methods, a problem I am seeing in Drupal having to split data across two different databases/schemas. Unless I am missing a way around this?
    – harunahi
    Nov 26, 2012 at 13:55
  • No, you're right, hence the "non-trivial" note. There's a large number of things one can do to make it easier, but what exactly can be done will depend greatly on the site itself. I added a brief note on entity api in the answer, with regard to this.
    – Letharion
    Dec 3, 2012 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.