Wie dagelijks tientallen Drupal-websites beheert, ziet dingen die je met één of twee sites eenvoudig mist. Niet omdat die ene site minder belangrijk is, maar omdat vergelijking ontbreekt. Wij beheren Drupal-omgevingen voor uiteenlopende organisaties: MKB-sites, portals voor non-profits, en complexe omgevingen binnen overheid en semipublieke instellingen. Die variatie, gecombineerd met schaal, dwingt tot scherpere keuzes. En tot conclusies die je niet uit documentatie haalt, maar uit dagelijks werk.
Waar een intern team vaak jarenlang met dezelfde site leeft, zien wij voortdurend verschillen: in configuratie, in maatwerk, in onderhoudsgeschiedenis. Juist dat naast elkaar leggen maakt zichtbaar wat in beheer werkt, en wat structureel risico oplevert.
Gestandaardiseerde processen zijn geen luxe, maar noodzaak
Bij één website kun je veel oplossen met gezond verstand en incidentele ingrepen. Bij twintig of dertig omgevingen werkt dat niet meer. Elke uitzondering wordt herhaald, elke afwijking vermenigvuldigt zich. Zonder vaste werkwijzen ontstaat onvermijdelijk ruis.
Daarom zijn onze processen gestandaardiseerd. Updates, gebruikersbeheer, back-ups, incidentafhandeling: elke handeling volgt dezelfde stappen. Niet omdat elke site gelijk is, maar omdat de handeling dat moet zijn. Dat voorkomt dat beslissingen telkens opnieuw genomen moeten worden, en verkleint de kans op fouten.
Updates zijn daarin het duidelijkste voorbeeld. We werken niet per site ad hoc, maar met een vaste update-cyclus: eerst testen in een aparte omgeving, controleren op maatwerk en afhankelijkheden, daarna gecontroleerd uitrollen. Rollback-scenario’s zijn vooraf bekend. Toen eind 2022 een kritieke Drupal core-kwetsbaarheid werd gepubliceerd (SA-CORE-2022-015), konden we die binnen korte tijd over alle omgevingen uitrollen, zonder improvisatie en met minimale downtime.
Hetzelfde geldt voor back-ups. Een back-up die nooit wordt teruggezet, biedt schijnzekerheid. Daarom testen we restores periodiek, volgens een vast patroon. Zo weten we niet alleen dát er een back-up is, maar ook dat die werkt wanneer het nodig is.
Beveiliging werkt alleen als systeem
Bij één site kun je beveiliging grotendeels oplossen met modules en beleid. Bij veel sites leer je dat beveiliging geen optelsom is, maar een keten. En die keten breekt op de zwakste plek.
In de praktijk blijkt dat zelden de belangrijkste productieomgeving te zijn. Het zijn juist vergeten testomgevingen, oude subdomeinen of een contrib-module die ooit is blijven liggen. Daarom monitoren we alle omgevingen actief: productie, test en acceptatie. Inlogpogingen, afwijkend gedrag en verouderde componenten krijgen overal dezelfde aandacht.
We houden een actueel overzicht bij van gebruikte contrib-modules per klant. Wanneer er een beveiligingsadvies verschijnt via het Drupal Security Advisory-systeem, zien we direct waar actie nodig is. Dat stelde ons bijvoorbeeld in staat om tijdens de SQL-injectieproblemen in bepaalde contrib-modules in 2021 snel en gericht te patchen.
Veel beveiligingsrisico’s zitten bovendien niet in code, maar in configuratie. Bestandsrechten die ooit tijdelijk waren, gebruikersrollen die ongemerkt zijn uitgebreid, ontbrekende headers zoals CSP of HSTS. Door deze instellingen over tientallen sites te vergelijken, worden structurele fouten zichtbaar. En dus ook structurele verbeteringen.
Performance en schaal laten zich niet voorspellen, wel herkennen
Wat bij de ene site probleemloos werkt, kan bij een andere site tot serieuze vertraging leiden. We zien dat dagelijks terug, mede door de variatie in hostingomgevingen: van gedeelde hosting tot cloud-clusters.
Door die variatie ontstaat herkenning. Trage sites blijken vaak dezelfde oorzaken te hebben: niet-geïndexeerde databasequeries, zware Views die ooit logisch waren, externe koppelingen die time-outs veroorzaken. Wie deze problemen vaak genoeg tegenkomt, herkent ze voordat ze escaleren.
Die ervaring beïnvloedt ook hoe we naar architectuur kijken. Modulekeuzes, contentstructuren en integraties beoordelen we niet alleen op functionaliteit, maar op gedrag bij groei. Een structuur die bij honderden nodes werkt, kan bij duizenden vastlopen. Dat soort effecten zie je pas wanneer je ze meerdere keren hebt meegemaakt.
Onderhoud onthult technical debt
Veel Drupal-omgevingen dragen hun geschiedenis zichtbaar mee. Wij beheren sites die zijn gestart in Drupal 7, zijn doorontwikkeld in 8 of 9 en nu op 10 of 11 draaien. Dat maakt technical debt tastbaar.
Sites met veel maatwerk dat core-functionaliteit nabootst, verouderde contrib-modules zonder migratiepad of complexe configuraties kosten structureel meer tijd. Niet alleen bij dagelijks beheer, maar vooral bij upgrades. Die extra kosten en risico’s zijn geen verrassing, ze laten zich lezen in de codebasis.
De migratie van Drupal 7 naar 10 is daarvan een actueel voorbeeld. Voor eenvoudige sites is dat een relatief gestroomlijnd traject. Voor complexe omgevingen is het vaak een herimplementatie. Onze ervaring helpt om dat onderscheid vooraf te maken, inclusief realistische inschattingen van tijd, kosten en risico’s. We weten welke contrib-modules problemen geven, en waar maatwerk opnieuw moet worden ontworpen.
Documentatie speelt daarin een sleutelrol. Bij één site kun je veel onthouden. Bij tientallen niet. Bruikbare documentatie is daarom geen verslag, maar een overzicht: afwijkende configuraties, afhankelijkheden, bewuste keuzes. Zonder dat verdwijnt overzicht sneller dan gedacht.
Communicatie wordt concreter bij schaal
Naast techniek leert schaal ook iets anders. Communicatie wordt scherper wanneer je kunt vergelijken. Klanten willen geen technische details, maar duidelijkheid: is dit normaal, of een risico? Moet hier iets gebeuren, of kan het wachten?
Omdat wij meerdere omgevingen zien, kunnen we dat plaatsen. We rapporteren daarom niet in jargon, maar in begrijpelijke indicatoren, vaak via een beheer-dashboard. Dat maakt gesprekken concreet.
Hetzelfde geldt voor advies. Wanneer we zien dat een gebruikte module binnenkort niet meer wordt ondersteund, kunnen we dat vroeg signaleren en samen een plan maken. Dat soort advisering is alleen mogelijk wanneer je patronen herkent over meerdere sites heen.
Ook SLA’s worden daardoor realistischer. We weten uit ervaring wat haalbaar is, en wat niet. Dat maakt afspraken betrouwbaarder, voor beide kanten.
Beheer is een vak dat je leert door schaal
Het beheren van tientallen Drupal-omgevingen maakt één ding duidelijk: websitebeheer is geen bijzaak. Het is een vak. Het bestaat uit processen, monitoring, documentatie en communicatie die op elkaar aansluiten.
Organisaties die hun website serieus nemen, als informatiekanaal, dienstverlenend platform of verkoopomgeving, hebben baat bij die ervaring. Niet omdat ‘Drupal ingewikkeld is’, maar omdat patronen pas zichtbaar worden wanneer je ze vaak genoeg ziet terugkomen.
Die kennis ontstaat niet in theorie, maar in dagelijks werk. En juist die opgebouwde praktijkervaring bepaalt of een Drupal-omgeving vandaag stabiel is, en morgen beheersbaar blijft.