Upgrading a Drupal 6 website to Drupal 7 using Drush

Overview

So we want to upgrade from Drupal 6 up to Drupal 7. Here's the thing with a major upgrade, it isn't just Drupal core that needs upgrading, it's all the modules and themes as well. Whilst upgrading Drupal core, contributed modules need to be disabled. Many modules and certainly core will need to update the database when the code is upgraded. After upgrading core, you then need to replace every modules code with the Drupal 7 version. With many Drupal websites having 60+ modules installed, this can be a somewhat time consuming task. Not to mention ripe for human error. 

Thankfully the gods behind Drupal have thought this through. Admittedly this post will only be any good to you if you have experience on the command line and have Drush installed. If you have Drush then you no doubt have the root level access that will be required as well. 

So here is the plan:

1. Make a copy of the Drupal 6 production website.
2. Remove as many modules as possible from the copy of production.
3. Upgrade the copy of production to Drupal 7

Install "Site upgrade" for Drush

From outside of any Drupal install on your server, run this:

drush dl drush_sup

That's it, we have just installed it!

Create empty databases

I'm not going to cover the how for this because if you're reading this, i'm assuming you know that. You will need to create the empty database and user for two Drupal websites. 

The first will be used for a copy of our production site because we will need to work on it prior to the upgrade. The second will be used when we upgrade the copy of production to Drupal 7. 

Create your Drush aliases

What is a Drush Alias?

A Drush alias is used to point a Drush command at a specific Drupal installation. We use it by adding a preceeding @ to the alias like @aliasname. So instead of having to be within a working Drupal directory, we can be anywhere. Just add the alias name after "drush" in a command. For example "drush @aliasname status".

Create the aliases

Edit / create the alias file

nano /usr/share/pear/drush/aliases.drushrc.php

An example alias file:

 'example.com',
    'root' => '/var/www/example.com/prod/',
    'db-url' => 'mysql://user:password@localhost/dbname',
  );
 
$aliases['d6dev'] = array(
    'uri' => 'dev.example.com',
    'root' => '/var/www/example.com/dev/',
    'db-url' => 'mysql://user:password@localhost/dbname',
  );
 
$aliases['d7dev'] = array(
    'uri' => 'd7.example.com',
    'root' => '/var/www/example.com/d7',
    'db-url' => 'mysql://user:password@localhost/dbname',
  );

There should be a opening tag (<?php) but no closing php tag (?>) and the database urls need your actual credentials. It's just like the Drupal 6 db_url string from the settings.php file.

Check aliases are working by running these commands:

drush site-alias @d6prod  --with-db

 

drush site-alias @d6dev  --with-db

 

drush site-alias @d7dev  --with-db

Make a copy of your production website to work with

Copy your Drupal files from production to the development copy.

drush core-rsync @d6prod @d6dev --include-conf

The "--include-conf" option will copy the settings.php file. This needs to be included with the first copy. You then need to edit the settings.php file to change the db_url to point at the empty database. 

Copy the database

Copy the production database into the empty development database we created earlier, as defined by our alias.

drush sql-sync @d6prod @d6dev --create-db

The --create-db option will drop the tables in the target database, ready for the import. This will ensure the databases are identical.

Begin the upgrade

Remove as much bloat as possible.

The more contributed modules that you can uninstall from the copy of production, the better. Each one can have it's own problems during the upgrade. Modules for storing data will need to be kept but modules for displaying data could and probably should be uninstalled. Modules like devel, social bookmarks, views plug ins, caching... I took out everything that was plug and play like advagg and mollom.

Custom modules or themes will almost certainly need to be ported to Drupal 7.

It's also advised to switch the theme to the default, Garland. Despite the site-upgrade script taking care of this, it is apparently prone to errors.

Check requirements

drush @d6dev site-upgrade

Write down all modules do not have a Drupal 7 release. You'll then have to work out what you will do about them. Many of these problem modules were easily uninstalled for me because none of them were directly responsible for storing data. Although there was no direct upgrade, the objective could be re-developed easily enough using more up-to-date Drupal 7 modules.

We did however have one problem module that had data associated with it that We wanted to keep. That module was nodewords, the Druapl 6 module for storing meta tags. In Drupal 7 we use the metatag module. When you run into these, you have to go and research the upgrade path, starting with the project pages on Drupal.org. 

Plan the upgrade path

If you run the above command and everything has a recommended release and there are no warnings, try the next step and test the website thoroughly. Fingers crossed everything will just work. 

What is more likely is that there will be some modules that have multiple options for upgrading ie node_reference > references or entityreference. The system will tell you which one it plans to use. If you want to select different ones you can select your preference later, for now make a note. 

