Drupal 7 to Drupal 9 Migration Strategy: Key Learnings

Introduction

In order to build any kind of a website, Drupal presents its friendly and powerful content management platform, Drupal 7. You name it and they have it. From Collaborative Social communities to Blogs and social sites. 

Its features include Flexible content, Better theming, accessible administration, and built-in feature of adding images to content. The other features include Automated code testing, Improved database support, Better distribution support.

Drupal 9 

Speaking of Drupal 9, it isn’t a reinvention of Drupal but has a few major differences which separates it from the rest. The first one being updates of dependencies to versions that stay supported and the second one being Removal of its own code that was disapproved with removal before the release of Drupal 9. 

Drupal 9 majorly is the same as Drupal 8.9 (which is the last Drupal 8 minor release), apart from the above mentioned two things. 

Drupal 7 To Drupal 9 Migration - The Big Leap

In one of our earlier blogs Picking The Right Drupal Migration Strategy, we discussed what are the different migration approaches and how this is a good chance to refactor the content structure. 

In this blog, we will see practical examples of the above steps in a way that would not be overwhelming for all the stakeholders. 

Handling The Content types, Taxonomy And Modules First

Considered as the building block in structured authoring in Drupal, a content type primarily consists of two important elements.

1. Content type base configuration
2. Content type fields

In a content type, the base configuration defines the default behavior and properties of the content type while they permit the creation of a set of fields that are associated together in a meaningful way. 

Taxonomy in Drupal:  It is a powerful core module that allows one to connect, relate and classify the website’s content. 

Thus, the practice of classifying content i.e. Taxonomy can be used in workflow which will further customize a particular or defined sections of the website with various themes. 

Content Types

We have highlighted the importance of handling the content when doing a migration in our earlier blogs Performing Drupal 9 Content Migration

To understand the content on our site better, it helps to look at the content with a fresh perspective. One of the ways in which it can be done is by categorizing the available content types. Some of the options are mentioned below. 

• Rely on the body field as a primary source of information 
• Rich in fields with different data types

Categorization such as above can help us optimize the target site. For example:

• Merging content types that rely on body field into a basic page with a mapping field to Drupal 7 content type
• We also need to decide which content types are not used and avoid them

Each content type can be documented through the following

• Field level requirements
• Content Retention policy (what to migrate and what not?)
• What are the aggregate pages for the content type and type of filtering required?
• What does the content view page look like and what should be displayed?
• Migration considerations specific to content type and assumptions made 

A migration like this is also a good time to revisit the taxonomies, number of users, and roles used in the site and add/remove items as needed.

Modules

This is the area where we need to be careful not to assume that everything is needed in the new site. During a Drupal Development site, it is natural for a lot of modules to be added but not used.

We recommend classifying the modules based on MoSCoW rules of prioritization. 

Required Modules (Must-Haves and Should-Haves)

The ones that fall under this category are mentioned below. 

• Core modules in Drupal 7 and contributed modules in Drupal 7 which are now in Drupal 9 core
• Contributed modules in Drupal 7 which are actively used by administrators and editors. Examples include performance modules like memcache, basic utility modules like admin menu, XML sitemap, etc.

Optional Modules (Could-Haves)

Modules that are used in Drupal 7 but are not needed in the initial phases of the site and can be included only if needed (like Features, Rules, and Panels), fall in this category. It is because a lot can be achieved with Drupal 9 which was only possible via a contributed module in Drupal 7.

It is important to validate the need for each module (contributed and custom). Besides this, try to have only the minimal modules in Drupal 9 as it eases the maintenance of the site during the longer run. 

Bringing the Roles and Content Workflow to work together

As far as roles are concerned, below are the recommended steps.

• Validate existing roles and redefine them based on actions done by the user
• Use combinations of roles for a user to achieve the actions they did on the Drupal 7 site
• If access to site content needs to be based on their categorization, the Permissions by Term module might be helpful
• Remove permissions that are duplicate or no more required
• If the control of the site needs to be decentralized, then the Group module is recommended
• Check for active users and only migrate them
• If the number of users is less, then it is better to do the new role mapping manually, as achieving them via migration scripts would be time-consuming considering the mapping process is a one-time migration activity

For the content workflow,

• Define clear content moderation states which each role can perform
• For sites with a simple workflow Drupal core’s Content moderation module is recommended
• For sites that used the Workflow module in Drupal 7 using the same in Drupal 9 would make the migration easy as there is an upgrade path
• If the site needs a workflow dashboard, email notifications Workbench suite with Workbench, Workbench Moderation, and Workbench Email serve well

How are we going to manage the media?

The need for media depends on the following:

• Is the media in the Drupal 7 site restricted to a specific type like only images and video or is it diverse enough like Files, Audio scripts, and any other custom media types which are specific to the site?
• What is the future scope of media in the site in Drupal 9 ? Are we expecting the site to be media-rich with lots of metadata?
• Do we need the same field to store different types of files?

Based on the above, we can decide if we need to have simple image and video fields to store the media. Another option can be leveraging the media module in a core that allows us to store different types of files in the same field. Custom media types can also be created with metadata.

It’s worth noting that the community has often thought of moving to media as part of the default Drupal install. That being said, it is extremely unlikely that simple file fields will disappear from the core in the foreseeable future. But if you are planning to pick media, you’re in good company.

Check references for more detailed approaches for migrating media

Based on the path we choose, we have some supporting modules.

• Simple Image/Video/File field path - File Entity Browser to browse files
• Media field in Drupal core - organize media with Media Directories module, Bulk Upload to upload a lot of files in one go

NOTE: Media Directories module provides only virtual directories and is not physical mapping to actual directories in the file system. Work in progress for the same. There is also work going on to support drag and drop for the media library.

A good time to do some field re-engineering

The goal to achieve from field re-engineering is to look at the data types of each field and validate if we are doing justice to them.

Below are some incorrect examples of field types commonly found in Drupal 7.

• Plain text is used where it should have been Date field
• CkEditor is being used where it should have been plain text

We can either do the following at the destination site

• change the field types and move the data (we might need to check if the data type between source and destination is compatible in this case )

(or)

• move them to the same type and then migrate from old to new field type on a case by case basis

This will immensely improve the editorial experience. 

Other than the above aspects, it is important to also consider the different integrations available in the current site and how we are going to achieve them in the migrated site. 

If these are custom integrations you have written, then you would have to rewrite these modules to be compatible with Drupal 9. That is a much larger topic and beyond the scope of this article.

Conclusion

We must document the above aspects as it clearly says the decision and route we take which would provide clarity for the team working on the migration.

References

• Migrating Files and Images, Migrate File, External reference
• Migrating to files then media, Migrate File Entities to Media Entities, External reference