With Drupal 9 on the horizon, there’s been an influx of posts and alerts warning users to make the switch. Some headlines caution to “get ready, because the version of Drupal you are running will be obsolete, and more importantly, a security risk by November 2021,” while others say “change is coming, you need to be prepared.” With these warnings flooding the internet, we wrote a post about the extinction of Drupal 7, along with the ways you can prepare for the upgrade.

Lucky for you, there’s still ample time to plan and budget for the upgrade from Drupal 7 to Drupal 8, and the upgrade path between Drupal 8 and 9 has much less friction. By moving to Drupal 8, the path to Drupal 9 is a minor upgrade, requiring limited extraneous work.

While the internet is inundated with technical language about what to do and how to find out if there are any issues with modules or code within your website, there’s a lack of information regarding the formulation of a budget or plan for the upgrade. In addition, there’s limited information available that explains how to draft and structure a Request for Proposal (RFP) around your current website.

As a tech-driven agency, we are prepared to guide you through the phases of the upgrade. Whether you choose to work with our team or your own, you can follow these guidelines when upgrading from Drupal 7 to Drupal 8, and eventually, to Drupal 9. Here are five ways to help you formulate a plan and budget for your upgrade.

1. Get an inventory of all of your modules

Screenshot of Drupal 7 folders and inventory

 

In Drupal 7, you can capture a complete inventory of your modules in the modules screen, or in a local code in sites/all/modules. On occasion, there are folders in this path, such as Contrib, Custom, and others.

Screenshot showing folder path

 

Once you collect an inventory of modules, you can run it through a command-line application. A simpler step is to install the module, known as Upgrade Status, which puts a user interface over the command-line application. This will generate a list of items that are considered ready or not ready for the upgrade. This module will then provide a configuration screen, which can be found here: admin/reports/updates/upgrade. It may require you to run it manually or to use a crontab, which will prompt you with a screen similar to the one below - showing you which modules you should update, along with paths to different modules, and modules that aren’t in Drupal 8, and likely Drupal 9.

Screenshot of Drupal menu

 

The following preview depicts that a few contributed modules have been moved into Drupal core, with some in development for Drupal 8, and some without any update data. This means they haven’t yet been ported to Drupal 8 and will most likely break in the case of an upgrade. For example, if one goes into the block reference module, it’s apparent that there isn’t a Drupal 8 port (shown in the blue bar):

Screenshot of Drupal project information

 

By creating an inventory of these items, you will be able to effectively put together a budget of what needs to be managed and explored.

2. The theme files will likely need to be rebuilt. Plan for this.

Screenshot of Drupal 8 Twig template

 

When Drupal released version 8, the community switched up the theme templating engine - moving away from PHP template files, .tpl’s, and into Twig. The use of Twig is advantageous, because the front end can be compiled faster and the syntax is more readable, flexible, and scalable.

For Drupal 7 users, Twigify is a module that can be used to help port a theme into Twig. While this module can generate mixed results, it could be worth exploring for your website.

There are also responsive frameworks to keep in mind during the upgrade, including Twitter’s Bootstrap and Zurb Foundation. The best approach when navigating these frameworks is to allocate time for them and test them on a variety of screen sizes. If the theme is developed in a modern way, using tools like sass, it could help with the process of porting the theme over. In addition, any custom javascript running in the front end, or in Jquery, needs to be taken into account, depending on the age of the theme.

3. Compile a list of all website integrations

Illustration of computer elements linked together in clouds

 

Integrations and custom functionality are disparate from one another. Integrations typically use standard methods (RESTful APIs) or services (LDAP) to connect your website into services that are external from the application. Integrations could range - from connecting your webforms to a CRM system, such as HubSpot, to setting up single sign-on (SSO) to your Active Directory forest for website content administrations.

This phase correlates with the first number on this list, because it’s critical to notice if the contributed modules currently used are supported in Drupal 8 and beyond. It’s also important to see if the services within the modules have been ported over, which could occur if you’re currently using SOAP based and it has been depreciated for REST instead.

By keeping all of your integrations top-of-mind, you’ll be able to effectively allocate a budget for this phase.

4. Collect an inventory of any custom functionality

Illustration of individual with "custom development" on their shirt, surrounded by computers and phones

 

Keep track of any custom functionality that’s been written for your website. In Drupal, this is typically set up in a custom folder under Modules (sites/all/modules/custom), or can be listed in your other modules that don’t appear on Drupal.org.

This step may pose more challenges than others, because it can significantly vary from site to site. As a partner of Boston Digital, we would work with you to create a complete inventory of the custom functionalities on your website, allowing you to put together a budget around this. For example, it could be an inventory management system that connects your website to an application your company has built, or a web service that talks to a custom database within your organization that displays on the website.

With an inventory of custom functionalities, you’ll be one step closer to formulating an accurate time and budget for the upgrade.

5. Execute an effective content migration

Graphic showing content migration through cylinders

 

In most cases, an upgrade from Drupal 7 to 8 isn’t an in-place upgrade. This means that the current database with stored content is updated to Drupal 8 and the job is complete.

However, a typical process involves moving away from Drupal 7 altogether, building a new instance of Drupal 8 to build the new website, and eventually upgrading to 9 when it’s released. Then, you would migrate your content into the new Drupal 8 instance from Drupal 7. In this phase, it’s important to identify how your content is organized in Drupal and clarify whether or not it can be a one-to-one match over to Drupal 8.

Here’s a list of questions to keep in mind during this phase:

  1. Do you heavily utilize custom blocks, or BEANs, to organize content?
  2. Are you using content organizational modules to manage content in your site? In Drupal 7, the most common content organizational modules are Field Collections and Paragraphs - Paragraphs being the preferred method, while Field Collections aren’t recommended. This could help when aiming to move Field Collection content into more modern Paragraphs.
  3. Do you use Panelizer? It’s important to note that most of this functionality has been moved into Drupal core with its layout builder.
  4. Do you use the Feeds module to build pages based on an import?
  5. Do you heavily utilize taxonomy to categorize content?

Once these key questions are answered, you can better formulate a plan using Drupal’s migrate API to move content out of Drupal 7 and into the new Drupal 8 instance.

Start Preparing Today

While this isn’t a conclusive list of everything to know about the upgrade, it’s a starting point to help you take inventory of what needs to be done prior to the end of Drupal 7 in November 2021.

The talk has been focused on replatforming, but this assumes that the structure and look and feel of the website will not change during the move to Drupal 8 and beyond. Another option is to allocate a budget for a website redesign. This would work twofold - your website would be on a more modern, scalable framework, while also uncovering what currently works, what doesn’t work, and what enhancements could be made for the new website. While this option requires more time than a replatform, it’s a beneficial alternative to meet KPIs and start gaining optimal web results.

If you’re an existing client of Boston Digital, your account rep will be reaching out about this so that you’re aware. If you aren’t one of our existing clients but are interested in our services, please feel free to contact us and we can discuss your situation in more detail. While the overhaul from Drupal 7 to 8 was pretty substantial, the path from Drupal 8 to 9 is much less painful due to the groundwork that was already laid.


Subscribe to Our Blog

Don't miss another post. Subscribe to all new blog posts by following us on Twitter, LinkedIn, or Facebook.