Drupal migratie en upgrade

Drupal 10 loopt op 9 december 2026 uit support

Draait je site op Drupal 10, dan heb je tot 9 december 2026 om te upgraden.
Vanaf die datum verschijnen er geen releases meer voor Drupal 10, ook geen beveiligingsupdates.
Dat is dezelfde week waarin Drupal 12 uitkomt.
Drupal 10.6.0 is de laatste minor release die nog verschijnt.

Wat dat praktisch betekent: elk lek dat na die datum in core of in een contributed module wordt gevonden, blijft op jouw site open staan.
Voor een brochuresite is dat vervelend.
Voor een site die persoonsgegevens verwerkt, betalingen afhandelt of onder een aanbesteding valt, is het een aantoonbaar risico dat je moet kunnen verantwoorden.

De goede kant van het verhaal: als je op Drupal 10 zit, is de stap naar Drupal 11 geen herbouw.
Sinds Drupal 8 is een major upgrade een update geworden, geen migratie.
Dat is precies waarom uitstellen zo zonde is.

Welke versie draait er en wat betekent dat

Weet je niet welke versie je draait? Dat staat in het beheerdersscherm onder Rapportage, Statusrapport.
Of vraag het je huidige partij.
Kun je er niet bij, dan kan ik het meestal van buitenaf inschatten.

Van Drupal 10 naar 11 is een upgrade, geen migratie

Bij een upgrade van 10 naar 11 blijft je site je site: dezelfde content, dezelfde structuur, hetzelfde thema.
Wat er moet gebeuren, zit in de techniek eronder.

• Verouderde code opruimen. Drupal markeert functies die verdwijnen ruim van tevoren als deprecated.
  Wat in Drupal 10 nog een waarschuwing was, is in 11 een fout.
  Dit raakt vooral maatwerkmodules en het thema.
• Modules controleren. Elke contributed module moet een Drupal 11-compatibele release hebben.
  Voor de meeste veelgebruikte modules is dat inmiddels zo.
  Voor nichemodules soms niet en dan is de vraag: patchen, vervangen of laten vallen.
• Serveromgeving. Drupal 11 stelt hogere eisen aan PHP en de database.
  Dat is vaak een kwestie van een knop bij de hoster, maar het moet wel gebeuren en het moet getest worden.
• Thema en frontend. Twig is meegegaan naar een nieuwe versie.
  Dat raakt templates die oude syntax gebruiken.

Hoe lang dit duurt, hangt vrijwel volledig af van de hoeveelheid maatwerk.
Een site die dicht bij standaard Drupal blijft en nette modules gebruikt, is een overzichtelijk traject.
Een site met jaren aan gegroeid maatwerk vraagt eerst een inventarisatie voordat iemand een termijn kan noemen.

Van WordPress naar Drupal

Die stap is zinvol als je tegen de grenzen van WordPress aanloopt, niet omdat Drupal beter zou zijn.
Concrete aanleidingen die ik in de praktijk zie: complexe contentstructuren met veel onderlinge relaties, echte meertaligheid, strenge eisen rond rechten en workflows, of een integratie met systemen die verder gaat dan wat een plugin kan.

Draai je een blog of een overzichtelijke bedrijfssite die het goed doet, dan is overstappen geld uitgeven aan een probleem dat je niet hebt.
Ik zeg dat liever vooraf dan achteraf.

Technisch verloopt zo'n migratie via de WordPress-export of rechtstreeks op de database.
Aandachtspunten zijn de URL-structuur, die je moet behouden of netjes moet omleiden en de media, die vaak rommeliger zijn opgeslagen dan mensen denken.

Hoe zo'n traject verloopt

1. Inventarisatie. Welke versie, hoeveel maatwerk, welke modules, welke integraties, hoe is de hosting ingericht.
   Hier komt uit wat het werk werkelijk is, in plaats van wat het lijkt.
2. Plan met een begroting. Wat gaat mee, wat vervalt, wat wordt vervangen.
   Inclusief een inschatting in dagen en de volgorde van uitvoeren.
3. Uitvoering op een aparte omgeving. De bestaande site blijft draaien.
   De migratie wordt herhaalbaar opgezet, zodat je hem meerdere keren kunt draaien met verse content.
4. Controle en livegang. Redirects, structured data, toegankelijkheid en snelheid worden meegenomen.
   Een migratie is het moment waarop je die dingen goed zet, want je zit toch al in de code.

Wat ik zelf belangrijk vind: een migratie is geen goed moment voor een herontwerp.
Twee grote veranderingen tegelijk maken het onmogelijk om vast te stellen waar een probleem vandaan komt.
Eerst migreren, dan doorontwikkelen.

Zoekmachines en AI meenemen in de migratie

Het grootste risico bij een migratie zit niet in de techniek maar in de adressen.
Verandert je URL-structuur zonder dat er redirects staan, dan verlies je in één keer wat er aan vindbaarheid is opgebouwd.
Dat is te voorkomen, maar alleen als je het vooraf inricht.

Concreet: een volledige inventaris van bestaande URL's vóór de migratie, 301-redirects voor alles wat van adres verandert en na livegang een controle of de sitemap klopt en of structured data intact is.
Voor AI-zichtbaarheid geldt hetzelfde principe: schema.org-markup en een llms.txt die na de verhuizing nog naar bestaande pagina's wijzen.