Drupal 8.9

For this method to work, you will need a Drupal site on either 8.8.x + or Drupal 9.0.x. As well as Ctools. Since Layout Builder is in core, but is disabled by default, it will need to be enabled as well as core's Layout Discovery module. To get Ctools, you can download it via composer, composer require drupal/ctools. Drupal 8/9 Migration: Migrating Media Items and Their Relationships Since Drupal 8.5, the Media module in core has been a reality and the recommended way to handle media content in Drupal. If you're migrating from Drupal 7 to Drupal 8 or Drupal 9, this is something you need to take into consideration. ⚡ Go beyond the buzzword. With the upgrade from Drupal 8 to Drupal 9 – there is no need for migration; the new features for Drupal 9 were gradually released inside Drupal 8. The main change that Drupal 9 brings is the removal of deprecated code, much like getting a hair-cut. However, this was not the case with the change from Drupal 7 to Drupal 8.

Today we are going to talk about the upgrade (migration) from Drupal 7 to Drupal 8/9. As you probably know by now, there is no clean upgrade path from Drupal 7 to Drupal 8 and you are coming to a point where upgrading is a necessity to keep your website and your business protected. Let’s start out with some key dates/information:

  • Drupal 7 End of Life: November 2022 (Extended due to COVID-19)
  • Drupal 7 Paid Extended Support: November 2025+
  • Drupal 8 End of Life: November 2021
  • Drupal 9 Released: June 2020

Great, so now that we have that out of the way, lets talk about the migration from Drupal 7 to Drupal 8/9. First, let’s tackle the question “Should I migrate to Drupal 8 or Drupal 9?” The answer to this question is: It depends! This is really going to depend on your website and it’s unique requirements. The good news is that the upgrade from Drupal 8 to Drupal 9 has a clean path, and does not require a migration.


How do I determine if I should migrate to Drupal 8 or Drupal 9?

With the new upgrade paths between the major versions of Drupal, contrib adoption of Drupal 9 is significantly faster than previous versions. Today, we want to share the questionnaire we use with our clients to help them decide which path to take.

  1. List out all of the contributed modules you use:
    1. Is there an equivalent in Drupal 8? Drupal 9?
    2. If not, is there an alternative that is ready for Drupal 8? Drupal 9?
  2. Does my current hosting provider support the requirements I have for Drupal 9? Key questions to ask:
    1. Are you using Solr? Does your provider have Solr 7 Support? The SearchAPI module for Drupal 9 requires it.
    2. Does your hosting provider support PHP 7.4+? (It should!)
    3. Does your hosting provider support MySQL 5.7.8+ or MariaDB 10.3+? Drupal 9 requires MariaDB 10.3+ or MySQL/Percona 5.7.8+. There are patches available for the previous version in 9.0 but they will lose support in 9.1.
    4. If the answer to any of these is “No”, are you willing to consider different hosting providers and/or search providers?

As you can see, the biggest factors for the migration path here really depend on your hosting provider/support. Drupal 8 and Drupal 9 are built on the same framework and the only difference between 8.9.x and 9.0.x is the removal of deprecated functions in Drupal 8.x.

Migration Tools and As-is Migrations

When upgrading from Drupal 7, it is also important to think about improvements to the content authoring experience. Drupal 8 has incorporated some awesome updates into core and content authoring was a key core initiative. Content modeling should be discussed and your team should put together a migration plan before you get started.

Migration tools are awesome and leading up the pack is the Migration module which has a ton of great work to support a Drupal 7 to Drupal 8/9 migration of your data model.

Configuration Migration

There are tools to migrate your core entity structures such as Content Types, Taxonomies, etc… along with their fields. Support for contrib module upgrades vary, but these can be developed if required. This as-is migration path works great for very simple use cases, but it likely limits your ability to take advantage of new features/content authoring tools built in Drupal 8. For example, if you want to take advantage of Layout Builder for your landing pages, your content model/entity structure is going to need to change pretty dramatically.

Content Migrations

Drupal 8/9’s core migrate module comes with Drupal 7 source plugins which allow developers to easily connect to Drupal 7’s data model and map the content to Drupal 8. Again, contrib results may vary if your using complex fields/child entities and if you have any custom data structures, well, that’s going to be a custom migration as well!

