Uw website draait op Drupal 7. Hij doet het nog. Pagina’s zijn bereikbaar, formulieren werken en medewerkers kunnen inhoud aanpassen. Misschien is er zelfs al jaren nauwelijks iets aan veranderd. Waarom zou je er dan nu iets mee moeten?
Dat is een redelijke vraag. Het einde van Drupal 7 betekent namelijk niet dat websites op 5 januari 2025 ineens zijn gestopt met werken. Een Drupal 7-website die op 4 januari goed functioneerde, kon dat op 6 januari nog steeds doen. Wat op 5 januari 2025 veranderde, is iets anders: vanaf die datum wordt Drupal 7 niet meer regulier ondersteund.
Er komen vanuit het Drupal-project geen beveiligingsupdates, bugfixes of compatibiliteitsupdates meer. Ook de Drupal 7-versies van aanvullende modules zijn niet langer regulier ondersteund. Nieuwe beveiligingsproblemen kunnen openbaar worden zonder dat er vanuit het Drupal Security Team nog een oplossing voor Drupal 7 volgt. (drupal.org)
De website blijft dus draaien, maar het onderhoudsmodel waarop die website jarenlang kon vertrouwen, is verdwenen. En juist daar zit het probleem.
Een werkende website is niet hetzelfde als een onderhoudbare website
Bij oude software is het verleidelijk vooral te kijken naar wat je aan de voorkant ziet. Werkt de website, dan lijkt er weinig reden om in te grijpen. Maar software slijt niet zoals een auto. Drupal 7 wordt niet iedere maand een beetje langzamer omdat de onderdelen ouder worden. Een website kan jarenlang vrijwel onveranderd blijven functioneren.
Ondertussen verandert de omgeving eromheen wel. De server krijgt nieuwe software. PHP ontwikkelt zich verder. Browsers veranderen. Externe diensten passen hun API’s aan. Mailproviders stellen andere eisen. Bibliotheken worden vervangen. Hostingbedrijven stoppen uiteindelijk met oude configuraties. Een actief onderhouden applicatie beweegt daarin mee. Drupal 7 niet meer.
Daarom wordt de interessante vraag steeds minder of de website vandaag nog werkt. De betere vraag is wat er gebeurt wanneer er morgen iets aan moet gebeuren.
Beveiliging is het duidelijkste probleem, maar niet het enige
Het einde van de beveiligingsondersteuning krijgt terecht veel aandacht. Tot januari 2025 bestond er voor Drupal 7 een georganiseerd proces voor beveiligingsproblemen. Wanneer een kwetsbaarheid werd gevonden, kon het Drupal Security Team die onderzoeken en kon er een update verschijnen. Dat reguliere proces bestaat niet meer.
Daaruit volgt niet dat iedere Drupal 7-website op dit moment eenvoudig te hacken is. Dat kun je alleen beoordelen door naar de betreffende website, de geïnstalleerde modules, de configuratie en de omgeving te kijken. Wat wel vaststaat, is dat de normale route bij een nieuw Drupal 7-beveiligingsprobleem verdwenen is.
Drupal zegt daar zelf vrij duidelijk over dat Drupal 7 na het einde van de ondersteuning geen beveiligings- of compatibiliteitsupdates meer ontvangt. Beveiligingsproblemen kunnen bovendien openbaar worden zonder Drupal 7-fix of voorafgaande waarschuwing. (drupal.org)
Dat maakt een verschil. Vroeger kon beheer in veel gevallen bestaan uit: probleem bekend, update beschikbaar, update testen, update installeren. Nu kan de situatie zijn: probleem bekend, maar geen officiële Drupal 7-update beschikbaar. Dan moet een andere oplossing worden gezocht.
| Risico | Hoe waarschijnlijk? | Mogelijk gevolg |
|---|---|---|
| Nieuw beveiligingslek zonder officiële Drupal 7-patch | Middel | Hoog: er is niet vanzelfsprekend een reguliere update beschikbaar |
| PHP- of hostingomgeving verandert | Middel | Hoog: de site kan aanpassingen nodig hebben om te blijven draaien |
| Oude module of koppeling werkt niet meer | Middel | Middel tot hoog: functionaliteit kan uitvallen of maatwerk worden |
| Drupal 7-kennis wordt schaarser | Hoog | Middel: onderhoud en wijzigingen worden lastiger of duurder |
| Er moet onverwacht snel gemigreerd worden | Middel | Hoog: minder tijd om platform, scope en aanpak rustig te kiezen |
| Algemene stabiliteitsproblemen in de oude stack | Laag tot middel | Middel: problemen kunnen lastiger te onderzoeken en op te lossen zijn |
De techniek onder Drupal 7 staat ook niet stil
Drupal is maar één onderdeel van een website. Daaronder zit bijvoorbeeld PHP. Ook PHP wordt voortdurend doorontwikkeld en oudere PHP-versies verdwijnen na verloop van tijd uit de reguliere ondersteuning.
Drupal 7 heeft in zijn laatste jaren nog ondersteuning gekregen voor PHP 8.1, 8.2 en 8.3. PHP 8.4 wordt officieel niet door Drupal 7 ondersteund. (drupal.org)
Dat is een goed voorbeeld van het probleem dat langzaam ontstaat. Een hostingpartij wil zijn servers juist bij de tijd houden. Dat is wenselijk: nieuwe PHP-versies krijgen ondersteuning, oude versies uiteindelijk niet meer. Maar een Drupal 7-applicatie kan niet vanzelfsprekend mee naar iedere volgende versie.
Dat betekent niet dat uw hoster morgen de stekker eruit trekt. Het betekent wel dat het steeds waarschijnlijker wordt dat de website een uitzondering binnen de hostingomgeving gaat vormen. En uitzonderingen zijn meestal goed vol te houden tot het moment waarop er iets moet veranderen.
Vaak zit het probleem niet in Drupal zelf, maar in alles wat eraan hangt
Een doorsnee Drupal 7-website bestaat niet alleen uit Drupal core. Er zijn aanvullende modules geïnstalleerd. Er is vaak maatwerk aanwezig. Misschien is er een koppeling met een CRM, nieuwsbriefdienst, kaartendienst, inlogsysteem of andere externe partij.
Een deel daarvan kan nog jarenlang blijven werken. Maar stel dat zo’n externe dienst zijn koppeling verandert. Bij actuele software wordt een gebruikte module aangepast, verschijnt er een nieuwe versie of bestaat er een alternatief dat binnen dezelfde technische omgeving kan worden geïnstalleerd. Bij Drupal 7 is dat minder vanzelfsprekend.
De Drupal 7-versie van een module kan verlaten zijn. Een vervanger bestaat misschien alleen nog voor modern Drupal. Een nieuwe PHP-library die nodig is voor de koppeling kan eisen stellen waaraan de oude applicatie niet kan voldoen. Dan blijkt dat een ogenschijnlijk kleine wens ineens een veel groter technisch vraagstuk wordt.
Niet omdat die wens ingewikkeld is, maar omdat de ruimte om binnen Drupal 7 nog gewoon door te ontwikkelen steeds kleiner wordt.
“We veranderen toch bijna nooit iets aan de website”
Dat kan juist een goede reden zijn om niet halsoverkop een groot migratieproject te beginnen. Een eenvoudige Drupal 7-website die nauwelijks verandert, weinig koppelingen heeft en technisch goed is afgeschermd, kan een heel ander risicoprofiel hebben dan een druk gebruikte applicatie waarin dagelijks persoonsgegevens worden verwerkt en allerlei externe systemen zijn gekoppeld.
Alle Drupal 7-websites over één kam scheren heeft daarom weinig zin. Maar ook bij een eenvoudige website blijft één vraag belangrijk: wat gebeurt er als er onverwacht wél iets moet?
Een hostingomgeving moet worden aangepast. Een formulier stopt met mailen. Een gebruikte koppeling wordt beëindigd. Er wordt een serieus beveiligingsprobleem ontdekt. Een organisatie stelt nieuwe eisen aan toegankelijkheid of privacy. Of de website moet ineens worden uitgebreid. Op dat moment bepaal je liever zelf wat de volgende stap wordt.
Wanneer zo’n gebeurtenis eerst plaatsvindt en de oplossing daarna nog moet worden bedacht, is die keuzevrijheid kleiner. Daar zit voor veel organisaties het werkelijke risico van nog jarenlang niets doen. Niet dat Drupal 7 morgen vanzelf omvalt, maar wel dat het moment waarop je gedwongen wordt iets te doen, zich moeilijk laat plannen.
Moet Drupal 7 dan zo snel mogelijk weg?
Niet noodzakelijk. Er kunnen goede redenen zijn om een bestaande Drupal 7-website nog enige tijd in bedrijf te houden. Misschien wordt de website over een jaar vervangen vanwege een bredere huisstijlwijziging. Misschien is een migratie groot en moet daarvoor eerst budget worden vrijgemaakt. Misschien is de website onderdeel van een systeem dat binnenkort toch verdwijnt.
Ook bestaat er commerciële Extended Security Support voor organisaties die Drupal 7 na het officiële einde van de ondersteuning nog willen blijven gebruiken. De Drupal Association noemt momenteel HeroDevs en Tag1 Consulting als gecertificeerde aanbieders daarvan. (drupal.org)
Blijven draaien kan dus een verdedigbare keuze zijn. Alleen is het dan geen kwestie meer van regulier Drupal-onderhoud. Je kiest er bewust voor een end-of-life platform nog tijdelijk in stand te houden en moet bepalen hoe je de risico’s daarvan opvangt. Dat is een wezenlijk andere uitgangspositie dan vóór januari 2025.
En dan maar upgraden naar de nieuwste Drupal-versie?
Dat is één mogelijkheid, maar het is niet automatisch de juiste. Drupal 7 en modern Drupal liggen technisch ver uit elkaar. Een overstap is daarom niet vergelijkbaar met het installeren van een gewone versie-update. Content, configuratie, functionaliteit en maatwerk moeten worden beoordeeld en waar nodig gemigreerd of opnieuw gebouwd.
Als de bestaande website veel gebruikmaakt van wat Drupal goed kan, is dat prima te verdedigen. Denk aan uitgebreide contentstructuren, veel onderlinge relaties tussen content, complexe rollen en rechten, redactionele workflows, veel maatwerk of intensieve koppelingen met andere systemen. Dan kan modern Drupal opnieuw de logische technische basis zijn.
Maar er zijn ook heel veel Drupal 7-websites waarop dat verhaal niet van toepassing is.
Omdat Drupal er nu staat, hoeft Drupal niet terug te komen
Drupal 7 werd jarenlang voor zeer uiteenlopende websites gebruikt. Daar zitten omvangrijke platforms tussen waarvoor Drupal een duidelijke functie heeft. Maar ook websites van organisaties met voornamelijk gewone pagina’s, nieuwsberichten, documenten en een paar formulieren.
Voor zo’n website is de vraag of Drupal technisch kan worden vervangen door modern Drupal niet erg interessant. Natuurlijk kan dat. De interessantere vraag is waarom je opnieuw voor Drupal zou kiezen.
Als een website tegenwoordig met een eenvoudiger CMS goed kan worden gerealiseerd, kan dat een betere oplossing zijn. Minder techniek, minder maatwerk en een eenvoudiger beheeromgeving kunnen op langere termijn belangrijker zijn dan het behoud van het huidige CMS. Dat kan WordPress zijn, maar afhankelijk van de website zijn ook andere oplossingen denkbaar.
Het belangrijkste punt is dat Drupal 7 niet de keuze voor zijn opvolger zou moeten dicteren. De website is ooit in Drupal gebouwd op basis van de eisen en mogelijkheden van dat moment. Tien of vijftien jaar later mogen die uitgangspunten opnieuw worden bekeken.
Kijk daarom eerst naar de website en daarna naar het CMS
Wie begint met de opdracht “Drupal 7 upgraden”, heeft de oplossingsrichting eigenlijk al gekozen. Dat is soms terecht, maar niet altijd. Wij zouden eerst willen weten wat er daadwerkelijk staat.
Welke content bevat de website? Welke Drupal-modules worden gebruikt? Welk maatwerk is aanwezig? Welke koppelingen zijn belangrijk? Welke gebruikersrollen bestaan er? Welke functionaliteit wordt nog gebruikt en welke onderdelen zijn in de loop der jaren feitelijk overbodig geworden?
Dat laatste komt vaker voor dan je zou denken. Een website die tien of vijftien jaar in gebruik is, bevat bijna vanzelfsprekend technische resten van eerdere wensen: modules die ooit voor één functie zijn toegevoegd, contenttypen die nauwelijks nog worden gebruikt of maatwerk waarvan niemand meer precies weet waarom het bestaat.
Dat allemaal één op één meenemen naar een nieuw systeem is zelden verstandig. Een verouderd platform vervangen is ook een kans om de vraag opnieuw te stellen wat er nu eigenlijk nodig is.
Er zijn uiteindelijk drie serieuze routes
Na zo’n inventarisatie komt de keuze meestal neer op drie mogelijkheden.
De eerste is Drupal 7 nog tijdelijk in stand houden. Bijvoorbeeld omdat vervanging al gepland staat of omdat daar op korte termijn een andere goede reden voor is. Dan moet wel duidelijk zijn welke technische risico’s en afhankelijkheden daarbij horen.
De tweede is migreren naar een actuele Drupal versie. Dat ligt voor de hand wanneer de website functies gebruikt waarvoor Drupal nog steeds een passende keuze is.
De derde is de website vervangen door een ander platform. Vooral bij relatief eenvoudige websites kan dat praktischer en economischer zijn dan het reconstrueren van een oude Drupal-oplossing in een nieuwe Drupal-versie.
Geen van die drie is op voorhand voor iedere Drupal 7-website de juiste. Dat is precies waarom een algemene boodschap als “Drupal 7 is end-of-life, dus je moet upgraden” weinig helpt. Dat Drupal 7 end-of-life is, weten we. De vraag is wat dat voor deze website betekent.
Niets doen kan ook. Maar maak er dan wel een beslissing van
Misschien is de uitkomst dat je voorlopig niets aan de website verandert. Daar hoeft niets onverstandigs aan te zijn. Het verschil zit tussen bewust nog een tijd met Drupal 7 doorgaan en de beslissing voor je uitschuiven omdat de website vandaag nog werkt.
In het eerste geval weet je waarop de website draait, waar de kwetsbaarheden zitten, hoe lang je deze situatie wilt handhaven en welke route daarna waarschijnlijk volgt. In het tweede geval bepaalt uiteindelijk een gebeurtenis van buitenaf wanneer je moet handelen.
Dat kan volgende maand zijn, maar ook over twee jaar. Juist omdat niemand dat moment precies kan voorspellen, is het verstandig de keuze te maken vóórdat die keuze urgent wordt.
Waar begin je?
Niet met de vraag wat een migratie naar de nieuwste Drupal-versie kost. En ook niet met de vraag of WordPress goedkoper is. Begin met drie andere vragen:
- Wat moet er van de huidige website behouden blijven?
- Welke techniek is daarvoor werkelijk nodig?
- Hoe lang moet de volgende oplossing mee kunnen?
Als die drie antwoorden duidelijk zijn, wordt de keuze voor Drupal, een ander CMS of tijdelijk doorgaan met Drupal 7 meestal een stuk eenvoudiger. Dat uw Drupal 7-website vandaag nog werkt, is daarbij prettig. Het geeft u namelijk iets wat u beter kunt gebruiken voordat er daadwerkelijk een probleem ontstaat: tijd om zelf te kiezen wat de volgende stap wordt.