Now go through your copy of production again un-installing unavailable modules for Drupal 7. This will be different for all sites. We lost my video sitemap for example and need to cook up a new method because the D6 modules We used don't have D7 versions. 

There will also be special upgrade paths for specific modules ie CCK > Field api. These upgrade paths need to be read and understood before moving on. 

Upgrade to Drupal 7

drush @d6dev site-upgrade @d7dev

To state preferences add this option "--preferred entityreference" to use entityreference for example.

Well that didn't work for me

Unfortunately for us the script kept aborting at step 12. At that point it had:

1. Erased the target directory and unpacked a copy of Drupal 7 in its place.
2. It created the settings.php and populated the db_url line, using the information from the site alias.
3. It then copied the development database using the database credentials given in the site aliases.

At this point it threw up errors and kicked us out. It was still a lot quicker than doing these steps manually.

Get core working

To get this half baked D7 website working We run the database update command on the new copy.

drush @d7dev updatedb

All the updates were run and now I could see the site.

It was then throwing another error on the site to which we found the answer here to run this query

UPDATE system 
SET status=1 
WHERE name='standard';

We then had to copy the files and libraries directories over because for some reason they didn't get copied with the site-upgrade command. 

Upgrade contributed modules

Now the website was viewable it was time to begin downloading all the contributed modules. It's worth noting that for us the site-upgrade script didn't copy over the themes and modules directories either. Personally We begun with anything responsible for storing content. For each of the 50+ modules, We downloaded & enabled them and then run the database updates. The cck migrate step was required before running the node_gallery updates. 

To download a module run this command, replacing "modulename" to the machine-readable name of the module. This the name as per the project page URL on Drupal.org.

drush @d7dev dl modulename

 Next you enable it using this command:

drush @d7dev en modulename --y

 Then you run the modules updates, to migrate the data from the Drupal 6 varsion:

drush @d7dev updatedb --y

This process must be done for all contributed modules and theme if available. With the theme you must bare in mind that any customisations will need to be re-written.

Get the images working

Before doing this none of our images were showing. We had to run these updates on the database.

update `d7dev_database`.`file_managed` 
set type = 'image' 
where type = 'undefined';

UPDATE `d7dev_database`.`file_managed`
  SET uri = REPLACE(uri, 'public://sites/onlinebusinessbuilders.co.uk/files/', 'public://')
  WHERE uri LIKE 'public://sites/onlinebusinessbuilders.co.uk/files/%';

This one was because We just came from a multi-site setup. 

UPDATE `d7dev_database`.`files`
  SET filepath = REPLACE(filepath, 'sites/onlinebusinessbuilders.co.uk/files/', 'sites/default/files/')
  WHERE filepath LIKE 'sites/onlinebusinessbuilders.co.uk/files/%';

Had to upgrade the Media module

Needed to upgrade to dev versions to get rid of errors. Whilst upgrading other modules to Drupal 7 versions, file_entity was installed and it used to come with media. Upgrading media resolved this because file_entity was removed in that version.. 

Node Gallery complications

When editing the galleries We was getting thrown lots of errors and took a guess that We needed to go in and re-save all the node gallery relationships. The guess paid off and the errors disappeared. 

Content types

Check the display of each content type and for good measure re-save them as well.

Node words

Nodewords has been replaced by another module called Metatags in Drupal 7. This was probably the most challenging part of it, well when you don't have the method given to you. Without achieving this data migration we would have lost all our metatags for our content.

https://www.drupal.org/node/1281138#comment-7863403

https://www.drupal.org/node/1434756#comment-5638970

Configuration

Check all other "Configuration" settings to ensure configuration is as it should be. Pay particular attention to anything that uses the Token module because there is a new naming syntax. ,We actually went through all configuration pages and re-saved them all.

Views

All the views had to be re-developed which was somewhat annoying. At best the basic view itself without previously set CCK fields were available to get you going. Others couldn't be accessed and had to be deleted. 

Conclusions

Considering the overhaul that the Drupal websites get with this upgrade, it is worth the effort. Despite having to re-develop our Views and deal with other configurations, it also gives you the opportunity to do things better. Drupal 7 has made significant advances in terms of it flexibility. Not to mention an abundance of new technology for displaying your content.

We will say that the upgrade process is not one for the unexperienced or faint hearted. It would be an advantage to know:

1. How to interact with your MySQL server.
2. How to use the commandline and Drush.
3. How to locate and apply patches for bugs.
4. How to theme because the D6 theme won't work with D7.

We offer Drupal upgrade services. Due to each website  making use of different modules, it presents its own upgrade issues. Please contact us to get a quote to upgrade your website.