Homepage

Upgrading Drupal 8, 9 or 10 to Drupal 11

Use this path when the site is already on the modern Drupal generation, but updates have stalled. For the client, this means extending the life of the existing site while keeping content and core workflows in place.

What this means for the client

  • the goal is not to rebuild the whole website from scratch;
  • existing content, URLs and workflows should remain as stable as possible;
  • before changes start, it becomes clear which modules or custom parts block the upgrade;
  • PHP and hosting requirements often need to be upgraded as part of the same work;
  • JavaScript still needs review even when the old design or existing interface is kept;
  • data protection, keys and encryption-related parts also need review;
  • work happens in a test environment where forms, checkout flows, login and editing can be checked;
  • release is planned so there is a clear rollback option if needed.

When this is needed

  • the site runs on Drupal 8, Drupal 9 or Drupal 10;
  • Drupal core, modules or PHP version are behind;
  • the Composer workflow is broken or incomplete;
  • custom modules use deprecated APIs;
  • the theme or interactive parts depend on old JavaScript;
  • data storage or encryption choices are outdated;
  • you need to know what actually blocks a move to Drupal 11.

What WebPro checks

  • Composer packages, lock file and dependency conflicts;
  • PHP version and server requirements;
  • module readiness for Drupal 11;
  • custom modules, theme layer and deprecated code;
  • JavaScript errors, dependencies and interface behaviour;
  • keys, passwords, sensitive data and encryption-related configuration;
  • configuration, database updates and key user flows.

How the work runs

  • we create or clean up the local and test environments;
  • if the project does not yet use Composer properly, we first move it into a Composer-based workflow;
  • we upgrade in small steps through the next Drupal versions instead of making one large jump;
  • we upgrade PHP in the same plan when needed, because Drupal 8, 9, 10 and 11 do not have the same requirements;
  • at each step, we fix deprecated code, module conflicts and PHP requirements;
  • we check JavaScript, form behaviour, menus, filters, checkout flows and other interactive parts;
  • we review data flow and encryption-related areas, especially around forms, users and integrations;
  • when useful, stable intermediate versions can be published to the live site so risk does not build up into one large release;
  • we run database updates in the test environment and verify the result;
  • we add Playwright and PHP checks where useful;
  • we agree on release timing and rollback options for each important step.

What to know before starting

Drupal 8, 9 and 10 upgrades can be much more direct than Drupal 6 or 7 migrations, but risk grows quickly when the project has custom modules, an old theme, old JavaScript, missing security updates, an old PHP version, outdated data protection or no test environment. For the client, the important distinction is whether this is a regular upgrade or whether parts of the solution need rebuilding.

Next step: describe the current Drupal version, whether the project uses Composer and which workflows must not break.

Fill in the contact form