Any way you do it, upgrading an organizational website to a new major version of Drupal - for example, from Drupal 5 or 6 to Drupal 7 - is a significant task. Before digging in and even before planning out the work, it's worth asking some larger questions: What do we hope to achieve by upgrading? If we were building the site from scratch now, how would we do it? How can we get the most benefit out of upgrading? What major improvements should we consider making in the process?
What's involved in upgrading?
The first important step is to understand in general what upgrading a Drupal site means.
If there's one major misconception about upgrading, it's that reproducing what's already on a site in the old version will be the quick and easy part. Pretty much just click a button, right?
Unfortunately, wrong. Very wrong.
With some kinds of software - word processors, for example - upgrading from one version to another can be fairly painless, or can even pass almost entirely unnoticed. You download the new version, install it, open up the documents you produced in the old version, and away you go.
Not so with content management systems (CMSs), and particularly not so with Drupal. A typical Drupal site is made with multiple modules in addition to the core Drupal download. Some of these additional modules may not even exist in the new version. Even if they do exist, they may no longer be a good choice. Even if they exist and are still a viable choice, a lot may have changed and likely you'll need to redo configuration.
In most cases, when upgrading major versions, far from just pressing a button, you're in for a lot of site building work just to get the equivalent of what you already have in the old version. A pain? For sure. But, apparently, that's the price of progress.
In short, in the large majority of cases, upgrading means rebuilding a site--carrying forward a lot of the content and data, but into a new site that may well take as much or more effort to build as the original site.
The good news is, given improvements that have been made meantime in the software, you'll likely get some significant extras this time for your investment.
Which version to upgrade to?
An important factor to keep in mind is the current point in the Drupal release cycle. Now, for example, we're at the tail end of the Drupal 6 cycle. Coming in at the end of a cycle has some advantages: Drupal 6 is very stable and almost all important modules have been fully upgraded to Drupal 6. But it also has costs. Drupal 6 is already aging. Even before Drupal 7 was released in January 2011, the focus of innovation had already moved to this new version. There are important modules that may be available only for Drupal 7--e.g., the media module, which promises to revolutionize image, audio, video, and other media handling and embedding in Drupal.
Depending on the specific needs of the site, there might be reasons not to go to Drupal 7 yet. Maybe the modules you need for a key area of functionality aren't yet available in Drupal 7. If so, your best bet is to put off upgrading for a bit, until those modules are further along. Or if you really need to upgrade from Drupal 5 now, a key goal in upgrading to Drupal 6 should be to ease future upgrades, by carefully planning toward Drupal 7 solutions. By doing so, you can bring your site more and more tightly in line with the whole point of open source: shared solutions that are collectively developed and maintained, rather than private, custom code.
Some of the more obvious reasons to upgrade a Drupal site include:
- Get access to new features. Many new features are available in the current Drupal version that weren’t available previously. By upgrading, you can get access to these features "for free".
- Receive regular updates. Older versions (core and contributed modules) receives less and less attention and upgrading. Some modules you're currently using may no longer be maintained, or if they are maintained they may not be for long.
But there are also less obvious but potentially more important benefits, including:
- Streamlined site. By upgrading, you may be able to remove previous customizations, replacing them with standard solutions available in the new version.
- New approaches. A lot of innovation happens between one Drupal version and the next, and sometimes this innovation opens up whole new vistas for site development. In Drupal 6, such innovation included: vastly improved theme system and stable and proven base themes; the Features system, which allows major components of a sites configuration to be managed in code, facilitating both upgrades and the sharing of features between different sites; and the Pressflow Drupal distribution for high performance sites. Drupal 7 innovation included improved file handling and native support for adding fields to users and taxonomy terms as well as content types.
- Distributions. In building a new site, you may be able to take advantage of one of the expanding number of Drupal distributions, which provide at least a big leg up towards building a site to your needs.
Together, this second set of factors can produce a series of very significant benefits.
- Lower maintenance costs, as there is less custom code to maintain.
- Better stability, as more of the site's code is publicly tested and maintained.
- Better performance due to improvements in the code.
- Better solutions, as the newly available solutions will in many cases be fuller or more feature rich, particularly if previous ones were built in-house.
- Reduced reliance on a particular expertise, since the site uses more standard solutions and less custom code.
- Easier upgrade path in future, as the site is now much less reliant on custom code.
- Streamlined future development that can focus effort on just the specific new needs rather than carrying forward previous customizations.
In short: if you're taking the time and energy to upgrade, you can and probably should also look at this as an opportunity to make significant improvements, ones that not only may benefit the site in the long term but may also prove to require less work and expense than a straight upgrade of the existing code.
Approach: Where to Start?
What’s the best place to start upgrading your site?
The most obvious answer would be, with what you already have--the code of the current sites, along with their databases and files. Specifically, you could hire a developer or team to dig into the task of upgrading the code that drives the current site, including selecting new versions of the modules that were used and upgrading customizations that may have been made to Drupal core and contrib.
But, as is often the case, the obvious answer is not necessarily the best.
This may be an approach that will not appeal to you and your team....
Drupal 6 is in many ways profoundly different from Drupal 5, to the point that trying to reverse engineer D5 hacks to complement D6 may be a quite inefficient way to go. One thing to consider is that existing D6-based solutions may provide ready replacements for some of the D5 hacks. In some ways, you may end up "crossgrading" rather than "upgrading" much of your site.
So consider wiping the code base entirely (not the database, though) and re-implementing in Drupal 6. If your D5 hacks did not result in alterations to the database structure, you can simply perform a stock D6 upgrade process and then implement through contributed modules and a new or refactored theme the various end results those hacks were trying to achieve. This way you can embrace what D6 offers first before resorting to coding up custom module implementations.
In other words, start with the goals, the use cases, the desired results, and don't assume that the D5 hack logic will carry over into D6 modules. Your content lives in the database and uploaded files. Treat the rest of your site as disposable — to be used as notes but not necessarily as technical architecture.
While it might seem unorthodox, Laura's advice is probably a really good starting point in planning a Drupal site upgrade. To get the most out of the process, it's important to keep an open mind in terms of the fine details of appearance or architecture. Your primary questions should be: for each problem, what are the standard, proven, available solutions? Do these meet our goals and use cases? If not fully, what small tweaks would be needed?
I've written more on this subject in a couple of blog posts:
Theming: Selecting a base theme
If you already have a custom theme, upgrading it to the new version will be a significant part of your upgrade task. So again, before digging straight into the work, it's worth pausing to look at how the theme is implemented and what improvements you might be able to make.
Specifically, if the theme is not already based on one of the leading base theme systems, it's probably time to consider adopting one.
A base theme system is a specialized Drupal theme designed not to be used directly on a site but rather to be a building block for other themes. Generally it itself has little or nothing in the way of styling, but provides all the flexibility and selectors that are needed to build out a site however you might want it to look.
There are several proven theming systems for Drupal 6, with Zen and Fusion being the leaders in both site installs and documentation. By converting your custom theme to use one of the leading base theme systems, you might be able to reduce your custom theme work to one or two stylesheets and some images, avoiding partially or even completely the need to write and maintain custom templates.
As Laura Scott suggested, the most effective way of upgrading from a previous version may be to build a new site from scratch and then migrate the old content. This is exactly what prominent Drupal contributor Nate Haug demonstrated in a blog post Direct Drupal 5 to Drupal 7 Migration in 24hrs. While he skipped a major version, the same approach could be taken when upgrading from Drupal 6 to 7.
Migrating without upgrading site code
If you've created a new site and need to migrate in your old content and media assets, you could end up with custom scripts that read in your old data and save it to the data structures of your new site. If you have more complex data structures, you might look at the Migrate module, which provides a set of tools to facilitate data migration into Drupal.
Selecting a distribution
Questions to look at in evaluating distributions include:
- Does the distribution match our use case? E.g. for a publication-focused site, there are multiple news or publication distributions.
- What version of Drupal is it in? You may wish to move to Drupal 7, but many distributions are still available only for Drupal 6.
- What kinds of hosting and support options are available?
Keep in mind that, if you have very specific needs, a distribution is likely to get you only part way and you may need to further customize it. Still, if you find a distribution that's a good match for your needs, you might be able to get up and going relatively quickly. From there, you can hive off the migration of your old content as a separate sub-project.
Beyond the modules in use and the content, a Drupal site is built from components that are constructed through site configuration--views, content types, fields, panels, image style presets, etc. These components are stored in the site database, a fact that presents challenges when upgrading. If you've opted against the "leapfrog" approach, after completing the process of upgrading and slowly configuring components in the new version you'll face the issue of how to integrate the updated content that's still in the old version.
In Drupal 6 and 7, the Features module addresses this problem and can be a key tool in upgrading. As an added bonus, it can help immensely in continuing to maintain and develop your site beyond the upgrade.
Features allows automated conversion of a large amount of site configuration to code. For example, views, content types and their fields, roles, and permissions can all be pulled out of the database into code, while new areas of Features support are being added all the time.
The process of upgrading then becomes:
- Upgrade a copy of the site to the new version of Drupal.
- In the new site, upgrade all the components that Features supports.
- Create features including these components so that they are exported to code. You can now scrap the copy of the site you upgraded. Everything you need is in the features.
- Once everything is ready, upgrade the live site again to the new version, and - presto! - switch on the features you built. You end up with the latest version of your content and your upgraded site components happily reunited.
Features is valuable on a single site, where it can be used to facilitate staging. When a change needs to be made to e.g. a content type or view, the change can be made and tested on a development version of the site, then passed via Features to a QA version of the site for testing. Only when it's fully tested does it then get passed to the live site--all without any repeated manual configuration.
Features are all the more valuable if you have a need of multiple related sites. While each site has its unique needs, much is shared in common. With features, launching a new site could be as easy as selecting the features to enable, enabling them, and then adding some small custom tweaks. Even better, from there on, most maintenance of the new site would be automatically received as updates from the main site's features.
The biggest performance advance in Drupal 6 actually comes from Drupal 7. It's the Pressflow distribution of Drupal 6, which includes "backports" (adaptations for an earlier version) of major performance improvements that are part of Drupal 7.
Pressflow is designed to work seamlessly with "reverse proxy" caching software, providing potentially huge performance gains. The reverse proxy software most used with Pressflow is Varnish.
The gains in performance, stability, and ease of maintenance from a base theme, Features, and Pressflow + Varnish are on their own great incentives to upgrade to a new version of Drupal. And they're only a few of the opportunities you'll identify as you dig into upgrade planning.
[First posted June 2010 with minor updates in 2011]