By Greg Nowak. Updated October 12, 2026.
If your business still runs on Drupal 8, an essential module list should help you protect what works and decide what happens next. The priorities are usually straightforward: keep enquiries coming in, preserve valuable URLs, let editors publish reliably, and move the site onto supported software.
The difficult part is understanding what each module carries with it. A seemingly minor extension may hold years of redirects, support a sales integration, or provide a field used throughout your content. Start by connecting modules to business needs before deciding what to keep, replace or remove.
Drupal 8 maintenance needs an exit plan
Drupal 8 reached end of life on November 17, 2021. Updating contributed modules does not restore security support for core. As of October 2026, Drupal 11 is a sensible supported destination; Drupal 10 reaches end of life on December 9, 2026. Treat Drupal 10 as an intermediate step in this project. These dates come from the official Drupal release schedule.
For an in-place upgrade, Drupal requires each major version in sequence: 8 to 9, then 10, then 11. Rehearse those stages away from production. A rebuild with content migration is a separate approach and needs its own data mapping, URL preservation and acceptance tests.
Decide which capabilities deserve protection
Use this matrix to start a discussion between the site owner, developers and the people who publish content. Add an owner and a decision for every installed extension.
| Business need | Module or implementation | Preserve | Acceptance check |
|---|---|---|---|
| Keep established links working | Redirect; Redirect 404 | Redirect records and useful URL history | Important old URLs reach the correct destination without loops |
| Maintain predictable URLs | Pathauto; Token | Existing aliases, patterns and language rules | Editing and creating content produce expected aliases |
| Publish a useful sitemap | Simple XML Sitemap | Inclusion settings and custom links | Generated URLs are public, canonical and intended for indexing |
| Measure enquiries and sales | Tag module, theme code or consent integration | Measurement IDs, event definitions and consent behaviour | A test conversion fires once in the appropriate consent state |
| Display images correctly | Core Responsive Image; theme mappings | Image styles, breakpoints and required crops | Representative pages deliver suitable images on mobile and desktop |
Audit the modules that affect traffic and publishing
Redirect and Pathauto need to be reviewed together. The Redirect project supports manual redirects and canonical URL handling, while Pathauto can work with it to protect links when aliases change. Preserve existing aliases as well as generation patterns: rebuilding patterns alone will not reproduce every manually edited URL. Test language prefixes, renamed pages, redirect chains and campaign landing pages.
Simple XML Sitemap needs an intentional configuration. Review which content types, languages and custom links belong in it. Check the generated output for unpublished, private or duplicate pages. The current project documentation identifies 3.x as unsupported and provides an upgrade path from 2.x and 3.x to 4.x. Custom sitemap integrations still need review because the APIs changed.
Analytics needs a browser test. Find every place that injects tags, including modules, templates and consent tools. Record the important events, then submit a test enquiry and confirm it appears correctly. Check for duplicate tags and accidental tracking from staging.
Responsive Image belongs in the theme review. It is a core module, but enabling it does not prove the theme uses its mappings. Check image styles, generated derivatives and crops after any theme change.
Extend the same audit to forms, search, commerce and integrations where present. Ask editors which tasks depend on custom behaviour; a module inventory will not reveal every operational dependency.
Collect evidence before changing dependencies
Use the project-local Drush version already compatible with the site. These diagnostic commands inspect status rather than applying updates:
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 auditAvailability depends on the installed Drush and Composer versions; check each command's help if needed. According to the Composer CLI documentation, outdated --direct lists newer direct dependencies, while audit checks packages against dependency policies, including known security advisories. A clean audit does not establish that an unsupported Drupal site is safe.
Inspect composer.lock, patches, custom modules, themes and packages present but unused. Configuration exports do not replace database backups: redirect records, submissions and other entity data may live in the database. Test restoration of the database and public and private files before rehearsing upgrades.
Use Composer on the supported target branch
Keep the old drush dl workflow retired. On a compatible Drupal 11 development branch, the following remains a useful example for capabilities you have decided to retain:
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 crThis is a dependency and enablement example, not a complete core upgrade procedure. Check release compatibility and review the dependency changes before running it. Commit composer.json and composer.lock, then deploy through the established pipeline.
Turn the audit into a delivery plan
Classify extensions as keep, replace, remove or investigate. Before uninstalling anything, identify its data and dependencies; uninstalling can delete information you need. Rehearse each upgrade stage with the appropriate PHP and database environment, resolve custom-code compatibility, and record repeatable deployment steps.
Agree acceptance checks with the business: key URLs resolve, forms deliver, editors retain the right permissions, scheduled jobs run, and integrations and conversion events work. Define rollback around code, database and files together, including how new submissions will be handled during a cutover.
If the team needs help choosing between an upgrade and a rebuild, discuss a Drupal audit with Greg. Start with the site version, repository access and the workflows that matter most, so the next step can be scoped around your business.
Related on GrN.dk
- Drupal Relaunch: What Happens to Your Content and Old URLs?
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- Before you launch a vibe-coded feature, plan the production handoff
Need help with this kind of work?
Discuss your Drupal site with Greg Get in touch with Greg.
