Essential Drupal 8 Modules: What Still Matters on a Legacy Site

By Greg Nowak. Updated July 28, 2026.

A Drupal 8 module list is no longer a shopping list. Drupal 8 reached end of life in November 2021, so the useful question is: which capabilities should you protect while stabilising the site and moving it to supported Drupal?

For business owners, that means preserving valuable URLs, reliable measurement and workable publishing. For operations and agency teams, it also means understanding which modules contain important configuration or data—and which merely add complexity to an already overdue upgrade.

Start with risk, not new features

An unsupported Drupal core cannot be made safe simply by updating a few contributed modules. Treat urgent maintenance as risk containment while planning the upgrade. The normal destination in 2026 is Drupal 11, although the project must pass through each intervening major version: Drupal 8 to 9, then 10, then 11. Drupal’s documented upgrade path does not allow major versions to be skipped.

Before changing dependencies, create a restorable database and file backup, work in a separate environment, and capture the current behaviour. A module inventory without configuration, custom code and regression checks is only half an audit.

Business need	What to inspect	Keep or replace?	Upgrade check
Protect established URLs	Redirect and Redirect 404	Usually keep the capability and its data	Export redirects; test chains, loops and high-volume 404s
Generate consistent aliases	Pathauto patterns and tokens	Usually keep	Compare aliases before and after each major upgrade
Publish an XML sitemap	Simple XML Sitemap configuration	Keep if deliberately configured	Exclude private, duplicate and low-value content
Measure conversions	Google Tag, another module or theme code	Keep the measurement plan, not necessarily the integration	Test consent, tag firing and conversion events
Deliver responsive images	Core Responsive Image mappings	Keep where the theme uses them	Review breakpoints, crops and generated image styles

A practical decision matrix for separating business-critical capabilities from legacy implementation choices.

The modules and capabilities that still matter

Redirect remains important because URL history has business value. Its records may protect search visibility, campaign links, bookmarks and integrations. Review frequently used redirects first, then identify loops, chains and destinations that no longer exist. Do not discard the redirect table during a rebuild just because the new information architecture looks cleaner.

Pathauto keeps URL aliases predictable for editors. Document every active pattern, its language rules and the tokens it uses. During an upgrade, create representative content in a test environment and compare the generated aliases with production. A small pattern difference can change thousands of URLs.

Simple XML Sitemap is useful when it reflects publishing intent. It can include entities, multilingual alternatives and custom links, but more indexed URLs are not automatically better. Confirm that unpublished, private, duplicate and low-value pages are excluded. Current releases target supported Drupal versions; older Drupal 8-era branches should not be mistaken for a long-term solution.

Analytics and tag management require a functional audit rather than a module checkbox. Find every place that can inject tags: modules, theme templates, consent tools and reverse proxies. Record the container or measurement IDs, important events and consent states. Then test them in a browser and in the analytics platform. This avoids silently losing conversion data during the upgrade.

Responsive Image is part of Drupal core. Check whether the theme actually uses its mappings and whether image styles still exist. Broken mappings can produce oversized downloads, missing derivatives or unsuitable crops after a theme change.

Run a read-only inventory first

Use the project-local Drush binary where possible. These commands collect evidence without installing modules or changing configuration:

vendor/bin/drush status
vendor/bin/drush pm:list --type=module --status=enabled
vendor/bin/drush config:status
vendor/bin/drush updatedb:status
composer outdated --direct
composer audit

The exact commands available depend on the site’s Composer and Drush versions. Save the output alongside the codebase audit. Also inspect composer.lock, custom modules, patches, abandoned packages and modules that are present but disabled. Disabled code can still complicate dependency resolution and deployment.

Install current releases only on the supported target branch

The old drush dl workflow should not be revived. Manage contributed code with Composer, then enable it with Drush. For a compatible Drupal 10 or 11 target branch—not the live Drupal 8 site—a current example is:

composer require drupal/redirect:^1.13 drupal/pathauto:^1.15 drupal/simple_sitemap:^4.2
vendor/bin/drush en redirect pathauto simple_sitemap responsive_image -y
vendor/bin/drush updb -y
vendor/bin/drush cr

Check the project pages and dependency resolution again before running this; releases continue to move. Commit composer.json and composer.lock, deploy through the normal pipeline, and never experiment directly on production.

A sensible upgrade workflow

Baseline the site. Record critical journeys, URLs, forms, scheduled jobs, integrations and analytics events.
Classify every extension. Mark it as required, replaceable, removable or custom. Assign an owner to unresolved decisions.
Upgrade one major version at a time. Update contributed projects before core where supported, run database updates, and address deprecations and custom code at each stage.
Test business behaviour. Crawl important URLs, validate redirects and the sitemap, submit forms, check editorial permissions and verify tags.
Deploy with recovery options. Use tested backups, a rollback plan and post-release monitoring for errors, 404s and lost conversions.

What not to add during the transition

Avoid convenience modules that duplicate core features, CSS injector tools used as permanent theme architecture, and one-off import modules left accessible after a migration. Each additional dependency creates another compatibility, security and testing decision. If a module solves no current business problem and carries no data you need, removal is often the best upgrade.

Turn the inventory into a decision

The goal is not to preserve Drupal 8 exactly as it is. It is to preserve the parts that matter—traffic, content, operational knowledge and measurement—while removing avoidable technical baggage. A broader SEO audit checklist can help verify the search-facing details.

If you need an independent view of whether to stabilise, upgrade or rebuild the site, contact Greg for a practical Drupal audit. You will get a prioritised plan rather than another unfiltered module list.