Drupal 11 Upgrade Checklist – What to Consider Before You Upgrade

A Drupal upgrade can look straightforward until one overlooked dependency turns a routine release into a much larger project. The core update is rarely the only concern. Modules, custom code, hosting, integrations and deployment processes all influence the real upgrade effort.

For organisations moving from Drupal 10, timing also matters. Drupal 10 end of life arrives on 9 December 2026. No further Drupal 10 releases will follow after that date.

We have covered the wider business case separately in our Drupal 10 to Drupal 11 upgrade guide. This article takes the next step.

It assumes you are considering the move and need to know exactly what to inspect before production changes begin.

A useful Drupal 11 upgrade checklist should answer more than whether Drupal core can update. It should expose the dependencies that could disrupt users, editors, integrations or search visibility later.

Drupal 11 Upgrade Readiness at a Glance

Before starting a Drupal 11 upgrade, confirm that your current environment meets the basic technical requirements. Your website should already run Drupal 10.3.0 or later, alongside PHP 8.3+ and Composer 2.7.0+. Your database must also meet Drupal 11 requirements, so verify its version before planning the upgrade.

Next, review the parts of your website that sit around Drupal core. Every contributed module should have a Drupal 11-compatible release or a suitable replacement. Custom modules need closer inspection for deprecated APIs, while themes and frontend dependencies should be tested for compatibility. You should also check whether the site relies on any core extensions removed from Drupal 11.

Composer dependencies deserve their own review because an incompatible package can block the upgrade even when Drupal itself appears ready. Configuration exports, imports, and environment-specific settings should also be documented before development begins. At the same time, test critical integrations such as authentication, CRM, payment services, search platforms, and external APIs.

Preparation should also cover recovery and release planning. Keep recoverable backups, use representative staging, record performance benchmarks and define a clear rollback route before production changes begin.

Before You Change Code, Establish the Real Starting Point

A reliable upgrade starts with knowing what you actually have. Documentation often says one thing while the live application tells another story. Years of fixes, modules, patches and integrations can leave a different technical estate.

That is why the first stage should be a Drupal website evaluation, not a core update.

1. Confirm Your Current Drupal Version and Update Baseline

Check the exact core release running across development, staging and production. Drupal requires at least Drupal 10.3.0 before the Drupal 10 to Drupal 11 upgrade can proceed. However, meeting that minimum should not become the objective.

Bring Drupal core and supported contributed projects to suitable current versions before attempting the major upgrade. This creates a cleaner baseline and limits the number of changes introduced at once.

A neglected Drupal 10 installation may therefore need ordinary updates before the Drupal 11 work even starts.

2. Verify the Drupal 11 Requirements Against Your Hosting Stack

Do not assume your Drupal 10 hosting environment can run Drupal 11 unchanged.

Current Drupal 11 requirements include PHP 8.3 or newer and Composer 2.7.0 or later. Drupal 11 also raises several database minimums. For common databases, Drupal currently requires:

• MySQL 8.0+
• MariaDB 10.6+
• PostgreSQL 16+

Drupal’s system requirements confirm these minimums for Drupal 11. Look beyond version numbers as well. Review PHP extensions, memory allocation, caching services, search infrastructure and deployment tooling.

A compatibility problem discovered here is manageable. The same discovery during production deployment becomes much more expensive.

3. Build an Inventory of Everything Drupal Depends On

List every contributed module, custom module, theme and integration before changing the platform.

Do not limit the inventory to obvious features. Include authentication providers, payment gateways, CRM connections, search services, scheduled processes and custom APIs. Old patches and Composer packages belong on the list too.

This Drupal website evaluation gives you a dependency map. It also separates essential functionality from extensions nobody uses anymore.

Removing unnecessary dependencies before the upgrade often creates less risk than carrying them into Drupal 11.

Once you understand the current Drupal environment, the next step is compatibility. Core may be ready for Drupal 11 while modules, custom code, themes, or dependencies still need work. These checks usually reveal where most of the upgrade effort will sit.

IDS Logic can review your Drupal platform, custom code, modules, integrations and hosting requirements before development begins.

