This post may be of interest to project managers and sitebuilders looking to migrate from Drupal 6 to Drupal 8 during the early months after the launch of GA D8.
On the Acquia Support Team we often find ourselves using Acquia’s public-facing documentation and article library as an effective tool for explaining product-related tasks, technical how-tos, and a variety of other topics. These resources are useful when communicating via our Support Help Center. Unfortunately, the underlying infrastructure for this site was Drupal 6.37.
As a team, we agreed that we wanted to learn as much about Drupal 8 as possible leading up to the GA on November 19th, 2015. But we felt that launching a site immediately after the GA announcement would be a bit premature for us; we wanted to insure the site was running on a stable release. At the same time, we knew that Drupal 6 would reach end of life (EOL) on February 23rd, 2016. This helped us to define our timeline: 3 months in duration, from start to finish.
At the beginning, we started with a few goals:
- Despite wanting an amazing site at launch, we had to identify a Minimum Viable Product as a more reasonable alternative.
- We wanted an automated migration, so that we could leave the DNS traffic hitting the old site until cutover time (~1 hour prior to launch).
- Migration must include all current customer-facing content.
- The final site should only implement reliable releases of contrib modules (beta, release candidate, or stable).
- We wanted to minimize the use of custom modules and code. We did expect, however, that theming would require significant customization.
We also had to contend with a few limitations:
- Our team consisted almost entirely of internal volunteers from other teams. (This turned out to be a positive as time progressed and individuals from across the company assisted with the solving of various issues.)
- Another limitation was that our hardware architecture had not been created to take into account build artifacts such as those created by a Composer-impacted development cycle. Fortunately we had the option of working with Composer on Acquia Cloud in the development environment by leveraging Livedev Mode.
To address our short time frame (three months!) and the variable availability of the volunteers, we chose to go with two-week sprints. Each sprint would focus on task and story tickets, outlining at least two critical goals or features, such as migration and theming. User testing was planned for the two weeks prior to launch.
Another key element was maintaining attention on contrib module availability. One or two of the team members tested and examined several contrib modules, and monitored both internal and community efforts in module porting to D6. The Drupal.org Contrib Tracker was a valuable resource in this effort.
Overall, the number one challenge was the content migration. The reason: we wanted to build a new data structure that was more consistent and flexible towards our future plans. However, this necessitated combing through the YAML configurations created by a stock D6-to-D8 migration, using the built-in tool in D8.
Migration delays impacted our ability to see what the new data structures would look like with real data. This slowed down our ability to tweak the theme. It also delayed testers, because the response to testing auto-generated “Lorem Ipsum” content in the shell of the site was tepid.
Search API was another hot topic, because we wanted to fully leverage Acquia Search in a bid to improve the findability of documentation. Unfortunately the suite of modules we intended to use are still in various stages of alpha release (as of this writing, in mid March, 2016). These modules include: Search API, Search API Solr, and Facets. We are currently working on insuring stability prior to incorporating them within our site.
Our plan for testers during the final two weeks prior to launch was sorely tested as we discovered early on that some sort of granular workflow was necessary to support our internal writing and editing team. Thankfully the beta of Workbench Moderation was available shortly before launch. While the module does not contain all of the features that we wished to eventually use within the site to provide a more robust workflow experience, it is an excellent starting point and a place to learn about the specific needs of your team.
Some simple contrib module wins we experienced due to their plug-and-play nature were: Mollom for protecting our contact forms, Automated Logout to insure that users were logged out following company policies, Metatag for improved SEO, and Admin Toolbar, a simple and yet welcome improvement for administrators working on the site.
Some modules worked as advertised, but often we had to make tough choices, such as including the dev release of certain modules. This ran counter to our recommended best practices. In essence, such decisions are common, almost expected, but it was important for us to maintain extra vigilance in monitoring the issue queues of those modules and developing a team process for doing so.
One good example of a stable but dev version of a contrib module was Google Analytics. The dev version hasn’t caused any trouble; we chose it because the last release candidate of the module was available 2015-Nov-22. A quick perusing of the issue queue for D8 Google Analytics reveals no glaring problems.
In the end, like any other project, we had a few stressful days. But we were able to achieve our goal: to launch prior to the EOL of D6. We still have many planned improvements and features for the site, but the future is bright. And we are quite happy with the experience of working across departments.