It is important to plan your migration path before starting with your migration. We highly recommend a content modeling exercise that maps your current data model in Drupal 7 to a proposed data model in Drupal 8/9. This will not only help gain buy-in from all parties, it will provide a roadmap for your migration and a way to validate it.

Theme Migrations

Your theme is going to be the area with the least support for automation in your migration from Drupal 7 to Drupal 8/9. The entire theme layer has been rebuilt from the ground up in Drupal 8 to use the Twig framework and there isn’t core support for the theme migration. There are several reasons for this:

  1. Themes are highly customized on every website.
  2. The default classes/html structure from Drupal 7 to Drupal 8 is different, likely rendering most of your styling unusable without customization.
  3. The way assets are loaded into the theme layer in Drupal 8 has changed.

While this will add time to your migration efforts, it is likely a good thing to reassess your theme layer and clean up technical debt. This will pay dividends in the future and provide you the opportunity to incorporate newer tools and technologies such as StorybookJS.

Ensuring a Successful Migration

In order to ensure a successful migration from Drupal 7 to Drupal 8/9, automation is required. Whether you are looking to do an as-is migration or a brand refresh, a good automation framework is going to be the difference between smooth sailing and a rocky launch. Some key checklist items to add to your site automation:

  1. Migration Scripts – Make sure your migration scripts are run early and often.
  2. URL & Redirect Validation – Make sure you have a way to validate your pages were migrated and/or redirected. This can be done on every migration run.
  3. Automated Testing (Unit, Behavioral, Visual Regression) – Good practice in any build!
  4. SEO & Metatag Validation – Don’t let your hard work fall apart during the migration. Ensure your migrations include key metadata.

We want to help!

If you are considering a migration from Drupal 7 to Drupal 8/9, we hope you have found this blog to be useful. For those looking to get more information or planning for your Drupal migration, don’t forget to watch our recorded webinar: Drupal 7 to Drupal 8/9 Migration.


With the end-of-life (EOL) for Drupal 8 closing in fast, we wanted to share our experience on how we have been handling the process of upgrading our client projects to Drupal 9.

The Drupal 8 EOL date is November 2nd 2021. This is because Drupal 8 has a dependency on Symfony 3 which has an end-of-life in November. That means there will be no further security fixes implemented, so to keep your project safe and secure against potential threats, it is strongly advised to upgrade to the latest version of Drupal.

No “migration” needed?!

Correct! With the upgrade from Drupal 8 to Drupal 9 – there is no need for migration; the new features for Drupal 9 were gradually released inside Drupal 8. The main change that Drupal 9 brings is the removal of deprecated code, much like getting a hair-cut.

However, this was not the case with the change from Drupal 7 to Drupal 8. From Drupal 7, there was a multitude of different changes that resulted in requiring a comprehensive and often complex migration. This led to many clients opting for a complete rebuild from the ground up to take full advantage of new features such as “workspaces” that arrived in Drupal 8.6.0.

What about contrib modules?

The “Drupal 9 deprecation” dashboard overview shows the overall compatibility status of all contributed modules to the Drupal ecosystem. Over 88% of the top 1000 contrib modules are explicitly compatible with Drupal 9, meaning they have a Drupal 9 release.

Additionally, more than 50% of all Drupal modules are compatible with Drupal 9, and a further 20% require only the info.yml file and/or the composer.json file to be upgraded to make them compatible with Drupal 9.

How do we upgrade our projects?

At Amazee Labs, we deal with a diverse range of clients – all of which have their own distinctive requirements – so we construct elegant solutions tailored to their unique business needs.

With such a diversity of projects, we developed a solid plan to upgrade each project to Drupal 9. Our maintenance team’s strategy involves the following three stages:

  1. Analyse
  2. Tackle
  3. Deploy


The Analysis stage involves scanning the project server and codebase to identify the complexity of the upgrade process. Some of the information we gain from this analysis answers the following questions:

  1. What version of PHP is the server using?
  2. What version of Drupal Core is installed?
  3. Is the Drupal Core Media module enabled?
  4. How many contrib modules are installed?
    - How many of those contrib modules are outdated?
  5. How many custom modules have been created?

We have a few pre-conditions that the project must pass before we can continue:

  1. The server is running on PHP version 7.4
  2. Drupal Core 8.8.x is installed or ideally the latest release from the Drupal Core 8.9.x branch
  3. Drupal Core’s Media module is enabled

