Van Drupal 10 naar Drupal 11: het volledige upgradepad

Drupal 10 bereikt end of life op 9 december 2026 — volgens het officiële releaseschema dezelfde week waarin Drupal 12 wordt uitgebracht. Na die datum verschijnen er geen nieuwe releases van Drupal 10 meer, ook geen beveiligingsupdates. De overstap naar Drupal 11 is geen herbouw zoals de sprong van Drupal 7 naar 10 was: uw database, content en configuratie blijven intact en u werkt de codebase bij. Het werk zit in de omgeving, in contrib-modules en in verouderde API-aanroepen in uw eigen code.

Waarom dit geen migratie is, maar een upgrade

Sinds Drupal 8 draait Drupal op Symfony en op een semantisch versiemodel. Van Drupal 8 naar elke volgende major geldt hetzelfde principe: functionaliteit wordt eerst gemarkeerd als deprecated in een minor release, blijft daar werken, en verdwijnt pas in de volgende major. Wie zijn site op de laatste minor van Drupal 10 houdt en de deprecation-waarschuwingen wegwerkt, doet de eigenlijke overstap met een handvol Composer-commando's.

Dat verschilt fundamenteel van Drupal 7, waar content daadwerkelijk via het Migrate-framework naar een nieuwe database moest worden overgezet. Wie nog op Drupal 7 zit — end of life sinds 5 januari 2025 — heeft een ander traject voor de boeg dan wat hieronder staat.

Drupal 10.6.0 is volgens drupal.org de laatste minor release van Drupal 10. De beveiligingsondersteuning van 10.5.x eindigde in de week van 29 juni 2026; die van 10.6.x loopt tot de week van 7 december 2026. Wie nu nog op 10.5 of lager staat, draait dus al zonder dekking.

De harde toegangseisen

Drupal 11 verhoogt de ondergrens op vrijwel elk onderdeel van de stack. Dit is het eerste dat u controleert, want een hostingpakket dat op PHP 8.2 of MySQL 5.7 vastzit, blokkeert het hele traject.

Twee eisen worden stelselmatig onderschat. De eerste is de databaseversie: MySQL 5.7 naar 8.0 is een servermigratie met eigen risico's (strict mode, sql_mode, collations), geen configuratievinkje. De tweede is Drupal 10.3.0 als absolute ondergrens — een Drupal 11-upgrade vanaf 10.2 of lager weigert simpelweg.

Drupal 11.x ondersteunt op dit moment PHP 8.3 en 8.4. Ondersteuning voor PHP 8.5 in Drupal 11 loopt nog als open core-issue. Dat is relevant voor uw hostingplanning, want Drupal 12 vereist volgens de gepubliceerde platformeisen wél PHP 8.5.

Stap 1 — eerst naar de laatste Drupal 10

Breng de site naar 10.6.x voordat u iets anders doet. Dat is een gewone minor update en levert twee dingen op: u krijgt de deprecation-meldingen te zien die relevant zijn voor Drupal 11, en u staat op de enige Drupal 10-lijn die nog beveiligingsdekking heeft.

Zet in dezelfde fase PHP op 8.3 of hoger, nog terwijl u op Drupal 10 draait. Drupal 10.4 tot en met 10.6 ondersteunen PHP 8.1 tot en met 8.4, dus u kunt de PHP-sprong en de Drupal-sprong loskoppelen. Dat is belangrijk: gaat er iets stuk, dan weet u welke van de twee het veroorzaakte.

Stap 2 — Upgrade Status draaien

De module Upgrade Status inventariseert wat er nog niet klaar is. Hij controleert de systeemeisen van de volgende major, kijkt via Update Status welke contrib-projecten al een Drupal 11-compatibele release hebben, en scant custom code met PHPStan op verouderde API-aanroepen.

composer require --dev 'drupal/upgrade_status:^4.3'
drush en upgrade_status

Het rapport staat onder Beheer » Rapportage » Upgrade status. De module heeft ook Drush-integratie (drush upgrade_status:analyze), zodat u de scan in een CI-pijplijn kunt hangen. Wat u eruit haalt is een lijst in drie stapels: projecten die klaar zijn, projecten die een update nodig hebben, en projecten waar nog geen Drupal 11-versie voor bestaat. Die derde stapel bepaalt uw planning.

Upgrade Status repareert zelf niets. Waar een probleem automatisch op te lossen is, verwijst het rapport door naar Drupal Rector.

Stap 3 — custom code opschonen met Drupal Rector

Drupal Rector automatiseert een deel van de codewijzigingen die deprecations vereisen: gewijzigde service-signatures, verplaatste klassen, verouderde functieaanroepen.

composer require --dev palantirnet/drupal-rector
cp vendor/palantirnet/drupal-rector/rector.php .
vendor/bin/rector process web/modules/custom --dry-run

Draai altijd eerst met --dry-run en lees de diff. Laat de wijzigingen daarna wegschrijven door het commando zonder die vlag te herhalen. Het rector.php-configuratiebestand hoort in de projectroot te staan, naast uw documentroot (web of docroot), niet erin.

Rector dekt niet alles. Custom thema's met verouderde Twig-constructies, oude jQuery-code en zelfgeschreven hook-implementaties die naar verdwenen core-modules verwijzen, blijven handwerk.

Stap 4 — de zes extensies die uit core verdwijnen

Drupal 11 verwijdert zes extensies uit core: Actions UI, Activity Tracker, Book, Forum, Statistics en Tour. Gebruikt uw site er één, dan heeft u twee opties: de functionaliteit uitzetten vóór de upgrade, of de contributed versie installeren terwijl u nog op Drupal 10.3+ draait.

