Audit every custom module before scheduling a Drupal update. A custom-module audit reviews site-specific code for removed APIs, deprecated code, dependency conflicts, and platform requirements. Without that audit, a proposed change window is only a guess. The findings determine whether the work is a routine update, a code-remediation project, or a staged major-version upgrade.
Table of Contents
- Why custom code controls the schedule
- What should the audit examine?
- Include the platform and upgrade path
- Turn findings into a realistic work plan
- Audit external libraries separately
Why custom code controls the schedule
Major drupal releases can remove code that earlier releases merely deprecated. Drupal's upgrade guidance says custom modules and themes must replace Drupal 9 deprecations removed in Drupal 10 before that upgrade begins in its Drupal 9-to-10 instructions. Each custom module can therefore create work beyond installing new packages.
A module may need API replacements, dependency changes, configuration updates, database updates, or regression testing. The audit should record each module's purpose, business owner, maintainership, dependencies, and affected site functions. That context helps the team decide whether to update, rewrite, replace, or retire it.
What should the audit examine?
Start with automated compatibility checks, then review the results manually. For Drupal 10-to-11 planning, Drupal recommends Upgrade Status to locate gaps and Drupal Rector with Upgrade Status to replace deprecated custom code in its major-upgrade procedure.
Inspect each custom module for: Automated results are evidence, not a complete estimate. Drupal warns that Upgrade Status does not identify every issue, so teams must verify releases, patches, compatibility claims, and maintainer plans manually.
- Deprecated or removed APIs
- Core and contributed-module dependencies
- Composer library dependencies
- Database schema or update hooks
- Configuration changes
Include the platform and upgrade path
A code audit alone cannot establish readiness. A Drupal 10-to-11 project also requires a Drupal 10.3 or later starting point, PHP 8.3 or later, Composer and Drush access, and compatible hosting. Check the current major version before estimating the project.
Drupal does not support skipping an intervening major release, so a Drupal 9 site must pass through Drupal 10 before reaching Drupal 11. That limits simultaneous extension database changes but adds another upgrade stage. A practical readiness record should include: For a minor update, incompatibility may still affect timing. Drupal's guidance recognizes that custom or contributed modules might not support the newest minor release; a supported previous minor receiving security fixes can provide time to resolve the gap.
- Current Drupal core version
- PHP and hosting compatibility
- Composer and Drush availability
- Required intermediate core versions
- Unsupported modules or themes
Turn findings into a realistic work plan
Separate discovery from implementation. Estimate remediation only after the team knows which modules need mechanical changes, manual redesign, replacement, or removal. Build the schedule around a local rehearsal.
Before production work, Drupal recommends attempting the upgrade locally, running a Composer dry run, applying database updates, and testing automated checks, logs, and cron. Use the rehearsal to measure the complete sequence: The production window must cover more than Composer's package operations. Database updates, cache rebuilding, configuration review, and validation all consume time and can expose failures after the new code is present.
- Back up the database
- Resolve Composer dependencies
- Deploy code changes
- Apply database updates
- Rebuild caches
Audit external libraries separately
Do not treat the absence of a Drupal security advisory as proof that every dependency is safe. Drupal's advisory process covers supported stable core and eligible contributed-project releases, but external libraries do not receive Drupal Security Team advisories under its published security policy.
Review Composer-managed libraries as a separate audit stream. Run `composer audit`, document unresolved findings, and assign remediation before approving the update window.
