A couple of long-standing client sites were still sitting on shared hosting plans years after we moved the rest of our work to proper cloud infrastructure — mostly small brochure sites where the client did not want to pay for a migration that "nothing was wrong" would not obviously justify. It is a familiar pattern: the sites that are easiest to leave alone are exactly the ones nobody gets around to fixing.
How these clients ended up staying on shared hosting for so long
None of these were new clients. Each had been with us for years, on hosting plans that predated our own move to cloud infrastructure, and each time the subject came up the conversation stalled on the same objection: the site works fine today, so why pay to change something that is not visibly broken. That is a reasonable thing for a client to think when nothing has gone wrong yet, and it is a hard case to make preemptively without sounding like we are manufacturing a problem to bill for.
What finally forced the issue
This year a shared host's outage took one of those sites down for most of a day, with no meaningful support response beyond a generic status page acknowledging "some customers may be affected," and that was the push to finally migrate the last few. The client in question runs a small local business, and a full day of their site being unreachable during a period when a local news mention had driven an unusual amount of traffic their way was a genuinely costly coincidence — the kind of bad luck that turns an abstract argument about infrastructure quality into a concrete, felt cost.
Where everything runs now
All of our managed client sites now run on DigitalOcean or AWS, provisioned and configured the same way, with the same monitoring and backup setup regardless of how small the site is. We standardized on a small set of droplet or instance sizes rather than sizing each server bespoke to its site's traffic, since the operational simplicity of a handful of known configurations has been worth more to us than squeezing out marginal cost savings by fine-tuning every single server's specification individually.
What the migrations actually involved
- DNS cutover planned during each site's lowest-traffic window, with TTLs lowered a day in advance to keep the propagation delay short
- A full database and file export from the shared host, restored and verified on the new server before any DNS change, so we were never migrating blind
- SSL certificates reissued and automated to renew going forward, replacing whatever manual or host-managed certificate process the shared host had been quietly handling before
- A monitoring and backup setup applied identically to what every other client site already had, so these sites stopped being the exception to our own standard
The harder part was the client conversation, not the technical work
The migrations themselves were straightforward technically — these were simple WordPress brochure sites with no complex dependencies — but required careful client communication, since a couple of these clients had genuinely never thought about their hosting as something with quality tiers before, and needed a clear, non-technical explanation of why an outage that "wasn't our fault" was still something worth paying to prevent going forward. Framing it around control and accountability rather than technical superiority landed well: on our own infrastructure, we can actually diagnose and fix a problem ourselves rather than waiting on a shared host's generic support queue with no visibility into what is actually happening.
What we would tell a client asking the same question today
We now bring this up proactively with any new client still on inherited shared hosting, rather than waiting for an outage to make the case for us. The pitch is simple: shared hosting is not inherently bad, but it means accepting someone else's noisy-neighbor problems, someone else's support queue, and someone else's decision about when and how to patch the server your site depends on. For a client whose business genuinely does not depend on that site's uptime, that tradeoff might be fine. For most of our clients, it quietly is not, even when nothing has gone wrong yet to prove it.
Results
It is a relief to no longer have a mental asterisk next to a handful of clients whose hosting we did not fully control, and it simplifies our own operational story considerably — every client site we manage now gets the same monitoring dashboard, the same backup verification schedule, and the same incident response process, rather than a small subset living by different, weaker rules purely because of legacy hosting decisions made years before we had a consistent standard to apply. The next time a hosting-level outage happens anywhere in our client base, and eventually one will, we will at least be the ones fixing it rather than the ones waiting on someone else's status page.
The cost comparison, worked through honestly
The shared hosting plans these clients were on cost a fraction of what a properly provisioned cloud server costs, and we did not pretend otherwise during these conversations. What we walked each client through instead was the fuller cost picture: our own support time spent working around shared hosting's limitations, the actual dollar cost of the outage that prompted this whole migration, and the fact that a shared host's cheap monthly price does not include anything resembling the monitoring, backup verification, or incident response we already provide to every other client site. Framed that way, the price difference looked much smaller than the sticker price alone suggested, and in at least one case, once lost-business cost from the outage was factored in, cloud hosting turned out to be the cheaper option even before accounting for the ongoing operational benefit.
Backup verification, specifically
A detail we made sure every migrated client understood clearly: a backup that has never been restored and verified is not actually a backup, it is an unverified hope. Our standard process now includes a monthly automated restore of every client site's backup into an isolated environment, checked against a basic smoke test, specifically because we have seen other agencies discover a months-old, silently-broken backup process only at the exact moment they needed it. None of the shared hosts these clients had been on offered anything like this as a standard feature, which was a genuine gap in coverage that had simply gone unnoticed because nothing had gone wrong yet to expose it.
A migration checklist we now reuse
Going through several of these migrations back to back turned into a reusable internal checklist rather than something we reconstruct from memory each time:
- Full database and file export, restored and smoke-tested on the destination server before any DNS change is even scheduled
- SSL certificate reissued and automated to renew, rather than carried over or left to expire
- DNS TTL lowered a day ahead of the actual cutover, to keep the propagation window short and predictable
- Old shared hosting account left active, unbilled where possible, for a short overlap window in case a rollback is ever needed
- A final content diff between old and new after cutover, confirming nothing was missed in the export
What this means for how we onboard new clients now
Any new client who arrives already on shared hosting now gets this conversation up front, during initial scoping, rather than after something goes wrong. It is a small addition to an onboarding conversation, but it has already meant at least two new clients moved to proper cloud infrastructure before we ever built anything for them, rather than after an outage forced the issue the way it did for these long-standing clients.
One thing we got wrong the first time
On our very first of these migrations, several years earlier, we underestimated how long DNS propagation could realistically take for a domain with an unusually long previous TTL that the client's original registrar had set, and the site was intermittently unreachable for part of a day during what should have been a clean cutover. That mistake is exactly why lowering TTL a full day ahead of any cutover is now the first line of our migration checklist rather than an afterthought, and every migration since has gone cleanly because of it.