Kies vrijwel altijd de tweede route, en doe het vóór de code-upgrade. Wisselt u van core-module naar contrib-module terwijl u nog op Drupal 10 staat, dan blijven tabellen en configuratie op hun plaats en merkt u er inhoudelijk niets van. Doet u het achteraf, dan bent u aan het puzzelen met een site die de module niet meer kent.

Forum en Book vragen hierbij de meeste aandacht, omdat ze publieke content bevatten die aan URL's hangt. Controleer vóór de omzetting welke paden en aliassen eraan verbonden zijn.

Los hiervan zijn Single Directory Components en Help Topics als aparte extensie vervallen; die functionaliteit is in core opgenomen.

Stap 5 — contrib die nog niet klaar is

Voor modules zonder Drupal 11-release waarvoor wel een patch bestaat, is er de Drupal Lenient Composer-plugin. Die herschrijft de drupal/core-constraint van Drupal-extensies, zodat ze naast core 11 geïnstalleerd kunnen worden. Let op: de oude lenient-endpoint van drupal.org (packages.drupal.org/lenient) is vervallen — de plugin is de opvolger.

composer require mglaman/composer-drupal-lenient
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/naam_module"]'

De documentatie op drupal.org waarschuwt expliciet dat u deze plugin niet in productie moet gebruiken. Behandel het als tijdelijk verband, per module expliciet toegestaan. De plugin kent ook een allow-all-schakelaar; gebruik die niet, want dan installeert u ook modules die daadwerkelijk kapot zijn onder Drupal 11 en verliest u het overzicht dat Upgrade Status u net gaf.

Stap 6 — de upgrade zelf

Dit is de kortste stap. Onderstaande volgorde komt uit de officiële handleiding op drupal.org.

chmod u+w web/sites/default
chmod u+w web/sites/default/*settings.php
chmod u+w web/sites/default/*services.yml

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 remove drupal/core --no-update
composer require drush/drush --no-update
composer require 'drupal/core-dev:^11' --dev --no-update

composer update --dry-run
composer update

composer install
drush updatedb:status
drush updatedb

chmod 755 web/sites/default
chmod 644 web/sites/default/*settings.php
chmod 644 web/sites/default/*services.yml

Let op het --no-update op elke composer require: u stapelt eerst alle constraints en lost ze daarna in één keer op. composer update --dry-run is niet optioneel — daar ziet u welke pakketten Composer niet kan verzoenen, vóórdat u uw composer.lock overschrijft. Staat drupal/core expliciet in uw composer.json, dan moet die regel eruit; anders vecht hij met core-recommended.

Alle core-bestanden worden vervangen, inclusief .htaccess. Heeft u scaffold-bestanden aangepast, leg die wijzigingen dan vóór de upgrade vast, zodat u ze erna kunt terugzetten.

Draait de site na afloop en is het Upgrade Status-rapport schoon, dan kan de module er weer uit:

drush pm:uninstall upgrade_status -y
composer remove drupal/upgrade_status --no-update

Exporteer tot slot uw configuratie (drush config:export) en commit die, zodat de update-hooks die core heeft gedraaid ook in uw repository landen.

De valkuilen die tijd kosten

• De databaseserver. MySQL 5.7 naar 8.0 op productie is een apart project met eigen testronde. Plan het los en eerder.
• Patches in composer.json. Elke patch die tegen een Drupal 10-bestand is geschreven, faalt vermoedelijk tegen de Drupal 11-variant. Inventariseer ze vóór de upgrade, niet tijdens.
• Custom thema's. Verwijderde jQuery-libraries en gewijzigde Twig-templates in core leveren geen foutmelding op maar een stilzwijgend kapotte pagina. Alleen visueel testen vangt dit.
• Contrib zonder onderhoud. Modules waar al jaren geen release van is verschenen, komen er niet meer. Beslis nu of u ze vervangt of de functionaliteit schrapt — dat is een inhoudelijke keuze, geen technische.
• De volgorde omdraaien. Eerst upgraden en dan pas Upgrade Status draaien is het klassieke recept voor een omgeving die niet meer opstart en waar u niet meer terug kunt.

Planning richting 9 december 2026

De verleiding is om te wachten tot Drupal 12 er is en dan in één keer door te gaan. Dat is onverstandig: op de dag dat Drupal 10 stopt, is Drupal 12 nul dagen oud en heeft het contrib-ecosysteem er nog nauwelijks iets voor uitgebracht. Drupal 11 is op dat moment ruim twee jaar in omloop en is bovendien het verplichte tussenstation.

Houd er bij het plannen rekening mee dat Drupal 12 volgens de gepubliceerde platformeisen PHP 8.5 vereist en dat opnieuw extensies uit core verdwijnen — de documentatie noemt Ban, Contact, Field Layout, History, Migrate Drupal en Migrate Drupal UI. Die documentatie is nog in bewerking tot de release, dus behandel dat deel als richting, niet als vastgesteld draaiboek.

Realistische fasering: omgeving en PHP in het eerste blok, Upgrade Status en de contrib-inventarisatie in het tweede, custom code en thema in het derde, de daadwerkelijke upgrade plus regressietest in het vierde. Elke fase is los af te ronden en op te leveren. Begin bij het tweede blok — de inventarisatie kost weinig en vertelt u meteen of dit een week of een kwartaal wordt.

Meer achtergrond bij de einddatum en wat er precies stopt, staat op de pagina over Drupal 10 end of life. Loopt u vast op de inventarisatie of op contrib zonder Drupal 11-release, dan kan een Drupal-specialist die stap overnemen.