Deel 1: wanneer is een andere partner verstandig?
Het onderhoud van een Drupal-website overdragen aan een andere partij is geen beslissing die je iedere dag neemt. Toch komt het regelmatig voor. Omdat de samenwerking niet meer goed past, omdat kennis verdwijnt of omdat de website inmiddels andere aandacht nodig heeft. In deze driedelige serie bekijken we wanneer overstappen verstandig is, wat een goede overdracht vraagt en hoe de eerste maanden daarna verlopen.
De partij die een Drupal-website bouwt, blijft daarna vaak ook het onderhoud uitvoeren. Dat is logisch: de ontwikkelaars kennen de website, weten welke keuzes tijdens de bouw zijn gemaakt en kunnen meestal snel beoordelen waar een aanpassing of probleem vandaan komt.
Na verloop van tijd kan de behoefte van de organisatie echter veranderen. De nadruk ligt dan minder op het verder ontwikkelen van de website en meer op de vraag hoe deze technisch gezond, veilig en betrouwbaar blijft. Dat lijkt misschien een kleine verschuiving, maar in de praktijk vraagt structureel onderhoud om een andere aanpak dan het uitvoeren van incidentele updates of wijzigingen.
Dat betekent niet dat het oorspronkelijke bureau zijn werk niet goed doet. Het betekent alleen dat het bouwen van een website en het langdurig onderhouden ervan verschillende werkzaamheden zijn.
Van ontwikkelproject naar bestaande website
Tijdens de bouw van een website is het werk meestal projectmatig georganiseerd. Er zijn wensen, ontwerpen, planningen en oplevermomenten. Functionaliteiten worden toegevoegd en problemen worden opgelost met het oog op de geplande livegang.
Na die livegang verandert het karakter van het werk. De website hoeft niet meer voortdurend opnieuw te worden ontworpen of uitgebreid, maar moet wel blijven functioneren binnen een technische omgeving die continu verandert.
Drupal krijgt nieuwe versies, modules worden bijgewerkt en PHP-versies raken uit ondersteuning. Hostingpartijen passen hun infrastructuur aan en externe diensten wijzigen hun koppelingen of voorwaarden. Ook binnen de organisatie verandert er van alles. Medewerkers vertrekken, processen worden aangepast en nieuwe wensen ontstaan meestal niet meer in grote projecten, maar in een gestage stroom van kleinere wijzigingen.
Het onderhoud van een bestaande website bestaat daardoor niet alleen uit het installeren van updates. Het gaat ook om het volgen van ontwikkelingen, het beoordelen van risico’s en het maken van keuzes over wat direct moet gebeuren en wat kan wachten.
Af en toe bijwerken is nog geen onderhoudsproces
Veel Drupal-websites worden in de praktijk onderhouden wanneer daar een concrete aanleiding voor is. Er is een beveiligingsupdate beschikbaar, een onderdeel werkt niet meer goed of iemand wil een wijziging laten uitvoeren. De ontwikkelaar bekijkt de situatie, voert het werk uit en daarna kan de website weer verder.
Voor veel websites kan dat lange tijd prima werken.
Toch is deze werkwijze iets anders dan dedicated onderhoud. Bij dedicated onderhoud ontstaat er een vast proces waarin de website regelmatig wordt gecontroleerd, updates worden beoordeeld en technische ontwikkelingen vooruit worden gevolgd.
Daarbij gaat het niet alleen om de vraag welke update vandaag beschikbaar is. Minstens zo belangrijk is wat er over drie of zes maanden aankomt. Welke softwareversie loopt uit ondersteuning? Welke module wordt nauwelijks nog onderhouden? Is een externe koppeling veranderd? Zijn er onderdelen van de website die bij een volgende upgrade extra aandacht nodig hebben?
Door dat soort vragen op tijd te stellen, blijft het onderhoud beter planbaar en wordt voorkomen dat grotere technische werkzaamheden onverwacht urgent worden.
Problemen zien voordat ze zichtbaar worden
Een gespecialiseerd onderhoudsbureau is er niet alleen om problemen op te lossen nadat iemand ze heeft gemeld. Een belangrijk deel van het werk bestaat juist uit het signaleren van afwijkingen voordat bezoekers of medewerkers daar last van krijgen.
Veel technische problemen ontstaan namelijk geleidelijk. Een koppeling geeft steeds vaker een foutmelding, maar werkt voorlopig nog. Een cronjob wordt niet meer volledig uitgevoerd. Back-ups worden wel gestart, maar blijken niet goed te worden afgerond. De beschikbare schijfruimte loopt langzaam terug of de responstijd van een externe dienst wordt steeds langer.
Aan de voorkant van de website hoeft daar nog niets van te merken te zijn.
Door logbestanden, monitoring en technische controles serieus te nemen, kunnen zulke signalen eerder worden gezien. Dat betekent niet dat iedere storing kan worden voorspeld. Dat kan niemand. Wel wordt de kans groter dat een probleem wordt aangepakt voordat het uitgroeit tot een storing die gebruikers daadwerkelijk merken.
Dat is een wezenlijk verschil tussen reactief beheer en structureel onderhoud.
| Developmentbureau | Onderhoudsbureau |
|---|---|
| Gericht op het bouwen en uitbreiden van websites | Gericht op het gezond en betrouwbaar houden van bestaande websites |
| Werkt meestal projectmatig | Werkt doorlopend |
| Levert nieuwe functionaliteit op | Bewaakt continuïteit en technische staat |
| Start vanuit wensen en specificaties | Start vanuit risico’s, gebruik en onderhoudsbehoefte |
| Plant werk in grotere ontwikkelblokken | Verwerkt ook kleine vragen en wijzigingen |
| Komt vooral in actie bij een opdracht of melding | Controleert de website ook zonder concrete melding |
| Lost zichtbare problemen op | Probeert problemen te signaleren voordat gebruikers ze merken |
| Voert updates uit als onderdeel van een opdracht | Beoordeelt, plant, test en controleert updates structureel |
| Richt zich vooral op Drupal-code en functionaliteit | Kijkt ook naar hosting, back-ups, monitoring, e-mail en koppelingen |
| Test vooral wat binnen het project is gewijzigd | Bewaakt vaste, bedrijfskritische functies van de website |
| Werkt naar een oplevermoment toe | Werkt zonder definitief eindpunt |
| Denkt vooral vanuit ontwikkeling en verbetering | Denkt vooral vanuit stabiliteit, voorspelbaarheid en preventie |
| Heeft meestal ruimte voor grotere veranderingen | Is ingericht op een gestage stroom kleine werkzaamheden |
| Bouwt kennis op tijdens een project | Houdt kennis en documentatie over langere tijd actueel |
| De centrale vraag is: wat moeten we bouwen? | De centrale vraag is: wat is nodig om deze website goed te laten blijven werken? |
| Rapporteert vooral over voortgang, uren en oplevering binnen een project | Rapporteert periodiek en in een vast format over uitgevoerde werkzaamheden, technische aandachtspunten en geplande vervolgstappen |
Een update is pas klaar als de website nog werkt
Bij websiteonderhoud wordt vaak als eerste aan updates gedacht. Dat is begrijpelijk, want Drupal-core, modules en andere software moeten worden bijgehouden.
Toch zegt een geslaagde update op zichzelf niet genoeg.
Een update kan technisch correct zijn uitgevoerd, terwijl ergens anders een probleem ontstaat. Een formulier verstuurt geen e-mail meer, een importproces slaat een stap over of een koppeling verwerkt bepaalde gegevens niet meer op dezelfde manier. Zulke problemen zijn niet altijd direct zichtbaar tijdens het uitvoeren van de update.
Daarom hoort bij onderhoud ook kennis van de website zelf. Welke onderdelen zijn belangrijk? Welke formulieren worden veel gebruikt? Welke koppelingen zijn bedrijfskritisch? Welke processen moeten na een wijziging worden gecontroleerd?
Niet iedere pagina hoeft na iedere kleine update volledig handmatig te worden getest. Maar de belangrijkste functies moeten bekend zijn en op een passende manier worden gecontroleerd.
Dedicated onderhoud betekent daardoor niet simpelweg vaker updates uitvoeren. Het betekent dat updates onderdeel zijn van een breder proces waarin ook testen, controle en herstel zijn geregeld.
Kleine werkzaamheden worden belangrijker
Naarmate een website langer bestaat, verschuift het werk meestal van grote projecten naar kleinere aanpassingen.
Een formulier moet worden gewijzigd, een redacteur loopt tegen een beperking aan of een koppeling moet worden aangepast aan een nieuwe werkwijze. Soms gaat het maar om enkele uren werk, maar voor de organisatie kan zo’n wijziging wel degelijk belangrijk zijn.
Een ontwikkelbureau dat vooral is ingericht op grotere projecten kan dit soort werkzaamheden uiteraard uitvoeren. De planning en organisatie van het bureau zijn er alleen niet altijd op ingericht.
Een onderhoudsbureau werkt juist met een doorlopende stroom van controles, vragen en kleine technische wijzigingen. Daardoor kunnen dit soort werkzaamheden vaak eenvoudiger binnen de bestaande samenwerking worden opgepakt, zonder dat voor ieder verzoek een apart project hoeft te worden gestart.
Ook dat kan een reden zijn om onderhoud en ontwikkeling anders te organiseren.
De website is meer dan Drupal alleen
Een Drupal-website bestaat niet uitsluitend uit Drupal.
Er is een hostingomgeving, een database, versiebeheer, e-mailafhandeling en een back-upvoorziening. Vaak zijn er daarnaast koppelingen met andere systemen, zoals een CRM, zoekdienst, betaalprovider of interne applicatie.
Problemen houden zich niet netjes aan de grenzen tussen deze onderdelen. Een fout die zichtbaar wordt in Drupal kan zijn oorsprong hebben in de hostingomgeving. Problemen met e-mail kunnen worden veroorzaakt door DNS-instellingen of een gewijzigde configuratie bij de verzenddienst. Een trage pagina kan afhankelijk zijn van een externe koppeling.
Structureel onderhoud kijkt daarom naar de technische keten als geheel. De vraag is niet alleen of Drupal bijgewerkt is, maar of de omgeving waarin de website functioneert als geheel gezond en beheersbaar blijft.
Een andere partij hoeft geen vervanging te zijn
Het onderhoud overdragen betekent niet automatisch dat het oorspronkelijke bureau volledig uit beeld moet verdwijnen.
Het is goed mogelijk om ontwikkeling en onderhoud bij verschillende partijen onder te brengen. Het oorspronkelijke bureau kan bijvoorbeeld betrokken blijven bij grotere uitbreidingen, terwijl een gespecialiseerd onderhoudsbureau verantwoordelijk wordt voor updates, monitoring en dagelijkse technische ondersteuning.
Daarvoor moeten de verantwoordelijkheden wel duidelijk worden afgesproken. Wie beoordeelt updates? Wie volgt storingen op? Wie beheert de hosting en wie neemt het voortouw wanneer een grotere technische wijziging nodig is?
Als die verdeling helder is, kunnen verschillende partijen prima naast elkaar werken.
De behoefte is veranderd
De belangrijkste reden om het onderhoud van een Drupal-website over te dragen, is daarom niet per se ontevredenheid over de huidige leverancier.
Vaak is de website simpelweg in een andere fase terechtgekomen. De behoefte aan grote ontwikkelprojecten neemt af, terwijl de behoefte aan monitoring, voorspelbaarheid, kleine wijzigingen en preventief onderhoud juist toeneemt.
De relevante vraag is dan niet of de huidige partij haar werk goed doet, maar of de manier van werken nog past bij wat de website inmiddels nodig heeft.
Wanneer onderhoud meer moet zijn dan af en toe een update uitvoeren of reageren op een melding, kan het verstandig zijn om te kiezen voor een partij die zich juist op dat werk heeft gespecialiseerd.
In deel 2 bekijken we wat er nodig is om het onderhoud van een Drupal-website zorgvuldig over te dragen. Want een goede overdracht begint niet bij het doorsturen van een paar wachtwoorden, maar bij het compleet krijgen van de technische en organisatorische situatie.
- Deel 2: Wat is nodig voor een verantwoorde overdracht?
- Binnenkort op deze plaats – Deel 3: De eerste 90 dagen na de overname