Upgrading a blog-based Drupal site from 6 to 7

As mentioned previously, this site was recently upgraded from Drupal 6 to Drupal 7. Here's a more in-depth post explaining how I did it, and what the experience was like. Note that I use "upgraded", as distinct from "migrated", because I didn't create a brand new D7 site and push the content into it. For better or worse, I followed the actual d.o recommended upgrade path for major releases.

To avoid having to repeat the tedious work of database upgrades and code downloads, again and again for each different permutation of preferred modules, I used the drush site-upgrade command. I can really recommend it: while it's no silver bullet, it at least permits you to set a site upgrade running, then do other more productive tasks while it completes instead of having to babysit the process. drush site-upgrade very closely follows the Drupal 7.x major upgrade procedure described in UPGRADE.txt, which means that you can at least go through its output and dissect precisely what it was doing at each point.

Below, then, is my direct experience of the upgrade process: it hardly constitutes recommended best practice, as it does detail some of my slip-ups as well. If you're going to follow something step by step, then read UPGRADE.txt instead.

Before you start: just give it a whirl

Because drush site-upgrade takes away a lot of the pain of upgrading, and because it does so in a separate D7 instance that you specify with Drush site aliases, then it's tempting to just give it a try. I did, and I can heartily recommend doing so: it's the best way of discovering the biggest, most problematic hurdles between you and a D7 site.

I think in theory drush site-upgrade should upgrade all the modules in your D6 site first, before beginning on the major site upgrade. But you should also consider doing that yourself on your current site, especially as it's a (somewhat time-consuming) no-brainer that site-upgrade is always going to have to perform.

Running this command with no options means that Drush might request your input, so you probably want to babysit this trial upgrade and see what happens.

Preparing your site(s)

Along with upgrading all the contributed modules and core in your D6 site, you should also look at a few other tasks which the initial trial upgrade should have highlighted:

• Create an empty target Drupal 7 database. Unless you specify a particular configuration in your site alias for this, it will need to have the name "Site alias name with punctuation removed" + "db", and the same access credentials as your D6 website. My site alias was "@jps7.local", which meant that I needed a database called "jps7localdb".
• If you have any file include()s in settings.php, remove them or comment them out. This file gets copied over verbatim into your new D7 site, so it's possible that such includes will break. Not a serious problem, but it does make the upgrade output very noisy with unnecessary PHP warnings.
• Download and enable the schema module, and use it to fix any inconsistencies between the D6 database as it should be, and the database as it really is. If it looks like a load of tables have been left behind by a long-gone contrib module, download that module and explicitly uninstall it, as this will also clear up any system variables it might have set. Disable and uninstall it when you're done.
• Disable your custom theme. It's not essential, but having a custom theme did lead to some loss of themeing for me on my new D7 website, even though drush site-upgrade claims to downgrade the theme to core Garland.
• Disable and uninstall as many contrib modules as you can. Because my configuration was straightforward, I uninstalled the whole of Display Suite including Node Displays etc, because my trial site upgrade simply could not deal with it: there seems to be a relevant bug in the issue queue, but this was the easiest solution for me. I appreciate this was a pretty drastic move, but for a blog-based website I didn't foresee any serious consequences of redoing the DS configuration by hand. I also got uninstalled Image Gallery and CCK Redirection, although again this might be too drastic for your website. Remember to uninstall any helper modules: schema, as discussed above; but also devel, coder and any testing modules.
• Delete any content types you don't use. The same goes for any input formats, taxonomies etc: anything that you really don't need to migrate. If it has potential to break your migration, get rid of it now rather than later.

Successful (or at any rate completed) site upgrade

With the above changes made to the website, I ran drush site-upgrade @site.alias --auto. This extra flag means that the process runs with as little input from you as possible: in fact, assuming you've fixed any fatal errors mentioned above

This did mean that the following assumptions were made by the Drush command:

• I would fix any hacks to core (htaccess, robots.txt etc.)
• I would also copy across sites/files and sites/all/libraries
• The default CCK-equivalent modules in D7 were used: specifically node_ and user_reference, rather than entityreference.
• Automatic CCK field migration was performed on any fields that could be found, using D7's instance of CCK and the cck_migrate module. This migration of variable reliability, but improved by assuming the defaults above.

Immediate fixes on the D7 site

Once the upgrade happened, I concentrated on just getting a working D7 site with the content looking right to the site visitor. For that, I had to do the following:

• As mentioned above, my uploaded files and my libraries folder had not been copied over by the automated process, and I had to do that myself.
• My themeing was largely broken and CSS-free. This might have been because I was using the core Color module. Anyway, (re-)saving Garland's theme settings fixed it straight away. 
• To get Geshi syntax highlighting working again, I had to enable it on the text formats, and then administer Geshi and add at least one other language to the list of available languages. I think the latter is a minor bug in the CSS workflow of Drupal's geshi module.
• I also downloaded and enabled the media module and file_entity, sooner rather than later. To be honest, I couldn't tell you for certain whether this was a requirement of any of the procedures here as such. I just knew I was probably going to need something to manage documents and images.

This was the point at which I switched the codebases over on the live site, and my web presence was from that point on entirely in Drupal 7!

Improving admin and more niggles

There were still a few problems with the site; in fact, I'm still shaking a few bugs out now. None of them were really serious, but they did all have to be dealt with, and I did so as follows:

• I was using the image module for image management: I know, old-skool, right? This meant that to have my images managed and appearing in Media,  image nodes had to be converted to managed files. The field convert module helps with this; for a more detailed howto, read this excellent blogpost by Laura Scott.
• I lost my WYSIWYG profile for full text. I recreated this manually.
• Pathauto was failing because token syntax has changed radically (arguably for the better) but this was not migrated by the upgrade procedure. To fix, I manually edited the tokens to use the new syntax.
• My migrated images were managed OK, but the actual page for each image entity wasn't rendering the image. This was because each image's bundle type was set to "undefined" in the file_managed table. This was probably the worst problem to solve for anyone not well versed in databases, as it required a (relatively straightforward) SQL UPDATE statement.

Embracing Drupal 7

Finally, it was time to start taking advantage of some of the simplest improvements with Drupal 7. This included the following:

• Toolbar and shortcut module, to provide an "admin menu" experience across the top of the site
• Contextual links, for quick links to edit e.g. blocks on a page, or a view listing.
• An administrator role (under Configuration > Account settings), so that whenever a new module is enabled users with that role get all permissions for it straight away
• Update emails, warning me of important security updates, once per week (although all those decisions are configurable to taste)
• Media module, as mentioned above
• Views had automatically upgraded to version 3, which includes a huge and improving overhaul of the UI. 

There are a lot more improvements I can make going forwards, but this is where I drew a line under my personal upgrade project, and called it: success.

Summary

Upgrading a simple site from Drupal 6 to Drupal 7 is certainly comparable, if not preferable, to a content migration. The above took me around a working day and a half, split over a few nights. Personally, I can recommend it, as I felt at the end that, once everything had obviously migrated correctly, I had a very robust D7 setup.

Obviously if your site is more complicated, then automatic upgrading might be less straightforward. Almost certainly you'll need to keep Display Suite in place, which means solving the bug I encountered. And if you've got any custom code or (more likely) themeing, then upgrading this to work with Drupal 7's new APIs and themeing layer will not be at all straightforward.

But much of that would be the case whether you upgraded or merely migrated content. So do consider an upgrade: I found out from my own very meagre personal experience at the Drupalcon Copenhagen code sprint that a huge amount of work has been put into the upgrade path; it really seems to have paid off.