Menu
duover-blog-banner.jpg

Drupal 6 to Drupal 7: How to Retain IDs - Part One

Scott Weston on March 6, 2014

Why is retaining the same IDs important when upgrading Drupal 6 to 7?

One of our clients is in the process of migrating from Drupal 6 to 7. One of the requirements for this migration is to retain the same IDs from the previous version of Drupal. In part one I will set the scene for this migration by outlining the primary requirements of the project.  

Here is a list of the Drupal-generated incremental IDs that needed to stay the same from during the upgrade of Drupal 6 to Drupal 7:

●      User ID (users.uid in Drupal 6 to users.uid in Drupal 7)

●      Node ID and Revision ID (node.nid, node.vid)

●      Vocabulary ID (vocabulary.vid in Drupal 6 to taxonomy_vocabulary.vid in Drupal 7)

●      Taxonomy Term ID (term_data.tid in Drupal 6 to taxonomy_term_data.tid in Drupal 7)

Why does our client require this preservation of IDs?

●      There are URLs 'in the wild' that have a node or term ID in the URL (for example a page which shows the members of an Organic Group, or a Taxonomy Term page). It would have been possible to either serve up a page the user wasn't expecting or enter into some strange infinite loop of 301 redirects.

●      There are third party systems (a CRM among them) that have integrations, which are based on the Drupal ID of some items.

●      There are some custom modules and tables that have been created which aggregate some data on cron runs.

You might be thinking that retaining the same IDs during an upgrade is a crazy requirement and in some cases you would be correct. But given the requirements of our client, keeping the IDs the same would be less of a hassle than trying to keep multiple systems in sync with all of the changing IDs. In hindsight (of course) using UUIDs in the initial site build would have eased this transition.

With an open source content management system like Drupal, custom migrations are, relatively speaking, a breeze. In a proprietary CMS, someone may be locked in to a very specific way of importing or exporting data.

Leveraging the openness of Drupal on both ends, I was able to make a process for performing this Drupal 6 to Drupal 7 migration that is fast to develop, repeatable, and straight-forward to implement.

Caveat #1: This post is for someone looking to do something similar with their Drupal 6 to Drupal 7 migration. It is best suited for someone with a fair amount of knowledge about both Drupal 6 and Drupal 7 and isn't targeted for someone who is taking on this migration as part of their first Drupal project.

Caveat #2: The standard lawyerly disclaimer of "there's no warranty express or implied" is in full effect! While there are some specifics in this post, my goal is to provide readers with some inspiration about thinking outside the box (or in this case, the Drupal drop) and to get creative when approaching challenges with our beloved open source CMS.

Looking to Migrate

First, I must say that the intent of this post is not to bash the Drupal Migrate Module or other modules, which facilitate data migrations into Drupal.

I love the Migrate Module. It's a very powerful way of getting data from one database and into another. The Migrate Module let's developers extract data from other databases and import the information into Drupal.

The power of Migrate is twofold. First, the module allows users to 'rollback' imports if something goes awry. Next, the Migrate module gives the developer access to the Drupal database API to craft the custom queries that make up the record sets that will be imported.

Seasoned Drupal developers know that there are a lot of tables in the Drupal database. In the case of this specific client, the Drupal 6 installation has exactly 300 tables in the database-- a good number of which start with 'content_type' or 'content_field'.

If you've poked around in a Drupal 6 database you know what these tables are all about.

So in the case of using the Migrate module, there would be a lot of JOINs needed between the various field tables to get all of the data needed for a node import.

The ‘Other Modules’

We then looked at other modules (Node Export and Feeds, among others) to see if they would work. After some research, it appeared that going 100% custom would facilitate the needs of this project without introducing unnecessary complexity that would slow down the project.

Stay tuned for Part Two: The 5 Steps to a Completed Migration