Een dinsdagochtend, een mail valt onze inbox binnen. Iemand stuurt een hostingfactuur door van een bedrijf waar ze sinds 2018 niet meer aan hebben gedacht. De site laadt nog. Het contactformulier mailt nog naar de eigenaar. Niemand kent het FTP-wachtwoord. Ze willen weten of ze moeten verlengen, migreren, of het domein stilletjes laten verlopen.
Die mail komt bijna elke week binnen. De site staat altijd op shared cPanel. En het juiste antwoord is nooit hetzelfde, want de klant achter het cPanel is nooit dezelfde. Na meer dan tien jaar dit soort opruimwerk zien we vier varianten van dezelfde persoon.
De 'het werkt gewoon' blijver
Een brochuresite van vijf pagina's. WordPress 4.iets, of vaker, met de hand gebouwde HTML door iemands neef in 2012. PHP 7.2, omdat de host na de derde bounce stopte met upgrade-herinneringen. Tachtig bezoekers per dag, voornamelijk mensen die het merk al kennen. Twee leads per week, allemaal telefonisch. Hostingrekening per jaar: ongeveer €120.
Deze klant heeft geen redesign nodig. Geen CMS. En al helemaal geen 'groei-audit'. Wat ze nodig hebben is dat de site de komende tien jaar blijft doen wat hij doet, zonder op PHP 7.2 te zitten.
De migratie is saai en snel. Trek de statische bestanden eruit, zet de PHP-versie lokaal vast als er dynamische code is, parkeer het achter Cloudflare en plan back-ups in. PHP zelf ondersteunt alleen de laatste drie minor releases voor security fixes, dus het enige echte risico op shared hosting is het stille moment waarop de host PHP onder je upgradet en een contactformulier opeens niets meer verstuurt. Dat risico los je op met een platte HTML-deploy en een synthetic check die elke dag het formulier aanroept.
De per ongeluk WooCommerce
Begon als blog in 2015. Iemand installeerde in 2018 WooCommerce om één product te verkopen. Nu zijn er 240 SKU's, dertig orders per dag, en een checkout die negen seconden duurt omdat de shared box één gedeelde CPU heeft en de cache-plugin en de security-plugin elkaar in de weg zitten.
Deze klant denkt dat hij een snellere host nodig heeft. Bijna altijd zeggen ze 'we moeten gewoon naar een VPS'. Een VPS koopt ze zes maanden tijd, daarna zitten ze op precies hetzelfde punt, alleen betalen ze €40 per maand in plaats van €8.
Wat ze echt nodig hebben is een stack-wissel. Of de catalogus is klein genoeg dat Shopify hem in zijn geheel slikt en de blog verhuist naar een statische generator, of de catalogus is te custom voor Shopify en het antwoord is een dunne storefront op Next.js met de productdata in Postgres en de checkout op Stripe. De blogcontent overleeft. De Woo-database niet. Niemand mist hem.
Laat een klant die zegt 'we hebben gewoon een snellere host nodig' geen VPS kopen voordat je hebt gemeten waar die negen seconden heen gaan. Negen van de tien keer ligt het knelpunt niet bij de host. Het zijn veertig plugins die om dezelfde render-pass vechten.
De wees
Gebouwd in 2016 door een Rotterdams bureau dat niet meer bestaat. WordPress 5.2. Twaalf plugins. Drie daarvan hebben in vier jaar geen release gehad. Eentje heeft, als je het CVE-record erbij pakt, een ongepatchte authenticated RCE.
Niemand bij de klant heeft het FTP-wachtwoord. De oude projectmanager van het bureau zit nu bij HR van een bank. De cPanel-login zit in een 1Password-vault van iemand die twee banen geleden is vertrokken. De helft van de tijd staat het e-mailadres van de oorspronkelijke developer nog als technisch contact bij de domeinregistrar, wat betekent dat verlengingsmails naar een dode mailbox gaan.
Je kunt deze klant niet migreren voordat je het saaie archeologie-werk hebt gedaan. cPanel-toegang terughalen via de registrar (soms via een gewaarmerkte brief, soms via een telefoontje naar de billing-afdeling van de host), een volledige database-dump en een tarball van public_html eruit trekken, en de site dan lokaal draaien met de netwerkkabel eruit, zodat de verlaten plugins niet naar huis kunnen bellen. Vanaf daar is de rebuild een kwestie van hoeveel van de bestaande content nog waard is om mee te nemen. Meestal: het schrijfwerk wel, de structuur niet.
De compliance-angstige
Advocatenkantoor, accountant, of kleine huisartsenpraktijk. De site is prima, in de zin dat hij werkt. Ze kregen een mail van hun cyberverzekeraar of het inkoopteam van hun grootste klant, met de vraag om TLS 1.3, een SBOM, kwartaalmatige vulnerability scans, vier-ogen change-control en een logbewaartermijn van 90 dagen.
Shared cPanel kan technisch TLS 1.3 serveren. Het kan een auditor niet laten zien dat de productie-binary die op 12 april een pagina serveerde sindsdien niet is aangepast. De host heeft root. De contractors van de host hebben root. Niemand kan bewijzen wie wat heeft gedaan.
Deze klant heeft geen snellere of mooiere site nodig. Ze hebben een stack nodig waar elke wijziging via een pull request gaat, elke deploy een getekend artifact achterlaat, en de logs naar een plek gaan die de developer niet kan herschrijven. Een managed Vercel of Cloudflare Pages-deploy vanuit een private git-repo, een database buiten de host met point-in-time recovery, en structured logs naar een aparte provider brengt ze grotendeels waar ze moeten zijn. Het lastige is niet de techniek. Het lastige is ze ervan overtuigen dat dit goedkoper is dan de cPanel-verlenging zodra de verzekeringskorting ingaat.
Wat de vier gemeen hebben
Geen van deze klanten heeft technisch ongelijk over hun huidige setup. cPanel is geen morele tekortkoming. Voor de blijver is het zelfs precies de juiste maat. Het probleem is dat alle vier met dezelfde vraag in onze inbox belanden ('moet ik migreren?') en met dezelfde standaardaanname ('waarschijnlijk naar een andere shared host, gewoon nieuwer'). Het antwoord is qua vorm steeds hetzelfde en qua inhoud steeds anders: bepaal welke van de vier je bent, en de migratie schrijft zichzelf.
De verleiding, vooral voor een bureau dat zo'n mail binnenkrijgt, is om iets duurders te verkopen. Doe het niet. De blijver krijgt een platte HTML-deploy en een jaarlijkse check-in. De Woo-klant krijgt een stack-wissel en een eerlijk gesprek over de vraag of zijn marges een echt platform overleven. De wees krijgt een schone rebuild op tekst die hij al bezit. De compliance-klant krijgt een auditbare pipeline.
Toen we afgelopen voorjaar een Rotterdamse logistieke makelaar van een cPanel-installatie uit 2014 af haalden, liepen we tegen het wezen-probleem aan, gestapeld op het compliance-probleem: geen FTP-credentials, en een verzekeraar die voor het einde van Q3 een logbewaartermijn van 90 dagen eiste. We hebben het opgelost door de site te reconstrueren vanuit de live HTML, de rebuild door een git-pipeline te duwen en de access logs naar een externe sink te routeren die de host niet kon aanraken. De meeste legacy site rescues zien er uiteindelijk uit als een van deze vier vormen. Het werk is hetzelfde. Het verhaal dat je de klant vertelt is wat verschilt.
Als je vandaag maar vijf minuten hebt, open dan het hostingaccount, zoek de PHP-versie, en check die tegen de PHP-supportmatrix. Is hij ouder dan de huidige stabiele versie min twee, dan zit je al op geleende tijd. Dat ene getal vertelt je welke van de vier gesprekken je gaat hebben.
