Migrating Your Data from Drupal 7 to Drupal 10: Source Site Audit - An In depth Analysis

Series Overview & ToC | Previous Article | Next Article

In the previous article, we analyzed the site from a high-level perspective. It is time to dive deeper into the site structure. Use this source site audit template as a starting point. Feel free to add more elements or remove some if they are not relevant for your project. Filling the template can take a couple of hours, but it will save a lot of time down the road. Once the template is filled out, the developers performing the migration and the product owners should review it together and discuss the findings.

The first part of the template is an analysis of enabled projects: modules and themes. For each one, determine whether there is a version compatible with Drupal 10. If so, pay attention to the stability of the project. From highest to lowest stability, projects can have full releases, release candidates, beta, alpha, and development versions. Ideally, a project has a full release. Otherwise, beta versions tend to be stable enough and can be used. Note that from a security standpoint, only full releases are covered by the Drupal security team, so consider internal policies when conducting your evaluation. For instance, I have worked with organizations that only allow using stable modules with security coverage. In the list of projects, include any custom module or theme and add a note stating what each one is responsible for.

To fill out the module and themes tab in template, I recommend using the Upgrade Status module. Upon installation, it will automatically check for Drupal 10 compatibility for enabled projects and, in the cases where none is found, provide recommendations for alternative modules where available. For example, the Drupal 7 Address Field module is not available in Drupal 10, but the Address module can be used in its place. Most of the Date contributed modules made it into Drupal 10 core, but some features like recurring dates might need extra modules. Note that the availability of a module does not guarantee an automated upgrade path. Sometimes, one module provides the upgrade path for another. For instance, you can use Drupal 10 Paragraphs in place of Drupal 7 fields collections. Another example is the Migrate: URL2Link module, which provides a migration path for the URL module on Drupal 7 to the Link module in Drupal 10 Core. Even if no upgrade path is available, being able to use the module in the new site may suffice. Either a manual configuration or a custom migration can make up for the lack of an upgrade path.

*Partial screenshot of the report provided by the Upgrade Status module.

Next, list and review all content types, how many nodes are for each type, and the percentage of nodes that are unpublished. Content types with few published nodes can be removed, or their content manually recreated, in the new site. If a content type has no nodes, remove it altogether. Always keep in mind how a content type is being used. For example, using the Workbench Moderation module can make a content type have a high percentage of unpublished nodes, yet the content type and the nodes need to be preserved.

Consider how the different content types are being used and whether they need to be recreated in the new site. It is possible that the content types are needed, but the nodes are not. For each content type, take note and provide examples of whether the node is used as a standalone page or as part of a listing page. This will help in other aspects of the migration project, such as estimating theming efforts. Even if obvious in most cases, be sure to note how nodes of each type are created, and whether they are embedded as part of other content types or entities.

For taxonomy terms, it is useful to know how many terms are in each node. Also, take note of any vocabulary that has fields attached to them. All vocabularies that do not have fields can be migrated in a single migration. For those with fields, a separate migration is necessary. The same analysis can be applied to other fieldable content entities like paragraphs and field collections.

The next step is to create a list of all the fields on the site. Drupal 7 already includes a field list report at /admin/reports/fields which can be referenced directly. It is particularly important to note the different field types that exist and which modules provide them.

A technical note: In Drupal 7, a field could be shared across bundles of multiple entity types while, in Drupal 10, fields can only be shared among bundles of the same entity type. In Drupal 7, it was possible to share a field between a content type and a taxonomy vocabulary. In Drupal 10, each entity will have its own field, even if it has the same name. This might affect your migration strategy.

In the views portion of the template, make sure to take note of the base table. That is, whether the view was initially set up to list nodes, users, files, taxonomy terms, or another entity. Also, include information about plugins that are provided by modules outside of Drupal core and Views itself. For example, Views bulk operations, Views data export, Better exposed filters, and Views slideshow. Views migration is not supported as part of the core Migrate API. Modules like Views migration take a best-effort approach in migrating them. The generated migrations need to be reviewed and, where necessary, manually updated. The template suggests that you keep one record per view, but a view can have multiple displays. If you want a more granular analysis, add a column for the display.. If you decide to take a more granular approach, focus on the views that you know are critical for the project.

For the webforms tab, take note of how many submissions have been captured. Additionally, the publication status of the node and the webform itself are useful to determine whether they should be migrated or not. Webforms can include extra functionality, like sending the collected data via email or to an external API endpoint. The Webform: Migrate module does a very good job of automatting the migration of configuration and content related to webforms. Similar to Views, a manual review and update process may be necessary.

In the files tab, list all the schemes currently in use on the site: public, private, temporary, etc. Are you using private files? Are you using an S3-like backend, for your public files with the S3 file system module? What are the mime types of uploaded files? If using the File Entity module in Drupal 7, what are the different media entities available? I tend to find unexpected things when reviewing Drupal’s managed files on sites that have been running for a couple of years. At the very least, determine which schemes and mime types need to be migrated.

Regarding access controls, what roles are available on the site? Can some of them be merged, removed, or separated into multiple roles? What about the permissions for each of them? Should blocked users be migrated? Are there modules like Profile 2 that integrate with the user entity? If so, look at the Profile module in Drupal 10 for a feature parity and a migration path.

For text formats, ask yourself: what text formats are in use? Are they configured with a WYSIWYG editor? What text filters are being used? Which roles have access to which text formats? The PHP code filter provided by the PHP module should raise red flags in terms of security. If media is embedded as part of rich text fields, the Media Migration module can help with migrating those as well as converting the underlying references to media types.

Next, compile a list of image styles and effects being used. If the upgrade includes a redesign, some of them might not need to be migrated. Or, you can choose to use a completely different set of image styles in a responsive theme implementation. While not common, it is possible that a module relies on specific PHP extensions to work properly. That is, in addition to ext-gd, which is already a requirement for Drupal core.

When you fill out the template, aim to strike a balance between what is useful information and the time needed to collect it. Depending on the size of the project and the modules in use, it can take one to five hours to gather the data. Once collected, present it to your stakeholders and discuss it together.

Image by Christine Aubé from Pixabay