Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the release of Drupal 8 by upgrading their own sites and addressing the issues they find along the way. This series chronicles the journey from Drupal 6 to Drupal 8.

Part 1: Readiness Assessment

Before performing a major version upgrade, I usually go through a series of steps that help me determine:

1. What compelling business needs or new functionality are prompting the move? In this case, the site builder view on the status of D8 will help us identify and hopefully address real barriers to adoption, as well as to prepare materials that help document the journey.
2. What does the site do? If there are functional tests or test plans, I review those. Then, I manually review the site, paying attention to functionality for particular roles. I also check with at least one or two of the stakeholders with each role to learn what features they regularly use, what improvements would better support them, and what they’d really like to see. I don’t normally act on that wish list answer as part of the upgrade proper, but knowing what new functionality they desire can help make decisions about the new modules to use.
3. Are there features that are no longer in use? I’m always surprised, though by now I really shouldn’t be, by the number of things that seemed like a good idea at the time to someone which were never used at all or which are no longer in use.
4. Is now the right time? Are the contributed modules on which the site depends ready or is there a new way to achieve the required functionality.

1- Compelling Functionality

As noted above, this particular journey is compelled by the desire to identify and fix bugs during the Beta period of Drupal 8. That doesn’t mean we’re not excited by:

• WYSIWYG in Core- I am ecstatic at the prospect of NOT having to choose and configure basic WYSIWYG functionality.
• Views in Core - I pay a lot of attention to the experience of content contributors. They’re the everyday users that Dries talked about back at DrupalCon San Francisco, people who use the interface of Drupal as their day job. What a site builder does for them (or fails to do) can make or break the success of the site as well as cement the organizational satisfaction with Drupal itself.

I want Tag1’s busy staff to find it a pleasure to keep their blogs, community contributions, and case studies up-to-date.

2 - Current Functionality

Our speciality is performance and scalability for complex websites, which never necessitated building a complex external site for ourselves. We have internal sites that put Drupal 6 though its paces, but the main Tag1 site is a combination of blogs and brochure:

• Review what the current site does
  I start any readiness evaluation looking at the site from the user perspective, clicking around, then reviewing any documentation. The site revealed no surprises. I jotted notes about those user-facing features, mapped to Drupal functionality, and stored them as a sheet in the Readiness spreadsheet. For a basic site, the notes aren’t too impressive, but the process was a valuable refresher on what the site does.

• Inventory the enabled modules
  After looking at the site from the user interface, I make an inventory of enabled modules. The following Drush commands make nice spreadsheets:

  drush pm-list --no-core
  drush pm-list --core

  You can take a look on Sheets 2 and 3 of the Readiness spreadsheet to see the entirety of what was and and wasn’t available.

  In our case there are just two areas of concern:

  Blogs have been removed from core, but with views moved in, this won’t be daunting to rebuild. They may work a little differently, but odds are that will be for the better!

  The only missing module that had no alternative and looked like it might hurt was Pathauto. It’s nice to keep URLs tidy and hard to remember to set them, but wouldn’t be strictly necessary for our purposes and there were were no other glaring show stoppers.

  Note: It looks like upgrade work is happening on Github so I updated the spreadsheet to make note and will evaluate the status as part of the process.

• Look for customizations
  In addition to custom and contributed modules, it’s good to check for inappropriate customizations done directly to core or contrib. Whatever reason they had for being done back then may need to be accounted for, hopefully in a best-practices way, on the new site.

  Although it seemed unlikely that any relevant changes had been done, for good measure, I always run Hacked. It’ll let you know about files that have been changed from the source.

  There were some theme customizations and a .gitignore file was missing, so as suspected, nothing to worry about.

3 - Features no longer in use

I’ve learned over the years that not every module that is enabled is in use! I try to find a link that illustrates somewhere on the site that the module is visibly in play. Even when there is a place in production where the module is used, it’s entirely possible that the production feature itself doesn’t make sense to upgrade. A serious investigation of analytics and logs can be insightful. Data can guide conversations with product owners about what’s still valuable and support decision-making.

On our straightforward site, there’s not much to not use. As I learned running the first migration, though, even features that were briefly explored but never used can come into play. More on this later.

4 - The right time

Once you’ve completed your archaeology, you’ll need to find the right time for your organization. Talk with stakeholders about the change and be on the lookout for in-process or upcoming feature requests that you might not be prepared to accommodate.

In our case, because the motivation for this upgrade is process, not product, we’ll proceed and go as far as we reasonably can with the upgrade. At the time of this writing, I’ve done a D8 install and begun running a migration. (That’s how I know to be on the lookout for certain disabled modules!) I’m feeling confident that we can get a long way.

Unless the migration process is flawless and the Drupal 8 to Drupal 8 update path is in place I'd be unlikely to recommend deployment of the work, especially with an impending re-design. While re-entering some data manually has always been a part of previous major version upgrades, I’d be loathe to commit to beta adoption if I thought we’d find ourselves stranded in the latest version. Fortunately, all the preparatory work can be done without the upgrade path in place!

Coming next in this blog series, Part 2: Preparing to Migrate.

What modules and processes do you use to prepare for a major version upgrade?