Een website wordt zelden in één klap te zwaar. Het gebeurt geleidelijk: een CMS dat veel aankan, een stukje maatwerk erbij, een koppeling, een module voor iets dat destijds urgent leek. Na een paar jaar staat er een platform met behoorlijk wat technische mogelijkheden, terwijl wat de site dagelijks daadwerkelijk moet doen intussen best overzichtelijk is geworden.
Op zich is daar niets mis mee. Het levert alleen soms een merkwaardige verhouding op: een site met twintig informatiepagina’s die technisch evenveel onderhoud vraagt als een platform vol accounts, workflows en koppelingen. Niet omdat die twintig pagina’s zo lastig zijn, maar omdat de techniek eronder nooit is meegekrompen. En eerlijk gezegd: dat valt meestal pas op als het te laat is.
De techniek blijft, de aanleiding verdwijnt
Websites worden gebouwd met een bepaalde situatie in het achterhoofd. Er waren misschien plannen voor een groter platform, of meerdere redacteuren met verschillende rechten, of een koppeling met een systeem dat later alweer is vervangen. Op het moment zelf was dat allemaal een goede reden om iets uitgebreider te bouwen. Het probleem is dat die redenen meestal sneller verdwijnen dan de techniek die ervoor is neergezet.
Functionaliteit raakt in onbruik, een proces verandert, een onderdeel verhuist naar een ander systeem. Wat overblijft is vaak niet veel meer dan nieuws, een paar diensten, contactinformatie en wat formulieren — terwijl de technische constructie eronder gewoon blijft staan. Meestal valt dat pas op bij een grote upgrade, een beveiligingsprobleem of het aflopen van de ondersteuning voor een oude versie. Dan blijkt hoeveel techniek er nog draait voor functies die eigenlijk allang niet meer worden gebruikt. En dat is zonde van ieders tijd.
Een upgrade is meer dan een technische keuze
Bij een verouderde website gaat het gesprek al snel over versienummers: welke draait er nu, welke moet het worden, welke modules kunnen mee, wat moet er herschreven worden. Allemaal terechte vragen, maar ze slaan de belangrijkste over. Namelijk: wat moet deze website op dit moment nog kunnen?
Die vraag wordt gek genoeg vaak overgeslagen, precies omdat hij zo simpel klinkt. Voor een site die vooral publiceert, nieuws toont en bezoekers naar een contactformulier leidt, is dat antwoord meestal kort. En dan loont het om eens goed te kijken of de bestaande technische opzet daar nog wel bij past. Een upgrade betekent niet automatisch dat dezelfde machine opnieuw wordt gebouwd. Soms is de interessantere vraag waarom die machine ooit zo groot moest worden. En of je die omvang eigenlijk nog wel wilt meenemen.
Mogelijkheden zijn alleen waardevol als er iets mee gebeurt
Een uitgebreid rechtenmodel is prima wanneer er echt meerdere redacteuren zijn met verschillende bevoegdheden en publicatie via meerdere lagen gaat. Zware workflows, koppelingen en maatwerk hebben allemaal hun plek, zolang ze iets doen.
Het wordt vreemd zodra die mogelijkheden blijven bestaan nadat het gebruik ervan is gestopt. Ongebruikte techniek verdwijnt namelijk niet vanzelf; ze moet onderhouden, getest en meegenomen worden bij elke volgende upgrade. In de praktijk zien we regelmatig dat juist de dingen die een site níét meer gebruikt, een flink deel van het technische werk vormen. Meer mogelijkheden zijn dus niet automatisch meer waard. Ze zijn vaak vooral meer werk. En werk dat niemand meer echt nodig heeft.
Bij Drupal komt dit nogal eens voor
Drupal is populair omdat het zoveel kan, van kleine informatiesites tot platforms met uitgebreide rollen en integraties. Die breedte is precies de kracht van het systeem. Maar het betekent ook dat een simpele website technisch kan draaien op een fundament dat veel groter is dan nodig.
Dat een website ooit in Drupal is gebouwd, wil niet zeggen dat hij automatisch opnieuw in Drupal moet worden opgebouwd. Bij een upgrade kijken wij liever eerst wat er nog echt nodig is: welke content blijft, welke functionaliteit wordt daadwerkelijk gebruikt, welke onderdelen zijn er vooral omdat ze er ooit bijgekomen zijn, en wat verwacht de organisatie de komende jaren van de site. Het antwoord is niet altijd hetzelfde. Soms blijft Drupal de beste keuze, soms is WordPress praktischer, en soms blijkt een groot deel van de bestaande techniek gewoon overbodig. Dat laatste komt vaker voor dan de meeste mensen toegeven.
Eenvoudig is iets anders dan simpel
Dat onderscheid raakt weleens zoek. Een eenvoudige technische oplossing hoeft niet primitief te zijn — een website kan prima snel, veilig en professioneel zijn zonder dat er een zwaar technisch landschap onder zit. Minder onderdelen betekent vaak juist minder wat kan mislopen bij een volgende upgrade, en minder specialistische kennis om een kleine aanpassing door te voeren.
Dat maakt eenvoud geen doel op zich; ook een te kale oplossing kan verkeerd uitpakken. Waar het om gaat is verhouding: de techniek moet passen bij wat de website nu moet doen, niet bij wat hij ooit misschien had kunnen worden. En die verhouding is bij veel Drupal-sites uit balans geraakt.
Eerst kijken, dan pas kiezen
Een zinvolle technische vernieuwing begint daarom zelden met een CMS-keuze. Ze begint met kijken wat er op de website gebeurt, wat daadwerkelijk wordt gebruikt, wat moet blijven en wat de komende jaren nodig is. Pas daarna wordt de technische keuze interessant.
Dat klinkt minder spannend dan een complete herbouw, maar de winst zit vaak juist daar: niet elke website heeft een zware oplossing nodig, en soms is de slimste stap gewoon dat je niet alles opnieuw meeneemt. Minder spannend, wel praktischer.