Is it time to migrate to Drupal 10?
If your website currently sits on an old version of Drupal, it's likely time to migrate over to Drupal 10. Our developer, Alan, is sharing the process we follow for Drupal migrations depending on which version of the software you currently use.
Drupal 10 is the latest major version of Drupal available, and Drupal gives us as developers the tools to be able to upgrade from an older version to a newer one. In this blog post, we will outline the steps that we follow to get your sites upgraded.
It’s not too late to plan in an upgrade with Drupal 7’s end of life date recently being pushed back to 5th January 2025 and Drupal 9’s end of life in November 2023.
The process that we follow is very similar whether we are upgrading to Drupal 10 from Drupal 7 or Drupal 9.
The major distinction to make between going to Drupal 10 from Drupal 7 and going to Drupal 10 from Drupal 9 is that going from Drupal 7 would be considered a migration, whereas going from Drupal 8 or 9 would be more considered as an upgrade.
This is because to upgrade from Drupal 7 there is a lot more work involved as Drupal 8 was rearchitected from the ground up and requires functionality to be rebuilt to use the new structure/code that Drupal 8 brought in. Whereas with an upgrade from Drupal 8 or 9 to Drupal 10, the upgrade path is usually much more straightforward.
Pre-migration
Regardless of the version we are going from, we need to perform an assessment of the current state of the website prior to the migration/upgrade.
To do this we setup a spreadsheet which notes down all the entity types that are on a particular site; such as content types/nodes, paragraphs, taxonomy vocabularies, blocks (including any that are not enabled) and users. Noting down how many entities exist for each entity type helps give us an idea of the scale of how big the migration is going to be.
For migrating from Drupal 7, we also identify when reviewing the different entity types if there are any field types that could cause us issues when migrating/upgrading the site.
If the site that we are upgrading from is on Drupal 7 and the website uses the views module, then we note down all the views that the website has. This is so that we can then evaluate each view to note how many displays that the view has, how complicated the view is i.e., does it have any contextual filters, how many fields does it have, does it use view modes like full and teaser or does it just have all the required fields added and does it contain any fields containing PHP code embedded.
Next, we inspect the modules/themes that the website has installed/downloaded to establish if any of these modules/themes have Drupal 9/10 compatible versions available. There is a useful module called Upgrade Status that can help us to work this information out. If it doesn’t, then we check the modules/themes manually on Drupal.org.
The Upgrade Status module not only checks contributed modules downloaded from drupal.org but can also be used to check if custom modules/themes are compatible with Drupal 9/10.
Additionally, we must take into account any modules that have been patched and identifying why they have been patched. This is to ensure that the functionality in the patched modules is maintained or handled via different means.
The Upgrade Status module can also tell us if the sites hosting environment (PHP and database versions are the main issues that crop up) will require some work to ensure that the upgraded site can go live when the time comes.
Particularly for Drupal 7, when we are examining the modules/themes that have Drupal 9/10 compatible versions available, we need to work out what the migration path looks like (the migration path is the process of upgrading the module/theme, is the whole process going to be handled by the module/theme or is there a need for us to perform manual steps to fully migrate the module/theme).
If any modules/themes do not have a compatible release, then we need to scrutinise these further to identify if there is a patch that could be applied to add in compatibility or if we need to look at alternative modules/themes that do a similar job or if the problem that the module/theme resolves can be resolved in another manner.
We also use the drupal-check package created by Matt Glaman to check for deprecated code in the modules.
Migration
When it comes to migrating, the process is different when upgrading from Drupal 7 compared to upgrade from Drupal 8 or 9.
Drupal 7
If we are migrating from Drupal 7 then we tend to install and use three contributed modules in tandem: Migrate Plus, Migrate Tools and Migrate Upgrade. These modules allow us to migrate the site and allow us more control over the migration enabling us to perform actions like rolling back a migration if something has gone wrong.
The modules are also useful if you are upgrading medium to large sites that have a lot of functionality/content/configuration that would need to be migrated, so that you can fix all the migration issues the first time. Then when the site is upgraded, we arrange a window of time with the client to enforce a content freeze. Doing so enables us to roll back the content parts of the migration and run the migration again using a newer copy of the database.
Drupal 9
If the site is being upgraded from Drupal 8/9 to Drupal 10 then we can use composer to perform this upgrade. There can be some issues when it comes to performing this upgrade, especially if not all of the modules have Drupal 10 compatible releases and rely on patches being applied to the module using the really useful composer-patches package. Composer can have a hard time downloading some modules from drupal.org because the module requires a patch to be compatible. But composer needs to download the module before it can apply the patch.
We can try and get around this by tricking composer a little by installing Drupal Core version 10.1.2 as 9.5.10. However, Matt Glaman has created another useful package called composer-drupal-lenient package which removes the need to apply this trick.
Upgrading from Drupal 8/9 to Drupal 10 can still provide us challenges that we have to overcome in terms of other dependencies that the website relies on, but the upgrade certainly tends to be a much smoother ride.
If the site has larger features like;
Multi-site (multiple installations of Drupal using one codebase).
Commerce
Multi-lingual
Heavy custom code
Then the complexity of the upgrade and the likelihood of hitting issues is increased.
Post migration
Drupal 7
After the initial migration has been completed to bring in any entity types, entities and any other functionality that has a defined migration path. We then must manually migrate over the views from the Drupal 7 site as these do not get created automatically when upgrading from Drupal 7 and reconfigure any modules/themes that were identified in the pre-migration assessment as requiring manual steps to be followed for the functionality to be considered as migrated.
Drupal 9
The post migration steps after upgrading to Drupal 10 from Drupal 9 is thankfully a lot less time intensive, because it just requires us to review that the upgrade has been successful before moving into the testing phase.
Testing
The testing phase is really what it says on the tin, we need to test the site to ensure that with the migration/upgrade that all the functionality that the website has works as expected.
Release
Finally, once the testing has been completed and any issues have been resolved, we arrange go live. If we host the website on our hosting, then we can make any required hosting changes just before or at the point of go live of the upgraded website.
Whereas if we do not host the website, then we would need to liaise with the people that manage the hosting to get the changes made, this can increase the time in which it takes for an upgraded site to go live.
We at Logic+Magic have a breadth of experience when it comes to performing migrations/ upgrades on Drupal websites. So, if you’re looking for a company to perform an upgrade for your Drupal 7 then do get in touch and we can perform an audit on your website.