4. Run Upgrade Status Before You Remove Drupal 10 APIs

Run Upgrade Status against your current site before changing the major version. It checks environment requirements, contributed projects and code compatibility.

Static analysis can also identify deprecated APIs and other compatibility problems within custom projects.

The resulting Drupal Upgrade Status report becomes a practical remediation list rather than a last-minute warning.

Treat a clean Upgrade Status report as a technical indicator, not proof that the entire website works correctly. It cannot validate checkout rules, CRM logic or unusual editorial workflows, so functional testing still matters.

5. Check Every Contributed Module for Drupal 11 Compatibility

Contributed modules can determine the project timeline.

Some already support both Drupal 10 and Drupal 11. Others need an updated branch, replacement package or compatibility work. Where possible, update a module to a Drupal 11-compatible release while your site still runs Drupal 10.

Drupal’s official upgrade guidance recommends this multi-version approach because it reduces simultaneous changes during the core upgrade.

When no compatible version exists, investigate before applying an unofficial patch. Check the project issue queue, maintenance status and available alternatives. An abandoned module can create problems well beyond this upgrade. Sometimes the right decision is replacement rather than another temporary fix.

6. Check for Core Extensions Removed From Drupal 11

This is an easy item to miss because the affected functionality worked inside Drupal core previously. Drupal 11 removed several extensions that Drupal 10 had already deprecated. These include Actions UI, Activity Tracker, Book, Forum, Statistics and Tour.

If your site depends on one, decide how to handle it before the Drupal 11 code upgrade. Drupal advises either stopping its use or moving to the corresponding contributed project where available.

Do not simply uninstall a required module to make an error disappear. That could remove configuration your website still needs. Do not simply uninstall a required module to clear an error, as this may remove configuration your website still needs.

7. Audit Custom Modules for Deprecated Drupal APIs

Custom code deserves more scrutiny than contributed code because nobody else owns its Drupal 11 compatibility. Run Upgrade Status against your custom modules and identify deprecated APIs, services, plugins and other version-specific dependencies.

Drupal Rector can automate some recognised deprecation fixes, but it should not become your only remediation method. As of September 2026, the Drupal Rector project has no supported stable release and documents several automation limitations.

Preview any proposed changes first, then rerun Upgrade Status and resolve the remaining findings manually. Business logic still needs separate testing because technically valid code can behave differently after remediation.

For sites with substantial bespoke functionality, experienced Drupal development services can reduce uncertainty before production.

8. Test Custom Themes and Template Overrides

Backend compatibility receives most of the attention during an upgrade. Frontend regressions can be just as visible to users.

Review custom themes, Twig templates, preprocess logic, JavaScript dependencies and overridden components. Do not assume that pages rendering without an exception means the theme is correct.

Compare key templates visually. Check forms, navigation, responsive layouts, interactive components and accessibility behaviour. Content editors should also review preview and authoring experiences where the theme affects them.

9. Resolve Composer Dependencies Before the Upgrade Window

Composer dependency conflicts can expose relationships that are invisible in Drupal’s administration interface.

A contributed module may support Drupal 11 while another package still requires an incompatible dependency. Run dependency checks before your planned release window.

Understand why Composer refuses a version before forcing a different combination. Repeatedly relaxing constraints until Composer succeeds can leave you with an unstable dependency tree.

Drupal recommends using Composer for installation and updates, while Drupal 11 requires Composer 2.7.0 or later. Treat composer.json and composer.lock as controlled parts of the release rather than files repaired manually on production.

Once dependencies and Composer issues are under control, focus on recovery and release planning. Before production work begins, have reliable backups, controlled configuration and a tested rollback route ready.

10. Review Configuration Management Before Branches Diverge

When several environments or development streams exist, configuration management needs dedicated attention. Confirm exports are current and version controlled, then review environment-specific overrides and any splitting strategy.

Check whether active development has introduced configuration outside the upgrade branch. Conflicting exports or parallel changes can restore old settings or overwrite recent work, even when deployment completes successfully.

11. Test Every Third-Party Integration You Depend On

