How to Test a Drupal 11 Upgrade Before It Goes Live

If your site still runs Drupal 10, the clock is short. According to Drupal’s release schedule, “Drupal 10 will reach end of life on December 9, 2026.” Drupal 12.0.0 is planned for the same week. And you can’t jump from 10 straight to 12: Drupal’s upgrade overview says “A major version cannot be skipped during an upgrade.” Every Drupal 10 site has to go through Drupal 11.

The upgrade tools are good at telling you whether your code is compatible. They don’t tell you whether your pages still look right. This guide covers both: how the upgrade works, what it tends to change on the front end, and how to check every page before the upgraded site goes live.

Key dates and requirements

Dates are from Drupal’s release schedule, and PHP and database versions from its PHP and database requirements pages, checked on 9 November 2026. The schedule can move, so check it before you plan around a date.

Two things in that table are easy to miss. Your host has to run PHP 8.3 before you can upgrade, and that change alone can affect a site. And if you’re planning ahead for Drupal 12, it needs PHP 8.5.

What a Drupal 11 upgrade changes on the front end

Most of the work in a major upgrade is in the code: deprecated APIs, contributed modules and Composer constraints. But several changes reach what visitors see:

• jQuery 4. The latest Drupal 10 (10.6) ships jQuery 3.7.1, and Drupal 11.4 ships jQuery 4.0.0, according to each version’s core.libraries.yml. jQuery 4.0.0 removed long-deprecated functions such as jQuery.trim, jQuery.isArray and jQuery.parseJSON. A theme or custom module that still calls them throws a JavaScript error, and whatever that script did, such as a menu toggle, a slider or an accordion, stops working. For most sites coming from Drupal 10.6, this is the biggest front-end change.
• Removed core modules. According to the Drupal 11.0.0 release notes, Actions UI, Activity Tracker, Book, Forum, Statistics and Tour left core. If you use any of them, you either stop using them before the upgrade or replace them with the contributed version while you’re still on Drupal 10. Book and Forum pages are the most visible to visitors, but Activity Tracker and Statistics can also put content on public pages.
• Coming from an older Drupal 10. If you’re still on 10.3 or 10.4, moving to Drupal 11.4 also brings a much newer Twig (from 3.10 or 3.16 to 3.27 or later) and CKEditor 5 (from version 41 or 44 to 47.6), and, from 10.3, jQuery UI 1.14. Drupal 10.6 already ships nearly the same versions as 11.4, which is one more reason to update to the latest 10.x first.
• Scaffold files. Drupal’s upgrade guide warns that core files, .htaccess included, will change, so any customisations to scaffold files have to be documented and reapplied. A lost redirect or header rule can change what a page shows.
• Contributed modules. Many need a new major version for Drupal 11, and a new major version of a module is where markup, CSS and JavaScript change.

The visual effects of these changes don’t produce an error. A slider that stopped sliding or a view whose grid collapsed at tablet width is still a page that returns 200.

A testing plan for the upgrade

1. Get to the latest Drupal 10 first

You must be on Drupal 10.3.0 or later to upgrade. In practice, update to the latest 10.x release first, deploy it, and make sure the site is stable there. That separates problems caused by the minor update from problems caused by the major upgrade, and it gets the Twig, jQuery UI and CKEditor updates out of the way before the jQuery 4 change.

2. Check code compatibility

Install Upgrade Status. It checks your environment and every contributed and custom module and theme for Drupal 11 readiness, and lists deprecated code. For each contributed module, update to a release that supports Drupal 11. For custom code, Drupal Rector can fix some deprecations automatically, and Upgrade Status lists the rest.

If a module you depend on has no Drupal 11 release yet, the upgrade guide suggests looking for a compatibility patch in its issue queue and applying it with the help of Drupal Lenient, a Composer plugin that lets Composer install a module whose version constraints don’t allow Drupal 11 yet. Drupal’s documentation says Lenient shouldn’t be used in production, so treat that module as high risk in your testing and switch to a proper release as soon as one exists.

3. Choose the pages to check

You don’t need every node. You need one or two examples of everything that renders differently:

• the homepage and each landing page template
• one node of each content type, especially those built with Paragraphs or Layout Builder
• each view: listings, grids, search results, archives
• every page with a form: contact, newsletter, Webform pages, login
• pages that depend on JavaScript: menus, sliders, accordions, tabs, maps
• pages behind a login, if members or customers see a different layout
• the 403 and 404 pages

Check each at the widths your visitors use: at least one mobile, one tablet and one desktop width. Drupal themes are full of breakpoints, and an upgrade problem often appears at only one of them.

4. Build the upgraded site on a copy of production

Do the upgrade in a separate environment: a local DDEV site, which the Drupal upgrade guide recommends, a Pantheon Multidev, or a staging site. Before you start, copy the production database and files into it, so the only difference between the two sites is the upgrade. If the content differs, every new article shows up as a change and hides the ones that matter.

The upgrade itself, run from the Drupal root, comes down to these commands from the upgrade guide:

composer require 'drupal/core-recommended:^11' 'drupal/core-composer-scaffold:^11' 'drupal/core-project-message:^11' --no-update
composer config allow-plugins.symfony/runtime true
composer require drush/drush --no-update
composer update --dry-run
composer update
composer install
drush updatedb:status
drush updatedb

