This is part 8 of an 8-part series on migrating a fleet of roughly 40 WordPress sites from two shared-hosting providers (A2 Hosting and SiteGround) onto a self-managed Hestia Control Panel VPS with Cloudflare as the DNS layer. “Self-managed Hestia Control Panel VPS” does not imply exotic or special-purpose hardware: Hestia runs on any generic x86_64 Linux box. Our own instance is a Hetzner Cloud CPX32 (4 vCPU, 8GB RAM, roughly 160GB SSD disk, running Ubuntu 24.04), reachable over Hetzner’s standard shared datacenter network like any other cloud VPS, not a dedicated line or special connection.
This series is written for the sysadmin who is considering doing this themselves and wants to know exactly how hard it actually is before they start.
Part 8: What we’d tell you before you start
If you’re considering doing something similar, here is what is worth knowing going in.
This is genuinely difficult, not difficult-sounding. Every layer that a managed host used to handle silently is now something you configure, monitor, and occasionally get paged for at odd hours: DNS, TLS issuance and renewal, mail transport and deliverability reputation, backup verification, and the web server stack itself. None of these are individually exotic, but there are a lot of them, and they interact in ways that produce the kind of bugs in Part 6: a fix in one layer (an SSL cert reissue) silently breaking another (mail delivery) because they shared a config path you didn’t know about.
Ask yourself these questions before you start:
- How many domains, realistically, and how many of them are actually live and generating real traffic or real business email, versus defensive registrations that just need a redirect? Sort your fleet into these buckets before you touch anything; it changes what “done” means for each domain.
- Do you actually want to run your own mail server? This is, without question, the highest-effort part of a migration like this. If most of your domains already route mail through Google Workspace or a similar external provider, you can skip the hardest section of this entire project for those domains and only touch web hosting.
- What’s your backup and disaster-recovery story compared to what a managed host was already giving you for free? Set this up (and test restoring from it) before you migrate anything real onto the new box, not after.
- Do you have someone with real Linux, DNS, and mail-server operations experience who can run a periodic audit (we found real, silent bugs, misconfigured SSL flags, missing file ownership, invisible mail domains, on a quarterly audit cadence that a one-time migration checklist would have missed)? Budget for ongoing operational time, not just the migration itself.
- Are you comfortable debugging an nginx-fronting-Apache SNI proxy setup, PHP-FPM pool configuration, Dovecot’s config parser, and a firewall/fail2ban stack, when something goes wrong at 11pm? If the answer is “not yet,” that is a reason to build experience on a smaller, lower-stakes domain first before moving anything with live business email onto self-managed infrastructure.
- What’s your rollback plan for a specific domain if a cutover goes wrong mid-flight? We deliberately never coupled a web cutover and a mail cutover into a single irreversible step for exactly this reason: if the web side has a problem, mail keeps flowing at the old host while you fix it, and vice versa.
For scale and credibility: this project moved roughly 40 domains across two source hosts onto a single 4 vCPU / 8GB RAM Hetzner VPS running Hestia, over several weeks of real engineering time, not counting the ongoing quarterly audits that continue to catch drift. The single policy decision that saved us the most pain in retrospect was insisting on one dedicated system user per domain, no shared accounts, early in the project. An earlier attempt at a batch script that put 22 domains under one shared account produced a cascade of the subtlest, hardest-to-find bugs in this entire writeup (invisible accounts, decoy accounts still silently serving from the wrong place, ownership stragglers breaking uploads on a report-by-report basis for weeks afterward). Untangling that took more time than migrating those same 22 domains cleanly would have taken the first time.
The single most important takeaway: a clean exit code, an HTTP 200, and a config flag that says everything is fine are not evidence of anything. Verify the actual behavior, end to end, every time, and you’ll catch most of what’s in Part 6 before it becomes a support ticket from someone who trusted you with their email.