External systems do not care that Drupal core upgraded successfully. Your CRM, ERP, payment service, SSO provider, search platform and marketing tools still need to communicate correctly.

Document each integration before testing begins. Record authentication methods, endpoints, scheduled jobs, data formats and expected responses.

Then identify the business journey attached to each connection. Checking a CRM endpoint is useful, but confirming a real enquiry reaches the correct workflow tells you much more. The second test tells you whether the business process survived the upgrade.

12. Back Up the Whole Application, Then Prove You Can Restore It

“Take a backup” sounds simple enough to become dangerous. A database export alone is not a complete recovery strategy.

Your pre-upgrade recovery set should cover:

• database;
• public and private files;
• configuration exports;
• application code;
• Composer files;
• environment-specific settings;
• manual rollback instructions.

Drupal recommends taking complete backups before updates. Keep the database, uploaded files and application code recoverable, then test restoration before the production upgrade.

13. Build a Staging Environment That Actually Resembles Production

A staging server only reduces risk when its important characteristics match production.

Use comparable PHP, database and service versions. Reproduce integrations where practical. Include representative data while respecting privacy and security requirements.

If production uses Redis, external search or special caching, staging should not ignore those dependencies entirely. The closer your environments behave, the more useful your test results become.

14. Complete a Dry Run Before Scheduling Production

Your first Drupal 11 upgrade should never happen during the production maintenance window.

Run the complete path elsewhere first. Record the Composer changes, database updates, cache rebuilding, configuration imports and manual actions required.

Measure how long each part takes. Then reset and repeat where the environment allows it. A repeatable second run is much more reassuring than one successful attempt that nobody can reproduce.

Technical health checks matter, but customers and editors experience workflows rather than status reports. Your testing should therefore cover the complete journeys they rely on.

15. Test Business-Critical User Journeys

List the actions that would create the biggest problem if they failed. Then test them deliberately.

Depending on your site, that may include:

• user login and password recovery;
• content creation and publishing;
• enquiry and contact forms;
• ecommerce checkout;
• payments;
• site search;
• gated content;
• membership workflows;
• CRM synchronisation;
• scheduled imports or exports;
• email notifications;
• multilingual publishing.

Do not rely entirely on automated testing. Automation provides speed and repeatability, while manual testing catches context that scripts may miss. This balance matters particularly for older custom code and complex editorial behaviour.

16. Protect Existing SEO During Drupal Website Upgrades

A major CMS upgrade should not casually change search signals.

Before deployment, record your existing URLs, canonical tags, redirects, robots directives and XML sitemap behaviour. Check structured data where your site uses it.

After the release, crawl important templates again and compare the results. Analytics and Google Search Console tracking also need verification.

These checks are particularly important during Drupal website upgrades because technical changes can accidentally affect crawlability without obvious visual errors.

Keep working URL structures wherever possible. When a URL genuinely must change, prepare the redirect before launch rather than after rankings decline.

17. Measure Performance Before and After the Upgrade

Performance testing after deployment means very little without a comparison point.

Record a baseline before changing the platform. Measure representative pages, backend response behaviour and important user journeys under comparable conditions.

For UK organisations, Drupal performance tuning should go beyond headline page-speed scores.

Review caching, slow database queries, search behaviour, third-party calls and PHP configuration. Check Redis or other caching services where your stack uses them.

Frontend assets, images and Core Web Vitals still matter as well. The goal is not to prove Drupal 11 is “faster” in the abstract. You need evidence that your own implementation behaves correctly.

18. Run a Drupal Security Checklist Before Sign-Off

A supported Drupal version gives you a maintained foundation. It does not remove the need for security discipline.

Your Drupal security checklist should verify core and contributed project status, administrative access and unused extensions. Review logs, external sharing, authentication and backup processes where relevant.

Once Drupal 11 goes live, keep Drupal updates and patches within an ongoing maintenance process. Drupal publishes regular bug-fix and security release windows for supported core branches.

A major-version project should therefore improve your update process rather than become the last update anyone plans.

Core updates, security patches and performance work continue after launch. IDS Logic provides ongoing Drupal support for UK organisations.

