A Tuesday morning email lands in our inbox. Someone forwards a hosting renewal invoice from a company they have not thought about since 2018. The site still loads. The contact form still emails the owner. Nobody knows the FTP password. They want to know whether to renew, migrate, or quietly let the domain expire.
That email arrives almost every week. The site is always on shared cPanel. And the right answer is never the same, because the client behind the cPanel is never the same. After more than a decade of cleaning these up, we see four versions of the same person.
The "it just works" lifer
Five-page brochure site. WordPress 4.something, or more often, hand-built HTML by someone's nephew in 2012. PHP 7.2, because the host stopped sending upgrade nags after the third one bounced. Eighty visits a day, mostly people who already know the brand. Two leads a week, all by phone. Annual hosting bill: roughly €120.
This client does not need a redesign. They do not need a CMS. They certainly do not need a "growth audit". What they need is for the site to keep doing what it does for the next ten years without sitting on PHP 7.2.
The migration is boring and quick. Pull the static files, freeze the PHP version locally if there is any dynamic code, drop it behind Cloudflare, and put the backups on a schedule. PHP itself only supports the last three minor releases for security fixes, so the only real risk on shared hosting is the silent moment where the host upgrades PHP under them and a contact form stops sending. That risk is solved with a flat HTML deploy and a synthetic check that runs against the form once a day.
The accidental WooCommerce
Started as a blog in 2015. Somebody installed WooCommerce in 2018 to sell one product. Now there are 240 SKUs, thirty orders a day, and a checkout that takes nine seconds because the shared box has one shared CPU and the cache plugin and the security plugin are fighting each other.
This client thinks they need a faster host. They almost always say "we just need to move to a VPS". A VPS will buy them six months, then they will be in exactly the same place, paying €40 a month instead of €8.
What they actually need is a stack change. Either the catalogue is small enough that Shopify swallows it whole and the blog moves to a static generator, or the catalogue is too custom for Shopify and the answer is a thin storefront on Next.js with the product data in Postgres and the checkout on Stripe. The blog content survives. The Woo database does not. Nobody misses it.
Do not let a "we just need a faster host" client buy a VPS without first measuring where the nine seconds go. Nine times out of ten the bottleneck is not the host. It is forty plugins fighting for the same render pass.
The orphan
Built in 2016 by a Rotterdam agency that does not exist anymore. WordPress 5.2. Twelve plugins. Three of those have not had a release in four years. One of them, if you check the CVE record, has an unpatched authenticated RCE.
Nobody at the client has the FTP password. The agency's old project manager is now in HR at a bank. The cPanel login is in a 1Password vault belonging to someone who left two jobs ago. Half the time the original developer's email is still the technical contact on the domain registrar, which means renewal notices go to a dead mailbox.
You cannot migrate this client until you do the boring archaeology first. Recover cPanel access through the registrar (sometimes via a notarised letter, sometimes via a phone call to the host's billing department), pull a full database dump and a tarball of public_html, then run the site locally with the network unplugged so the abandoned plugins cannot phone home. From there, the rebuild is a question of how much of the existing content is worth keeping. Usually: the writing yes, the structure no.
The compliance-anxious
Law firm, accountant, or small medical clinic. The site is fine, in the sense that it works. They got an email from their cyber insurer or their largest client's procurement team asking for TLS 1.3, an SBOM, quarterly vulnerability scans, two-person change control, and a 90-day log retention policy.
Shared cPanel can technically serve TLS 1.3. It cannot show an auditor that the production binary which served a page on April 12th has not been tampered with since. The host has root. The host's contractors have root. Nobody can prove who did what.
This client does not need a faster site or a prettier one. They need a stack where every change goes through a pull request, every deploy leaves a signed artifact, and the logs go to a place the developer cannot rewrite. A managed Vercel or Cloudflare Pages deploy from a private git repo, an off-host database with point-in-time recovery, and structured logs to a separate provider gets them most of the way. The hard part is not the technology. It is convincing them that this is cheaper than the cPanel renewal once the insurance discount kicks in.
What the four have in common
None of these clients are technically wrong about their current setup. cPanel is not a moral failing. For the lifer it is actually right-sized. The problem is that all four arrive at our inbox with the same question ("should I migrate?") and the same default assumption ("probably to another shared host, just newer"). The answer is the same in form and different in substance every time: figure out which of the four you are, and the migration writes itself.
The temptation, especially for an agency on the receiving end of that email, is to upsell. Don't. The lifer gets a flat HTML deploy and a yearly check-in. The Woo client gets a stack change and an honest conversation about whether their margins survive a real platform. The orphan gets a clean rebuild on writing they already own. The compliance client gets an auditable pipeline.
When we migrated a Rotterdam logistics broker off a 2014 cPanel install last spring, the thing we ran into was the orphan problem stacked with the compliance one: no FTP credentials, and an insurer demanding 90-day log retention by the end of Q3. We solved it by reconstructing the site from the live HTML, pushing the rebuild through a git pipeline, and routing the access logs to a third-party sink the host could not touch. Most legacy site rescues end up looking like one of these four shapes. The work is the same. The story you tell the client is what changes.
If you only have five minutes today, open the hosting account, find the PHP version, and check it against the PHP support matrix. If it is older than the current stable minus two, you are already on borrowed time. That one number tells you which of the four conversations you are about to have.
