We’ve been building projects with Drupal 7 for years, but we’ve also maintained a handful of sites on Drupal 6. Of course, with the release of Drupal 8 and subsequent announcement that D6 would soon go the way of the dodo, the time had come to migrate our Drupal 6 flock.
Migrate a Site from Drupal 6 to 8
We began discussing options with D6 clients early on to determine the best course of action, and one courageous client opted to move ahead full steam right away. We just needed to decide if we should upgrade to Drupal 7 first, or go straight to the new Drupal 8.
Despite the fact not all third party modules would be Drupal 8-ready, we agreed on D8, which would avoid another major migration in the near future.
Together, we set forth goals for the migration:
- Update to Drupal 8 before Drupal 6’s end-of-life date
- Redesign the site with a new responsive design
- Bring forward all site features that had stable releases for Drupal 8
- Improve UX in key areas of the site, like search and navigation
Addressing missing modules
Our first order of business was to address the logistics of managing a migration to Drupal 8 before all modules were available. How would we accurately estimate the effort required to upgrade the site, and what potential hurdles might we run into? The answer to both questions proved surprisingly simple–split the project into two phases.
In Phase One, we planned to focus solely on the features Drupal 8 core was ready to support, and migrate the existing content data. In Phase Two, when more contributed modules became available, we would focus on customizations like complex editorial workflows and other features on the wish list.
To spec the phases, we first identified Drupal 6 modules that were either not stable for Drupal 8 or were never going to be ported. Then, we discussed our findings with our client to determine which modules we’d invest time in developing, and which we’d hold off on.
We recommended that items such as editorial workflow modules, image management tools and even critical tools like Path Auto be pushed out to Phase Two, because we knew they would prove difficult to bring forward—and there was still the chance that more modules would be available in Phase Two to address those items. Our client agreed.
We moved forward with a lean scope of work initially, but this approach allowed us to substantially reduce the project’s complexity—which, in the end, helped us stay on time and under budget.
Content migration kinks and resolutions
In parallel with the design upgrade, we began content migration. This is a process that usually happens in steps, starting with broad strokes. We typically move full pieces of content from the old system to the new system, and then audit the migrated content to look for inconsistencies. After that, we clean them up. And, despite being a Drupal-to-Drupal migration, this project unfolded the same way.
There are migration tools built into core—and a few of them extend functionality to make the process more complete — but our experience with data migration told us it wouldn’t be that easy. It’s always the small stuff that throws the wrench. Links within content, references to uploaded files and embeds for video content can hold up the process and eat away at the project budget fast. So we factored in all the small stuff.
We started with some brute force trials on a site clone, carefully noting all the things that popped up, like errors filling the logs, incomplete migrations, data issues and so on. Then we started working through the kinks, documenting all the steps until we were confident we could accurately reproduce the migration routine closer to launch.
Here’s a quick look at some of the issues we ran into with Drupal 8 migration tools:
- Menu inconsistencies (because back in the day the “main menu” was called “primary links”)
- Lost role assignments despite user migration
- Duplicated taxonomy vocabularies
- Some incomplete or duplicated content types and content field definitions
- Some data that didn’t carry over, such as content statistics
- Data issues on content language assignment (‘und’ vs ‘English’)
After running the automated migration tools, we had to do a lot of cleanup manually through database queries, which, while not ideal, was fairly fast and gave us the opportunity to get a better look under the hood at how Drupal 8 stores data compared to earlier versions.
What’s great in Drupal 8
It was helpful to have tools like Views, CKEditor, and various field types in core. For years, we were used to our regular updates of imagefield and filefield—but no more! Even some administrative tools like Module Filter (now in core), and a built-in responsive admin theme were instant improvements over previous versions of Drupal, and a vast change from Drupal 6.
We even gave Drupal’s new Configuration Management tool a spin and, while not as intuitive as we had hoped it would be, it provided a means for sharing configuration between members of the team during development. We look forward to digging into it more and putting it to use on future projects.
Theming in Twig was painless and the inherent separation of logic in the templating engine removed all the ambiguity about where code should live.
Under the hood, it’s a huge win that Drupal 8 has standardized a set of tools many of us were already using, like Guzzle, Composer, Twig, PHPUnit, and Symfony. (There are even more tools included in core, and you can read about them in this great article from Drupal Watchdog.)
The benefits of Drupal 8 were many, but a few things left us feeling like we’d gone backward (which may change as new modules are released). For instance, there is no D8 release yet for the Imagefield Crop module, which is an enhancement that gives content editors more control over the way images are cropped. We used it a lot in D7 and were hoping to bring that functionality to this migration.
Here are some other modules that weren’t available to us at the time of migration:
- Backup Migrate module - we replaced it with a custom script that manages backups of not just the database, but also site files and archives them off-site.
- IMCE Wysiwyg bridge - we decided to forego using IMCE at all, and instead use the built-in file support and “Files” tab (located on the content admin screen). We may revisit this later.
- Insert - this would have been nice for the admin experience, but wasn’t a show stopper.
- Webform - our requirements allowed us to use the built-in contact form functionality instead.
- Secure Pages - in Drupal 6, we had been protecting only login pages. We made the decision to enforce https on all site pages. It can help boost rankings and is quickly becoming best practice.
- Pathauto - this is a module we all probably take for granted and we ran into a bunch of bugs with early releases of it, including a conflict with paths defined Views. We launched without it but will be keeping an eye on the issue queues for updates.
In some cases, modules were released just as we were developing workarounds, like the Footnotes module, which our client’s D6 site had used quite a bit. We explored a few custom solutions to deal with the special syntax the module uses to convert footnotes on the front end, but by the time we were ready to apply our solution, a Drupal 8 development release was available. We anticipate that more and more stable releases will become available in the first half of 2016, which is great news for anyone looking to start developing sites with D8.
While we were migrating Drupal-to-Drupal, in many ways we still found ourselves comparing apples to oranges as we leapt over Drupal 7 and went straight to 8. Despite those challenges, we were able to launch on time and present a new Drupal 8 site that showcased a dramatic improvement over the previous site — not only does the responsive design work on any device, but the platform meets the latest Drupal standards for security and performance.
So, yes. It was a big leap of faith and logistics, but we’re pleased with the result. Along the way, we also had the opportunity to delve deeper into Drupal 8.