A client's site would slow to a crawl every time they ran a promotion, and their shared host's answer was always to upsell a bigger shared plan. We finally moved that site to a small DigitalOcean droplet instead, mostly out of frustration rather than a carefully weighed technical decision, though in hindsight it turned out to be exactly the right call for reasons beyond just the immediate performance problem.
Why shared hosting stopped working for this client
The client runs periodic promotions, a discount code emailed to a mailing list, and every single time, traffic would spike hard enough that the site became unusable for the exact window when it mattered most to them. Shared hosting means sharing physical resources, CPU, memory, disk I/O, with an unknown number of other accounts on the same box, and there's no way to know in advance whether one of those neighboring accounts is also having a busy day at the same time as you. The host's support team, to their credit, was honest about this when pressed, their answer wasn't a fix, it was an upsell to a bigger shared plan that would, at best, delay the same problem to a higher traffic threshold.
What surprised us
- We're responsible for everything now, security updates, the web server config, the firewall, nothing is done for us anymore. That's a genuine shift in responsibility that took some adjustment.
- It's genuinely cheaper than the shared hosting upgrade we were being pushed toward, which was a pleasant surprise given how much more control comes with it.
- Traffic spikes stopped being scary because we can see exactly what resources are being used, instead of guessing why a shared box feels slow, which used to be a genuinely opaque problem with no visibility into what was actually happening underneath us.
What we had to learn fast
Basic Ubuntu server administration, setting up Nginx from a config file instead of clicking through a cPanel, and just generally being comfortable at a terminal prompt. It's more work up front but it's work we now control instead of being at the mercy of a shared host's noisy-neighbor problem.
Setting up the actual server
The initial setup took longer than we expected, mostly because every step that a shared host handles invisibly, we now had to understand and do ourselves. Provisioning the droplet itself took minutes, choosing an image, a size, a datacenter region close to most of the client's actual visitors. What took the rest of the afternoon was everything after that: installing and configuring Nginx, setting up PHP-FPM, installing and securing MySQL, and getting a firewall in place before we felt comfortable pointing the domain at the new server.
We leaned heavily on DigitalOcean's own community tutorials for most of this, which turned out to be a genuinely good resource, clear, specific, and written for exactly the kind of person moving off shared hosting for the first time rather than assuming deep sysadmin background already.
The cost comparison, honestly
The shared host's proposed upgrade would have run noticeably more per month than the droplet size we ended up needing, which was a surprise going in, we'd assumed more control would cost more, not less. Part of that gap is because shared hosting margins are built around overselling capacity across many accounts, while a droplet's price reflects dedicated, predictable resources at a smaller scale. It's not a universal rule, a much bigger site would likely need a bigger, pricier droplet or several of them, but for a client this size the math worked out clearly in favor of the move.
What we'd tell someone considering the same move
Budget more time than you think for the initial setup, and don't do it for the first time under deadline pressure, ideally with a launch date already announced to the client. We did this migration with a comfortable buffer before the client's next promotion, which meant we had room to research an unfamiliar step rather than rushing past it under pressure. A migration done in a panic, the week before a client needs it working perfectly, is a much worse experience than the same migration done with breathing room.
We're also glad we kept the old shared hosting account active, untouched, for a couple of weeks after the DNS switch, just in case something on the new server surfaced a problem we hadn't anticipated and we needed to point things back quickly. Nothing went wrong badly enough to need it, but having that fallback in place made the whole migration feel much less risky while it was happening.
Monitoring what we couldn't see before
One unexpected benefit of moving to a droplet with full root access is visibility. We installed a simple monitoring tool that graphs CPU, memory and disk I/O over time, something that simply wasn't available to us as a shared hosting customer beyond whatever basic usage meter the host's control panel happened to expose. Watching those graphs during the client's next promotion, and seeing exactly which resource, CPU as it turned out, spiked hardest during the traffic surge, gave us concrete information to plan around instead of vague impressions of "the site feels slow."
That visibility changed how we think about the next capacity conversation with this client too. Instead of guessing when they might outgrow their current droplet size, we now have actual usage data to point to, which makes future upgrade conversations a lot more grounded than the previous host's generic upsell pitch ever was.
Backups, again, our own responsibility
Nothing about our new server setup handled backups automatically the way we'd naively assumed a proper host might. We had to explicitly set up the same kind of nightly database dump and file backup routine we'd already started using on other projects, which underscored a theme running through basically our entire year: the more control we take on, the more responsibility comes bundled with it, in ways that aren't always obvious until you go looking for the thing you assumed was handled and find nothing there.
Where this leaves shared hosting for us going forward
We're not writing off shared hosting entirely, for a small, low-traffic brochure site with no promotional spikes and a client who's cost-sensitive above all else, it's still a reasonable, low-effort choice, and not every client needs or wants the added responsibility that comes with a droplet. But for anything with real traffic variability, or a client who cares enough about uptime and performance to notice when either one slips, we're now defaulting to recommending a small cloud VPS from the start of a project rather than only reaching for one after a shared hosting plan has already failed a client once.