What If Development Cannot Stop During the Drupal Upgrade?

Freezing all development for several weeks is unrealistic for many active websites. That does not mean feature work and the upgrade should happen without coordination.

Create a clear branch strategy before remediation starts. Decide which changes can continue safely and which should wait until the upgraded platform stabilises.

Configuration needs particular attention. Two branches changing the same content types, views or service settings can create difficult merges later.

Custom modules also need coordination when one developer changes business functionality while another removes Drupal 10 deprecations. For larger teams, automated testing and CI pipelines can detect compatibility problems earlier.

The release manager should still know which branch owns the final configuration and dependency changes. A short change freeze near production may remain sensible.

The difference is that you use the freeze for release control, not months of blocked development.

Our Drupal development team can also support upgrades alongside ongoing feature and integration work.

What Usually Gets Missed From a Drupal 11 Upgrade Checklist?

The obvious checks get attention. The quiet background processes often cause the awkward post-launch problems.

Cron jobs are a good example. A site can look healthy while a scheduled integration has silently stopped processing data.

Email delivery deserves the same scrutiny. Test transactional messages rather than assuming a successful form submission proves the email arrived.

Search indexes may also need rebuilding. Check redirects, sitemaps and analytics because they rarely appear in core compatibility reports.

Role permissions can change subtly when modules or workflows move. Editors should therefore test their own accounts, not only an administrator account.

Finally, update your operational documentation. Record the new platform versions, replaced modules and any changes to deployment steps. The next developer should not need to reconstruct the entire upgrade from Git history.

Your Final Production Release Checklist

By this stage, most of the difficult work should already be complete. Production deployment should feel controlled rather than experimental.

If several items remain unresolved, delaying the release is usually safer than investigating them on production.

Before approving the release, confirm the following:

• Drupal 11 compatibility checks show no unresolved blocking issues.
• Required contributed modules support the target release.
• Removed core extensions have a documented replacement or removal path.
• Custom code has passed static analysis and functional testing.
• Composer dependencies resolve reproducibly.
• Configuration changes are version controlled.
• Staging reflects the production architecture closely enough for meaningful tests.
• Database, code, files and configuration backups are current.
• The team has tested a recovery procedure.
• Business-critical user journeys pass.
• SEO checks show no unintended URL or indexing changes.
• Performance has been compared against the pre-upgrade baseline.
• Security checks show no known unresolved upgrade-related risks.
• Monitoring and logs are available after deployment.
• A named person owns the rollback decision.
• Stakeholders know when validation has finished.

Final Thoughts – The Checklist Should Remove Surprises Before Production

The safest Drupal upgrade is not necessarily the one with the shortest checklist. It is the one where dependencies and risks are understood before the release window.

Start with platform requirements, then work through modules, custom code, themes and Composer dependencies. Backups should be recoverable, while staging must represent production closely enough for meaningful testing.

Performance, security and SEO need deliberate validation because a technically successful update can still create wider website problems. Treat the Drupal 11 upgrade as controlled engineering work rather than a version-number change.

A thorough checklist does more than help you install Drupal 11. It gives you confidence that customers, editors and connected systems will still work afterwards.

When Do Professional Drupal 11 Upgrade Services Make Sense?

A small, well-maintained Drupal site may have a straightforward upgrade route. Complex platforms need a different level of planning.

Professional Drupal upgrade services become more useful when custom modules, integrations or legacy dependencies dominate the application. Multisite estates, active development and limited automated testing also increase coordination and regression risk.

The right support should begin with the existing environment rather than an immediate core change. A Drupal website evaluation can identify compatibility blockers, hosting constraints and custom-code remediation before the production window.

IDS Logic supports UK organisations with Drupal 11 upgrade services covering readiness assessments, module and custom-code compatibility, Composer dependencies, staging, testing and controlled deployment. Our Drupal specialists can also support performance, security and ongoing maintenance after the upgrade.

For complex Drupal website upgrades, this provides continuity from the initial assessment through production validation instead of dividing responsibility across several suppliers.

Identify compatibility risks before they affect your production website.