Migrating data from D6 to D7

by Gisle Hannemyr

This legacy chapter describes how I tried to migrate content and users from a Drupal 6 to a Drupal 7 website.

Table of contents

Introduction

This section contains some notes about my practical experiences about migrating entities, such as users and contents, when doing an upgrade from Drupal 6 to Drupal 7.

Before you start

It is best to do the upgrade on a staging server to minimize downtime on your production server. This is what you should do as a minimum before you start moving actual content.

  1. Revert to the default theme.
  2. Revert to the default language (English).
  3. Make sure your version of Drupal is upgraded to the latest stable version of its branch.
  4. Disable and uninstall all modules and themes that you do not use.
  5. Upgrade all the modules you use to the latest stable version.
  6. Make a full backup.
  7. Install the Drupal branch somewhere (usually on the same web server).
  8. Configure the new Drupal branch.

After this, you should have a populated legacy Drupal website and an clean new Drupal website running side by side on the same web server.

Plans

To be honest, these plans did not work out very well. This is not a tutorial that tells you how to do this in a smooth and painless manner, but a record of how I tried to do it.

Plan A

The main entry about Upgrading from Drupal 6 to 7 on Drupal.org suggest that you can upgrade from Drupal 6 to Drupal 7 by unpacking and installing Drupal 7, tell it to use the old Drupal 6 settings and database, and run the upgrade script to convert legacy data into the new format, and then reintroduce any disabled modules one by one and again run the upgrade script.

This was my Plan A, and it failed horribly. I ended up with a crashed database. I think this only works if you're running a very basic system without any custom content types. Both the CCK and many contributed modules let you have custom content types. There is not yet an upgrade path for CCK created types, and the support for upgrading custom types vary from module to module.

So I restored Drupal 6 from backup and started on Plan B.

Plan B

Plan B was to migrate users and content nodes into a fresh and empty Drupal 7 configuration. This involves the following steps:

  1. Export content from Drupal 7 to intermediary format, then import this to Drupal 7.
  2. Create code for batch conversion of the remaining content.

For help with batch conversion, you may need to search for solutions. Spread around the web, developers struggling with upgrading from Drupal 6 to Drupal 7 have written batch conversion utilities that may help.

I've successfully migrated the Creative Commons Norge site. The specific scripts used and some notes was in the directory Doc/ below the staging area for ccno [now lost].

Export-import

Many contributed modules have built-in functions to export and import content by means of XML-files, CSV-files or other popular file formats. For instance the Biblio - Endnote XML module lets you export and import bibliographic records using the Endnote XML format. (However, some information, such as who created the bibliographic entry and when, is lost because this information is not supported by the Endnote XML format.)

For content that is managed by modules that offer export and import functions (provided you can tolerate that information that is not supported by the export format is lost) export from the Drupal 6 configuration, followed by import into the Drupal 7 configuration, is usually the most painless migration path.

Migrating users

To migrate the users, I created a simple PHP script based upon the suggstions that looped over all users and moved the neccessary fields into a new user table. This worked fine for porting basic user information, including passwords. Avatars need to be migrated by hand. Data kept in fields added to the configuration must also be migrated by hand.

My script is named mvusers_ccno.php.

Migrating nodes

Node content is spread out in a number of tables:

The Node export module (requires Universally Unique IDentifier) let you export nodes to a number of different text formats. The most human readable of these is XML. However, there is no simple conversion paths between versions since both the names of content types and the schema has changed.

These contributed extensions for Drupal 7 may be helpful:

[More TBA. I still haven't figured out how to do this.]

Plan C

I had some luck with migrating users under plan B, but so far not much luck with content based upon CCK content types. My plan C, which I've used for a few sites so far, is to make a complete content inventory of the old site. Then I've proceeded to reconstruct the content types I've used under Drupal 6 with Drupal 7 tools (mainly the core Field module). Then I've moved content node by node by scraping source and using copy & paste, using the content inventory document to keep track of progress. This way of doing it is not fast, and it is horribly boring, but at least it works.

Final word

[mumble]

Last update: 2021-01-04 [gh].