Migrating my blog from Drupal 6 to 8

Drupal 8 has been out for over a year at this point. I worked extensively on helping to improve portions of core during the Drupal 8 cycle, but maintaining your own site is radically different from trying to develop the platform that site(s) will reside upon. Upgrading my blog is especially exciting for me because I was still on Drupal 6. Getting to jump directly from Drupal 6 to Drupal 8 is a pretty big win and the fact that Drupal 8 supports this out of the box was amazing. Now granted this is just my blog, it's not even 100 nodes, but still... most of my effort was in cleaning up some content weirdness after the migration and building a new theme. Drupal 8 did all the heavy lifting for me in so far as handling the content. That being said, I did lose a bit of my formatting, but I took a couple of shortcuts that might have introduced the problem so I'll be watching more closely for this on the next migration I do.

Gotchas:

There were of course a couple of relatively minor "gotcha"s. If you're interested in migrating your own site to Drupal 8, you obviously need to be at the most up to date release of Drupal 6 (or 7 if that's what you're running). I was on an ancient version of 6 (6.10 I think), and amazingly the site was still intact. At some point there were some relatively minor schema changes introduced to some tables and of course, Drupal 8's migration path is expecting the tables and columns that should exist in the latest version of Drupal 6, so be certain you've upgraded to the latest release of whatever version of Drupal you're starting with.

I use Acquia's Dev Desktop for most of my local development work. This stems from my time as Developer Evangelist at Acquia and while Dev Desktop is a good tool, it has a couple of minor issues worth noting. First of all, DevDesktop builds a link of your site name to the sites/default directory. This can be rather confusing since you'll have both a "somesite.dd" and "default" directories in your sites directory. As part of my final deployment I actually removed this link without any ill effect. Likewise, DevDesktop doesn't document the database settings or the hash_salt in your settings.php, so you'll need to manually build your database settings on your server, and likewise retrieve the hash_salt settings from DevDesktop. (Check for a .acquia directory in your user dir on whatever OS you happen to favor) In addition to all of this, rather than use Drupal 8's built in Migration UI for a Drupal to Drupal migration, I opted for a Drush based approach. This meant a couple extra modules (and you can find docs here) but more importantly, it meant a reliable connection string to my database. Since it was Dev Desktop, this took a bit of experimentation. I documented the solution here. Using Drush is especially favorable when you have a lot of content to migrate but I'm also working on another migration using core's UI for the process and that works equally well.

Another wrinkle was around gist embeds. In Drupal 6 I just used "full html" input filter and pasted the script directly into my output. It's not quite this simple in Drupal 8. Currently I've opted for codefilter module, but that has been less than ideal to use. I'm contemplating trying gist-embed module too, but a quick glance at both of these leaves me feeling like more effort needs to be put into both of these modules to:

ensure proper identification of relevant content
integrate with the core bundled ckeditor implementation

I'd really like a solution that didn't require me to provide a custom input filter any time I need to paste code, which is what I'm forced to do right now.

Improvements:

Drupal 8's media support is far and away better than any previous version of Drupal. Granted, it's a pretty deep stack of modules and external javascript libraries at this point, but it wasn't difficult to get up and running and once I did it was pretty obvious I needed to rework my content into using it. Drupal 6, by comparison, had relatively little it could do and there were some interesting approaches to handling the problem space. The one I had opted for included a hidden imagefield on the content type which I then used to place images into my wysiwyg. Media made this so much easier that I actually dug back through all my historical content and re-embedded images via media and deleted all the imagefield contents and finally the field itself. This is a really big win and I'm hoping we can figure out how to get better media handling into core. I'd love for my next major upgrade of this site to just recognize what's already been done and adopt it.

On the topic of media handling, I'm pretty happy with focal point. Works as advertised, and made doing some cool stuff like the site header really easy.

Theming was both frustrating and enlightening. I'll blog about that separately, but in general, I'm very pleased with most of the processes involved in getting a new theme up and running. I hope the front enders in the Drupal community share that sentiment.

Final Thoughts:

Anyone as involved in a product cycle as I was with Drupal 8 probably doesn't have the right to give any sort of kudos to the product. It just seems wrong, but since none of my efforts even fringed on most of the things I discussed in this article, I feel really good saying this was a very good experience and I'd like to thank everyone who made this possible. Upgrading the content of my blog from Drupal 6 to Drupal 8 was about a day's worth of effort excluding theme work and was relatively painless. Drupal upgraded all my content types and field configurations, migrated my users, content, comments and files. In general, it went off without a hitch. I have a much much bigger Drupal 7 site I am going to upgrade as well in the near term future, and also a Drupal 5 to 7 to 8 migration I'm going to attempt. I'm really looking forward to trying this process again on a more complicated site. If you've got an old site that you've been putting off upgrading, I'd really encourage you to begin the process. Drupal 8 has reduced or removed most of the old pain points in doing site migrations of a certain complexity.