Migrating Drupal 6 to Drupal 8: Our experience

Author picture
Gareth Goodwin profile
Posted by
Gareth Goodwin
Date:

In his recent post, Keith Jay announced that the Five Mile team have been gaining invaluable experience building client sites in Drupal 8. In fact, since Drupal 8’s release in November last year, we took the decision that if the project fitted then let’s go with version 8. As a result, nearly all our recent work has been developed in the very latest Drupal release.

Of the several Drupal 8 projects we’ve completed, it was a project that we undertook for Capita to migrate a set of three, related Drupal 6 sites that has given our team the opportunity to learn the most about building in Drupal 8.

Since these sites were six years old and have always been supported extensively by us to provision new features, various rebrands, numerous campaigns and quite a few advanced custom features, this project covered pretty much the full spectrum of Drupal-related site creation. We knew this project would stretch us and we knew the general (good) advice is not to use client projects to cut your teeth on the latest and greatest (unless they are very simple). But we gave this project a lot of thought and put in a lot of planning and the result was a number of very good reasons to support going with Drupal 8 for this project.

In this post I’m going to be covering some of the background on the project and some of the decisions we took in approaching a full-scale migration of three large Drupal 6 sites into Drupal 8. As the lead developer at Five Mile, my focus will be on the technical and implementation approaches we took in order to reach ‘version 1’ of each of the three sites. In terms of experience to share, there’s way more than I can fit into a single blog post and so I am looking to cover our experiences across a number of posts.

Taking stock, what do we have, what do we want and what do we not want?

We were maintaining three large Drupal 6 sites that were in real need of being ‘upgraded’. Not only was Drupal 6 rapidly approaching end of life in February 2016, these sites were reaching their own form of end of life in terms of their architecture and features.

One of the most pressing factors was the client’s own need to ‘move on’ with new and more complex site projects including third-party system integrations. This alone is one of the main reasons why Drupal 8 was a preferred platform for upgrading to.

In order to make an informed decision on the best approach and whether using Drupal 8 was going to be feasible we started by taking a full stock on what we had:

Gareth building Qimteq site

  • 6 years old (from initial planning and designs)

  • Over 3,700 nodes across the 3 sites

  • Over 5,200 files

  • Many thousands of automatic and manually created redirects

  • Many pages of campaign style content built around theme-specific markup

  • Plenty of custom forms talking to back-office services

  • Pages based on blocks positioned with outdated drag-and-drop methods

For this project we took the approach with the client that we were upgrading, replicating and migrating. This was important because we wanted to avoid extending the scope of the project by adding the need to create new functionality or features beyond what was needed to move what they already had. The only ‘new feature’ we agreed made sense to implement into the new sites was the coinciding corporate online rebrand. Since the bulk of our source content was well structured in Drupal 6 CCK fields and in the main, body fields were not riddled with theme-tainted HTML, a retheme made good sense.

Also important is that we only wanted to move what was absolutely needed. Thankfully, much of the content and its presentation was already undergoing review and repurposing and so we were able to approach the problem of old content being presented in an old way by treating it as a form of ‘temporary archive’. On top of this, the client wanted the opportunity to cleanse the site of deprecated content.

This meant that all new development could focus on how we were going to migrate the parts of the site that will be living on well into the next five years+, as well as starting to plan the new content creation features the client desperately wanted.

One point of discussion that we kept returning to was the need for improved ways to work with configuration and deployments in code as a team. We really did not want to have to be struggling with deployments as the sites become more complex in the future. The Drupal 6 sites used the Features module extensively and our work in Drupal 7 meant we had plenty of insight into the pros and cons of Features. Since we hope to be continuing our support for these sites into the next 5 years, we wanted to be sure that the new sites would better support deployments and config in code.

And all this left us with the one key decision: whether to build in Drupal 7 or Drupal 8? Making this decision came down to looking at what we ideally wanted to achieve:

  • A vastly improved way of providing digital publishing features to our client, one that was robust and as future proof as we can hopefully get

  • Support for all of the required features, exhaustively listed in our research phase

  • A method of migration that the client could use to select only the content they wanted to be migrated

  • Support for the client to continue to work with the old sites and have that work migrated into the new sites at launch

  • Full migration support for content, meta content and supporting content features

  • Visual and functional replication of what they have, even if with progressive enhancements

  • Better support for ‘working in code’ as vital

  • Support for what turned out to be a reasonably simple set of required contributed modules

Drupal 7 or Drupal 8. Is it ready yet?

When we considered the points above, the choice between Drupal 7 or Drupal 8 really came down to two things:

  1. Do we need to use Drupal 7 because it’s mature and rich in modules or could Drupal 8’s core feature set and currently more limited contributed module space support the replication of these sites and allow us to really develop it for the future?

  2. Can we risk not going with Drupal 8 since we want to put ourselves and our client into the best technology for the future developments of this site?

I do recall that we’ve been in this situation before and it was on the same project. When I joined Five Mile the Capita project was only just getting under way and I recall attending meetings about the plausibility of using the release candidate of Drupal 7 as opposed to the then mature Drupal 6. Back then, the decision was easier to make because there simply wasn’t the contributed module readiness for Drupal 7 to support its early adoption on this project. However focus in the Drupal community naturally shifted away from Drupal 6 to Drupal 7 and over time we found ourselves wanting to use functionality that was being advanced in Drupal 7. Of course we have to plan for the same happening with Drupal 8.

Drupal 8 also has a new release cycle for core which means that we can support the client with deployments of Drupal core that will evolve and continuously improve. This coupled with the new configuration management in core which will enable us to better manage code deployments as a team, means that we are already seeing better workflows come together amongst our team working on this project.

Our decision to go with Drupal 8 really came down to the future proofing of the sites and the opportunity for us as a team to learn, get better at what we do and really importantly, get involved.

The truth is that as we were developing the sites, many contributed modules either didn't yet exist or were not quite ready for the prime time (though contributors are working incredibly hard on them) and depending on your project requirements this is obviously going to have a greater or lesser impact. Luckily for us on this project, although it’s pretty large the feature set is the typical requirements around digital publishing and so core Drupal 8 takes care of most of it. The same goes for documentation, at the time of working on these projects documentation covering common site building tasks or even more involved development tasks such as customising migrations in Drupal 8 was obviously a little thin on the ground.

Because of the wins that Drupal 8 could bring to this project we decided to approach these issues by seeing them as an opportunity. It definitely meant longer hours and whilst it’s good advice in general to recommend not learning Drupal 8 on client projects, I believe that given the right project it can be exactly the place to learn new things.

In my next post I will be covering the approach and groundwork we undertook in order to get content zipping from three Drupal 6 sites, all sharing the same multi-site code base into standalone Drupal 8 sites, all sharing the same base configurations.