Upgrading Drupal sites between major versions can be tricky. The community of developers that numbers in the thousands has taken great care to maintain upgrade path between adjacent versions of the content management system. This is especially true of Drupal's core, though one must go through each version to get to the destination. (An example: going from Drupal 5 to Drupal 7 requires passing through Drupal 6.) Contributed module upgrades take place with a very slight degree of peril, though typically a developer will include upgrade paths between major versions. Though incredibly rare, some modules will not upgrade their database to the new version of the module, and even then someone will flag it as an issue and it will get resolved.

Official Documentation

If you came here looking for guidance on upgrading your Drupal site, please consider visiting the official documentation at Drupal.org. The following only deals with two specific cases that may not apply to your site.

Upgrading Roland's Site

Some upgrades are very easy, however. Upgrading Roland's website was a breeze. My method:

1. install a fresh copy of Drupal 7 on my local environment
2. copy his site's database to my computer, and import into a fresh database
3. run the update.php script, taking notes if any errors pop up. If they do, either fix them or make a note of what to do when it comes to do it for real
4. do another test upgrade locally, just to make sure
5. clear out temporary data like sessions and cache on the local install
6. export the database and upload it to Roland's server
7. install Drupal 7 fresh with a very few modules (WYSIWYG, which he uses, and Views, which he doesn't)
8. import the database, and run update.php, perform the fixes from the earlier notes
9. show Roland what it looks like, then make the necessary switches behind the scenes to make it live on the rolandtanglao.com domain

(To keep it brief, I've excluded the steps about virtual host files on his server and faking a subdomain with my /etc/hosts file on my own computer.)

One funny bug that I couldn't put my finger on, which came up with another client's upgrade, was the need to save a node in order for URL aliases to kick in. If it comes up again, I'll dig further into Drupal.org's issue queue. One thing you learn quickly about the issue queue is that URL aliases are a common problem.

Upgrading Just a Gwai Lo (Eventually)

Other upgrades are not so easy. For the better part of a year, I've been working on porting over Just a Gwai Lo to Drupal 7. Working against me are the following:

• my SkyTrain Explorer page, which contains custom PHP to display the hierarchical book view plus the use of Viewfield to show station pages (example). I cherish that section of my website, and would like to see it come over in an upgrade.
• a few custom content types need their modules to either be upgraded or provide an upgrade path. I use Embedded Media Field in conjunction with Feeds to display my own photos posted to Flickr. I will need to move to the Media module along with Media: Flickr to do the same thing. There is an issue asking for an upgrade path, which I continue to monitor.
• I have a spreadsheet for other modules, which, for a laugh, I've made public. An explanation of my methodology follows.

The Spreadsheet

Every major upgrade to a site I work on gets a spreadsheet. Though some upgrades will need to require certain added and maintained functionality, those same upgrades can drop functionality too. It's usually best to conceive of features first, then map modules to them. Since I already know what I want (essentially status quo), the module-based approach stays for this spreadsheet.

Using my personal site as the example, I'll go through my research process.

1. Make a raw list of the modules used. I'm OK with doing this manually, since it gives me a chance to think through whether installing it in the first place was a good idea.
2. Highlight in blue the modules that are either custom modules (there's always at least one in all of my projects, personal and otherwise) or ones I can drop. In my case, I have the Fenchurch module (named after my first VPS, which was in turn named after Fenchurch in Hitchhiker's Guide to the Galaxy), which adds some small things to forms and whatnot, to upgrade. I'll also likely drop Better Formats since Drupal 7 adds most of what I need.
3. Highlight in red the modules that are not ready and that I need (called blockers).
4. Highlight in yellow the modules that I'm not sure are ready or that I don't know whether I'll need.
5. Highlight in green the modules that are ready for Drupal 7. Developmental and bet versions of modules are OK to use as long as they work. I always evaluate modules on their merits, not what their version number says. Green means go!
6. A row for notes, such as links to issue queues or which modules to use instead, or what I can do to make them ready.

As soon as it's all green, then it's time to do the work of upgrading. I then follow the same general process as outlined for Roland's site, though usually quite a few more times, since more things tend to go wrong

The spreadsheet definitely has flaws. Breaking it into a sheet per sections (such as one for content, another for each custom module) might make sense if only the format allowed for freer form of information. I remain a fan of Google Docs and its sister service Sites, so one can combine the two and embed a spreadsheet into a more freeform Site, for example. The online spreadsheet allows for live collaboration, though I have no experience with it in the context of upgrading a Drupal site.

Spreadsheets are most useful when a project requires a arithmetic calculation. I use them a lot for trip budgets, though only to get a rough sense of how much it might cost in total. This form of spreadsheet works as a status dashboard.

Temptations

The roadblocks and the work to overcome them tempted me to archive the site and start all over. A complete restart would have, in theory, allowed me to concentrate on writing instead of futzing with the site's details. On the other hand, most of what I learn about Drupal's capabilities comes through experimentation and breaking, then fixing, things. While I've archived Drupal sites in the past (such as PDXphiles and improvident lackwit), and a method exists for doing so (and possibly another using a module intended for caching), I can't be sure that my thousands of posts and thousands of tags will come in properly, not to mention that changing one little thing could mean having to do the archiving process all over again. And I don't even want to think about redirecting to a subdomain like archive.justagwailo.com but also ensuring that any new justagwailo.com URLs work.

Looking Forward to Drupal 7

Assuming all goes well, I look forward to using some of the RDF features baked into Drupal 7. I experiment with semantic markup in my reviews section, with most using microformats, at least one what I believe to be RDFa (I'm never really sure, but that's why I experiment!), and I hope in the future using some of HTML5's features such as micro data. Ideally the next incarnation of this site will feature stripped-down theme. Still pink, of course.