The most recent Drupal version, Drupal 8, is massively different from Drupal 7 and Drupal 6 (the earliest possible version of Drupal that is compatible with upgrading to Drupal 8).
Though it’s been over three years since Drupal 8 launched, many companies using Drupal to power their digital experiences have yet to upgrade Drupal 7 to Drupal 8 due to the complexities involved. Many Drupal agencies and general Drupal users have found out the hard way that making the jump from Drupal 7 to Drupal 8 is actually more like a re-build instead of an upgrade. Meanwhile, Drupal continues to release updates to the Drupal 8 core framework, and Drupal 9 is on the horizon for release in mid-2020. As such, the longer these companies put off the Drupal 8 upgrade, the more difficult that eventual upgrade will be when they’re forced to make it.
There is no easy way around it: upgrading to Drupal 8 is a big change that requires time and attention. To help ease your anxiety around this, we’ve put together a comprehensive overview of the various implications surrounding the upgrade process to Drupal 8, including how to best prepare yourself, your Drupal website, and your team for the project.
Without getting too deep into the weeds, Drupal 8 is much different than previous versions of the CMS, hence all of these upgrade implications. That’s because the Drupal community decided that the platform needed much better core standards and functionalities. Thus, Drupal 8 is essentially a rebuilt version of Drupal with the entire system moved to symfony php, a framework that any versions in the foreseeable future will also be built on. So even though upgrading to Drupal 8 from Drupal 7 might be a painstaking process, updating to Drupal 9 and beyond should be a breeze - that is, once you are already on 8.
There are several tips and best practices to follow to help you prepare for the upgrade. Still, since this is such a complex process, we highly recommend getting members of your development team involved from the beginning, which will help ensure the upgrade goes as smoothly as possible.
Upgrading to Drupal 8 is more similar to building a new website than previous Drupal updates were, meaning that you should never perform the upgrade to Drupal 8 on a live site. It’s also strongly recommended that you create a backup of your live site so that if anything goes awry, you can quickly roll the site back to an earlier version while you figure out what the issue is.
Also, as your team begins the Drupal update process, no one should be writing to the database that powers the site. For veteran Drupal developers, this is sort of a no brainer, but still, an overzealous junior developer could easily overlook the unique complexities involved and end up getting you and your website into a pretty serious predicament.
You must first understand how your current site is built, and this starts with taking an accurate inventory of the Drupal modules you are currently using. This information is pretty easy to find (Administer > Site building > Modules, or go to the Available Updates page at admin/reports/updates), and this type of preparation will come in handy a bit later in your upgrade process.
Make sure to document and create a complete list of the modules enabled on your current Drupal website as well, then evaluate each and every module by asking the following questions:
Not all Drupal 6/7 core modules will have a 1-to-1 complete upgrade path. If after taking module inventory you realize that not all modules will be upgradeable, then Drupal’s known issues page can help you prepare for many of these inevitable modular update scenarios.
If your site is overdue for a standard update, make sure you perform this update before you make the big jump to Drupal 8. Generally speaking, you’ll want your Drupal version to be as close numerically to the number 8 as possible. This helps ensure that any contributed modules are running on the most recent version available, which was the version that Drupal used when recreating these modules into its core framework.
If your website is using public-facing files, the future migration should be a bit easier because those files will be accessible through the site’s address. However, if you are going to be migrating any private files, the file directory needs to be directly accessible to the new Drupal 8 site, and you must also configure the Drupal 8 file private path in your PHP settings before running the upgrade.
Unlike previous version updates, moving to Drupal 8 first requires installing a clean core version of Drupal, and installing it so that it can access your Drupal 7 host server and database. From our experience, this might feel a bit like overkill at first, but you’ll be thankful when it comes time to update the actual content in your CMS. That’s because things are configured and structured so much differently in Drupal 8, so jumping ahead to a content migration strategy without the proper preparation can cause some serious issues.
Also, when installing Drupal 8, it is best practice to do so using the “minimal install” profile instead of the “standard” profile”, which introduces configuration settings that will eventually be overwritten.
You might have the urge to start recreating your content types and assigning fields on your new Drupal 8 platform, but the upcoming upgrade and migration process will overwrite whatever configurations are currently on the Drupal 8 site. Therefore, you should altogether avoid configuring Drupal 8 until the upgrade and migration process is complete.
Assuming you’ve done your homework on relevant modules in use, you should already have an idea of which modules will be leveraged again versus which ones can (and should) be retired. The migration ahead won’t automatically re-install the modules that your Drupal 7 site relies on to function properly, so start by enabling all of the core modules you use, then manually install the contributed modules. Again, make sure to do all of this before you start the migration process.
Also, ensure you’ve installed relevant modules on both the source and destination sites prior to any actual migration activities begin.
Again, all these things will be overwritten after the upgrade. This applies to taxonomy terms and content, node content, user accounts, and pretty much any other type of content you can think of, whether that content is front-end facing or not.
As you’ve likely gathered by now, this upgrade is a project that requires a team of people to implement successfully, including (but not limited to):
While it might seem like a lot to consider, we’ve seen too many clients get in over their heads with the upgrade process and reach out for assistance too late, which made fixing these issues more complex than they ever would have been from an earlier stage. We’ve also been engaged to re-design and build a new website, only to quickly discover that the necessary Drupal 8 upgrade inflates the overall cost estimation, eating up part of their budget. This is especially true if the client hasn’t engaged our team for any of the content, and thus is relying on an outdated or uninformed migration strategy to populate their new CMS and website.