Source Site Audit - A High Level Overview

Series Overview & ToC | Previous Article | Next Article

One of the most impactful things to do in preparation for any migration project is to understand the source site. The more insight you gather into how the current site was built, the better equipped you will be to perform the migration. While reviewing the site, analyze what works well, what can be improved, and what can be dropped. The audit can be broken down in two parts: a high-level overview of the site architecture, and an in-depth analysis of the content model. This blog post covers the former and the next one in this series will explain the latter. Note that for better results, there must be fluid communication between the developers in charge of performing the migration and the product owners who use the site on a regular basis.

Let’s start by noting all elements of the site that are no longer needed or functioning. Examples of this are: content types with no nodes associated, fields that were never used, webforms with no submissions, and disabled views or rules. This category should also include modules that integrate external services that have been shut down. In recent years, Google shut down the Sheets v3 API and Universal Analytics for Analytics. In cases like these, you might need to install newer versions of modules, apply patches to make them compatible with new versions of the APIs, or find alternative modules.

Next, identify cruft that does not need to be moved into the new site. Content types or fields labeled “old,” “deprecated,” “do not use,” or similar, are glaring examples of things that do not have to be migrated to Drupal 10. Also, consider whether blocked users or unpublished nodes need to be migrated. In the case of nodes, the analysis should be done on a per content type basis. For example, if you are using workbench moderation to moderate content for a content type, it is expected to have unpublished nodes while they go through the publication workflow.

Also, consider how the business has changed since the site was originally launched. Previously, I worked on a migration from a Drupal 6 site that had been in operation for over a decade. A key aspect of the site was to present up-to-date information about retailers across multiple countries and languages. By the time the migration project started, the organization no longer had representation in a handful of countries. Therefore, it was decided that any information associated with countries that had no current retailers should not be moved to the new site. Additionally, processes that have been offloaded to third-party services may help simplify the upgrade procedure. For instance, if order processing is handled by an external provider, it might not be necessary to implement a shopping cart in the new site nor migrate legacy order data.

If the current site is multilingual, do translations need to be carried over? In the Drupal 6 project I mentioned, some languages were dropped. If there were no retailers in a specific country, any language used exclusively in that country did not need to be migrated. Sometimes multilingual features are configured but never fully adopted, or abandoned due to lack of resources. Another scenario is when curated translations are discarded in favor of services like Google Translator. Whether for technical reasons, a change in business needs, or budget constraints, evaluate whether some, or all, translations can be left out of the upgrade.

Analyze why and how enabled modules are being used. I have seen sites use the Webform module to build a contact form. Another site used the Rules module to send an email when content is updated. And, there was a project that used the Flag module to mark a piece of content ready for review. While all are valid use cases, these examples introduced large codebases when barely utilizing the features each module provided. The Webform implementation can be replaced by Drupal core’s Contact module and the Contact Storage contributed module if persisting submissions was a requirement. The rule to send an email can be implemented using custom code. And the flag to signal content that is ready for review can be substituted by a boolean field on the content type. Webform, Rules, and Flag are useful modules and their use is justified in many scenarios. The point here is to understand to what extent you are currently leveraging enabled modules. When planning the update, evaluate whether their implementation could be replaced by Core functionality, other contributed modules, or custom code.

Do you use the same installation to serve multiple sites? Is it a single codebase and multiple databases in a multisite Drupal installation? Or is it a single database serving multiple domains via the Domain access module? No matter the technical implementation, careful evaluation is needed when a single installation is used for more than one site. From a technical standpoint, check whether users’ accounts and content are shared among sites. Business needs, ease of maintenance, security implications, and complexity in the migration process should all be considered.

If your site was built using a Drupal distribution, first check if there is a Drupal 10 compatible version. If so, confirm that there is an automated upgrade path. Make sure to read the documentation regarding the upgrade procedure. It is likely that the content model and the modules to assemble the distribution have changed and manual tasks may need to be performed. An example is FarmOS, which provided an automated upgrade path from Drupal 7 to Drupal 9 (the current version at the time). If your distribution does not offer this, search for projects that could help with the migration. For instance, if your site was built on Commerce Kickstart for Drupal 7, the Commerce Migrate can help migrate commerce-related data into Commerce for Drupal 10, whether the new site uses the distribution or not.

Even though most of the things we have mentioned are technical in nature, it is important to present the results to different stakeholders. Their perspective and feedback will enrich the analysis. It will also help get the team aligned and keep expectations in check for the project. In the next article, we will continue to audit the site with an in-depth analysis of the site structure.

Series Overview & ToC | Previous Article | Next Article (coming May 1st)

Image by Pexels from Pixabay