Een Drupal-upgrade roept bij veel organisaties dezelfde vragen op. Hoe groot is de impact? Hoeveel tijd kost het? Welke risico’s zijn eraan verbonden? En vooral: moet alles in één keer gebeuren, of kan een upgrade ook gefaseerd worden uitgevoerd? Het korte antwoord is: ja, in veel gevallen kan dat. Maar daarbij is het belangrijk om goed te begrijpen wat onder een gefaseerde upgrade wordt verstaan.
Een Drupal-website kan niet zonder meer gedurende langere tijd half op de ene en half op de andere Drupal-versie draaien. Drupal core, modules, thema’s en technische dependencies vormen samen één geheel. Op het moment van de daadwerkelijke upgrade moeten die onderdelen onderling compatibel zijn.
De fasering zit daarom vooral in de voorbereiding. Juist daar kan veel werk vooraf worden uitgevoerd, waardoor de uiteindelijke overgang naar een nieuwe Drupal-versie overzichtelijker en beter beheersbaar wordt.
Wat betekent gefaseerd upgraden?
Een Drupal-upgrade bestaat uit meer dan alleen het vervangen van Drupal core door een nieuwere versie. Bij een oudere of complexere website komen vaak meerdere werkzaamheden samen. Denk aan het controleren van gebruikte modules, het aanpassen van maatwerk, het vervangen van verouderde libraries, het wijzigen van de PHP-versie en het oplossen van dependency-conflicten.
Die werkzaamheden hoeven niet allemaal op hetzelfde moment te worden uitgevoerd. Een mogelijke aanpak is bijvoorbeeld om eerst vast te stellen welke onderdelen een upgrade blokkeren. Vervolgens kunnen niet langer ondersteunde modules worden vervangen, maatwerkmodules worden aangepast en technische dependencies worden opgeschoond.
Pas wanneer de belangrijkste blokkades zijn weggenomen, volgt de daadwerkelijke upgrade van Drupal core. Dat is in de praktijk wat we onder een gefaseerde Drupal-upgrade verstaan: niet een website die langdurig in een technische tussenfase blijft staan, maar een upgrade waarvan de voorbereidende werkzaamheden bewust worden opgesplitst.
Waarom een upgrade faseren?
Het belangrijkste voordeel van faseren is niet noodzakelijk dat er minder werk hoeft te worden uitgevoerd. Het voordeel zit vooral in de mate van controle. Bij een grote upgrade kunnen verschillende problemen tegelijk zichtbaar worden. Een module blijkt niet meer ondersteund, een maatwerkfunctie gebruikt verouderde Drupal-API’s en tegelijkertijd moet de serveromgeving naar een nieuwere PHP-versie.
Wanneer al die wijzigingen in één traject worden uitgevoerd, wordt het lastiger om vooraf te bepalen waar de echte risico’s zitten. Door de werkzaamheden op te delen, kunnen technische problemen eerder worden geïdentificeerd en afzonderlijk worden opgelost. Dat maakt ook de kosten beter inzichtelijk. Na een eerste inventarisatie kan bijvoorbeeld blijken dat het grootste deel van de website probleemloos kan worden meegenomen, maar dat één specifieke maatwerkmodule veel extra werk vraagt. In dat geval kan eerst worden besloten wat met die functionaliteit moet gebeuren, voordat de rest van de upgrade wordt uitgevoerd.
Wat faseren niet betekent
Een gefaseerde Drupal-upgrade kan veel rust geven, maar het is goed om vooraf duidelijk te hebben wat ermee bedoeld wordt. Faseren is bijvoorbeeld niet:
- Dat de website maandenlang ‘half geüpgrade’ kan blijven draaien. De uiteindelijke overgang naar een nieuwe Drupal-versie blijft een technisch samenhangend moment.
- Dat iedere technische wijziging zomaar los van de rest kan worden uitgevoerd. Sommige onderdelen zijn onderling afhankelijk en moeten daarom bewust in dezelfde stap worden meegenomen.
- Dat de totale hoeveelheid werk vanzelf kleiner wordt. Faseren maakt een traject vooral overzichtelijker en beter beheersbaar; het neemt noodzakelijk werk niet weg.
- Dat er zonder eindplan alvast wat onderdelen kunnen worden aangepakt. Juist bij faseren is het belangrijk vooraf te weten waar het traject naartoe werkt, anders ontstaat het risico op dubbel werk.
Welke onderdelen kunnen vooraf worden aangepakt?
Een aantal werkzaamheden leent zich bijzonder goed voor een gefaseerde aanpak.
Modules controleren en vervangen
Een Drupal-website kan in de loop der jaren tientallen contributed modules verzamelen. Sommige daarvan worden actief onderhouden, andere nauwelijks meer. Vooraf kan worden onderzocht welke modules geschikt zijn voor de beoogde Drupal-versie en welke moeten worden vervangen.
Soms blijkt een module bovendien niet meer nodig te zijn, omdat de betreffende functionaliteit inmiddels standaard in Drupal core aanwezig is. Door dit vooraf op te lossen, wordt de daadwerkelijke upgrade eenvoudiger.
Maatwerk controleren
Maatwerkmodules en maatwerkthema’s verdienen bij een upgrade altijd extra aandacht. Drupal verandert tussen hoofdversies regelmatig API’s en interne structuren. Code die jarenlang probleemloos heeft gewerkt, kan daardoor in een nieuwe versie aanpassing nodig hebben.
Met hulpmiddelen zoals Upgrade Status en statische code-analyse kan een groot deel van deze problemen vooraf worden gevonden. Waar mogelijk kan maatwerk vervolgens al geschikt worden gemaakt voor zowel de huidige als de toekomstige Drupal-versie.
Composer en dependencies opschonen
Moderne Drupal-installaties worden doorgaans via Composer beheerd. Daardoor is Drupal afhankelijk van een groot aantal PHP-packages.
Bij oudere websites ontstaan soms versiebeperkingen die een upgrade blokkeren. Een package vereist bijvoorbeeld een oudere Symfony-versie, terwijl de nieuwe Drupal-versie juist een nieuwere versie nodig heeft. Ook dergelijke conflicten kunnen vaak vóór de daadwerkelijke core-upgrade worden onderzocht en opgelost.
Hosting en PHP voorbereiden
Nieuwe Drupal-versies stellen doorgaans ook hogere eisen aan PHP, Composer en de database. Het is daarom verstandig om vroeg in het traject te controleren of de hostingomgeving geschikt is.
Soms kan een PHP-upgrade vooraf worden uitgevoerd. In andere gevallen moet die juist gelijktijdig met de Drupal-upgrade plaatsvinden. Dat hangt af van de compatibiliteit van de huidige website. Ook hier helpt een gefaseerde aanpak om vooraf duidelijk te krijgen welke volgorde technisch mogelijk is.
En wat kan niet onbeperkt worden gefaseerd?
Er zit wel een grens aan wat afzonderlijk kan worden uitgevoerd. Drupal core en de bijbehorende database-structuur moeten uiteindelijk bij elkaar passen. Hetzelfde geldt voor modules die alleen met een specifieke Drupal-versie werken.
Een website maandenlang laten draaien in een situatie waarin verschillende onderdelen eigenlijk voor verschillende hoofdversies bedoeld zijn, is daarom geen goede strategie. De uiteindelijke overgang naar een nieuwe Drupal-versie blijft een samenhangend technisch moment. Dat betekent echter niet dat al het voorbereidende werk ook tijdens dat moment hoeft te gebeuren. Juist door zoveel mogelijk vooraf te doen, kan dat kritieke deel van het traject relatief compact blijven.
Hoe kan zo’n gefaseerd traject eruitzien?
Een praktische aanpak kan bijvoorbeeld uit vijf fasen bestaan. In de eerste fase wordt de bestaande website geïnventariseerd. Daarbij wordt gekeken naar Drupal core, modules, maatwerk, PHP, Composer en andere technische afhankelijkheden.
Vervolgens worden de belangrijkste upgradeblokkades aangepakt. Niet-ondersteunde modules worden vervangen, maatwerk wordt aangepast en overbodige technische componenten worden verwijderd. Daarna kan de daadwerkelijke Drupal-upgrade op een ontwikkel- of testomgeving worden uitgevoerd.
In de volgende fase wordt de website functioneel getest. Niet alleen technisch, maar ook vanuit het gebruik: werken formulieren nog, blijven rechten correct, functioneren koppelingen en zoekfuncties zoals verwacht? Pas wanneer die controles zijn afgerond, volgt de productie-overgang.
Wanneer is faseren vooral zinvol?
Een gefaseerde aanpak is met name interessant bij websites die al langere tijd bestaan, meerdere Drupal-versies achterlopen of relatief veel maatwerk bevatten. Ook wanneer de technische historie niet volledig bekend is, kan het verstandig zijn eerst onderzoek te doen voordat een volledige upgrade wordt ingepland. Bij een kleine, goed onderhouden Drupal-website kan een directe upgrade juist efficiënter zijn. Faseren is geen doel op zichzelf. De juiste aanpak hangt af van de technische staat van de website en van de hoeveelheid onzekerheid die vooraf aanwezig is.
Conclusie
Een Drupal-upgrade kan dus zeker gefaseerd worden uitgevoerd, mits duidelijk is wat daarmee wordt bedoeld.
De daadwerkelijke overgang naar een nieuwe hoofdversie blijft een samenhangend technisch proces. Maar een groot deel van het onderzoek, het opruimen van dependencies, het vervangen van modules en het aanpassen van maatwerk kan vooraf afzonderlijk worden uitgevoerd. Daarmee wordt een upgrade niet per definitie kleiner, maar wel beter voorspelbaar.
En juist bij oudere of complexere Drupal-websites is dat vaak het belangrijkste voordeel: eerst inzicht krijgen in wat er werkelijk moet gebeuren, voordat de meest ingrijpende stap wordt gezet.