If we have detected that the PHP running on the server is lower then version 7.4, then we need to update this first. If the project is hosted on Lagoon, by amazee.io, then this is generally a breeze to update, as it is highly developer-friendly.


If we detect an older version of Drupal Core released before version 8.8.x, then we create a task to upgrade Core to the latest 8.9.x version. Within the web maintenance team, we have taken over some very outdated projects and meticulously updated each one, always involving the client within our Agile workflow, to build trust throughout the entire development process.

Drupal 8.9.1 Download

To ensure Media in Core is enabled, the process to migrate from the contrib Media Entity modules to Drupal Core Media is outlined over on the FAQ page on drupal.org.

During this initial investigation, we install the Upgrade Status and Upgrade Rector modules, then generate a report containing information on what modules require updating. Furthermore, we generate fixes for deprecated code in the custom modules.


With our web maintenance service offering, we ensure the longevity and reliability of our clients’ projects by keeping their websites up to date and secure.

With the results from the analysis stage, we then create individual tasks to tackle the challenges that lie ahead. The drupal.org documentation has some information on how to upgrade from Drupal 8 to Drupal 9 or higher.

The Upgrade Rector module helps us to perform automated fixes on the codebase. For contrib modules that lack a Drupal 9 release, we contribute back to the community by submitting fixes and collaborating with maintainers to aid them in releasing a new version of their module.

Many Open Source communities have found that to support their growth and ensure long-term sustainability they’ve opted to utilise platforms that pay contributors or embrace corporate sponsors. Underrepresented groups, in particular, do not always have the privilege of free time to contribute to Open Source outside of work hours. At Amazee Labs, we can take advantage of providing contributions to the Drupal community during work hours. Gábor Hojtsy has an extensive overview of articles aimed at helping to push contributed modules to a successful Drupal 9 release.


So we have gone through and analysed the code, updated the modules and exported the configuration, now how do we deploy our changes to the production environment?

Our workflow for the majority of our projects tends to be as follows:

  • All projects have at least two environments:
    • production and development with their respective databases
    • Some benefit from Lagoon's Pull-Request environment feature
  • A production git branch, often named “prod” for short
  • A development git branch, often named “dev” for short

Here is our 13-step guide:

  1. A developer first checks out the project codebase locally.
  2. The developer then fires up a local instance either with Docker or with native PHP.
    - For Docker, they would either use Pygmy or Lando’s Lagoon beta. For native PHP, they would simply run “drush serve” with an SQLite database.
  3. The developer then creates a feature branch on git from the latest changes on the prod branch.
  4. Using the composer tool, the developer upgrades the necessary modules as well as upgrades Drupal Core.
  5. Then they run the update database command in Drush and export the configuration changes.
  6. After this, they commit all changes: configuration changes, composer JSON and lock file changes, as well as any other changes to the custom modules or custom theme.
  7. They push their local git branch to the remote origin and create pull-request into the prod branch.
  8. If PR environments are available, then this would automatically spin up a new environment with all the changes, ready to be tested by another developer.
  9. If the project does not have PR environments available (i.e. if it is not hosted on Lagoon), then the developer will merge their changes into the development environment so that another developer can test.
  10. If the second developer does not find any specific issues during their testing process, then the project manager is informed that they can test the changes with the client.
  11. If the project manager and the client find no specific issues with the changes, then the pull-request is approved for deployment to production.
  12. The original developer is empowered to deploy on their own (but the team is always there for one another). The developer will trigger the deployment by simply merging the pull request they made into prod.
  13. Once the deployment is completed, the developer informs the project manager and client that their website is now running on the latest version of Drupal.


Drupal 8.9.11

Once we have gone through and updated the modules, upgraded Drupal to the latest stable release, and deployed everything to the production environment, then...we celebrate our accomplishment internally with the rest of the team – a job well done!

In retrospect, the upgrade from Drupal 8 to Drupal 9 is a piece of cake compared to the upgrade from Drupal 7. It feels like we are modernising the website in small bites instead of trying to gobble down a brand new refreshed website all at once.

Ready to talk about your upgrade needs? Whether you’re operating on Drupal 7 or 8, We’re ready to help. Get in touch with us and upgrade to Drupal 9 today!