The allow-plugins line is needed because Drupal 11.4 added symfony/runtime, a Composer plugin that has to be allowed to run. The guide also covers file permissions before and after, removing drupal/core if it’s listed directly in composer.json, and what to do when Composer can’t resolve the dependencies. Follow it rather than this summary.

5. Compare the upgraded site with production

Now take screenshots of the same pages on production and on the upgraded copy, at the same widths, and compare them. Look for anything that moved, disappeared or changed style: spacing, fonts, icons, grids, menus. Check pages that need a login too, with a test account rather than an admin one, so the toolbar and edit links don’t get in the way.

Expect some intended differences: a contributed module’s new version may have changed its markup on purpose. Note those once, so the next round of comparisons only shows what’s new.

6. Check what screenshots can’t

A screenshot shows how a page looks, not whether it works. On the upgraded copy:

• open the browser console on your key pages and look for JavaScript errors, which is where jQuery 4 problems show up
• submit each form, log in and out, and run a search
• edit and save a piece of content as an editor, to check CKEditor and its plugins
• run your automated tests, if you have them, and watch the log while you click around with drush watchdog:tail, as the upgrade guide suggests
• run drush cron

7. Deploy and compare again

Deploy the upgrade, then repeat the comparison on production against the screenshots you took before. Production has things your copy may not, such as a CDN, real caching and the real .htaccess, and a final check there catches problems that appear only in that setup.

Doing the comparison with Diffy

Diffy is ours, so this is how we’d do step 5. It works from URLs, so it doesn’t need a Drupal module and works on any host and any Drupal version.

1. Create a project and import your pages from your XML sitemap, then keep one or two per template.
2. Add the upgraded copy as a second environment. Diffy swaps the domain in every URL, so one page list covers production and the upgraded site.
3. Compare the two environments. Diffy screenshots every page at every breakpoint you set, from 240px to 2000px, in Chrome or WebKit, and highlights what changed.
4. Mark each change as expected or as a bug, and share the comparison with the developers fixing it.

For pages behind a login, choose the Drupal preset under Authenticate and Diffy logs in through /user before it takes screenshots. If you work locally, the DDEV add-on lets Diffy screenshot your local upgraded site, so you can check it before it reaches a shared environment.

What it costs. Diffy counts one page at one breakpoint as one screenshot. Forty pages at three breakpoints is 120 screenshots per environment, so comparing production with the upgraded copy uses 240, and the check after deploy (step 7) adds another 120. The free plan covers 500 a month, with production and staging environments, which is enough for an upgrade check on a small site with room for one re-run after fixes. Paid plans start at $67/month billed annually ($80 monthly) for 2,000 screenshots. See pricing.

After the upgrade, the same project keeps working for monthly module updates and for scheduled checks of production. See visual regression testing for Drupal for the rest of the workflow, including pull request checks on Pantheon, Upsun and Tugboat.

Looking ahead to Drupal 12

Once you’re on Drupal 11, the next step comes into view. According to the Drupal 11 to 12 upgrade guide, which is still marked as a work in progress, Drupal 12 needs PHP 8.5 or later, and Ban, Contact, Field Layout, History, Migrate Drupal and Migrate Drupal UI are removed from core. The Contact module powers the contact form on a lot of sites, so check whether yours uses it. Drupal 12 also removes the core updates from before 11.3.0, so the upgrade overview says sites must be on 11.3.0 or higher before upgrading to Drupal 12.

There’s no rush to move to Drupal 12 on day one: Drupal 11.4 has security support until 21 April 2027, and 11.5 is planned for the same week as Drupal 12.0.0. But the testing plan is the same. Pick the pages, upgrade a copy of production, and compare before you deploy.

Frequently asked questions

When does Drupal 10 reach end of life?

On 9 December 2026, according to Drupal’s release schedule. After that, Drupal 10 gets no more security releases. Drupal 12.0.0 is planned for the same week.

Can I upgrade from Drupal 10 directly to Drupal 12?

No. Drupal’s upgrade overview says a major version can’t be skipped, so a Drupal 10 site has to upgrade to Drupal 11 first, and be on Drupal 11.3.0 or later, before it can upgrade to Drupal 12.

What do I need before upgrading to Drupal 11?

Drupal 10.3.0 or later, PHP 8.3, a supported database (MySQL 8.0, MariaDB 10.6, PostgreSQL 16 or SQLite 3.45 at minimum), and Drupal 11 compatible releases of your contributed modules and themes. The Upgrade Status module checks most of this for you.

What can break visually in a Drupal 11 upgrade?

The most common causes are JavaScript that relies on functions removed in jQuery 4, new major versions of contributed modules that change their markup or CSS, removed core modules such as Book and Forum, and lost changes to scaffold files such as .htaccess. A page with one of these problems usually still loads without an error, so compare screenshots of your key pages before and after.

How many pages should I check after a Drupal upgrade?

One or two of each content type, view, landing page template and form, plus pages that rely on JavaScript and pages behind a login, at a mobile, a tablet and a desktop width. For most sites that’s 20 to 50 pages.

Start before the deadline

With Drupal 10’s end of life weeks away, the upgrade is going to happen on a tight schedule for many sites. Taking a set of screenshots of production now, before anything changes, gives you something to compare the upgraded site with.

Try Diffy free: 500 screenshots a month, no test suite required.

Related reading: Visual regression testing for Drupal · What breaks during WordPress and Drupal updates · Website migration testing checklist