This is part 1 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.
This project took over two weeks of engineering – and we made lots of mistakes along the way. If you are evaluating whether to leave managed shared hosting for something you run yourself, you deserve the real list of things that broke, not a highlight reel.
Part 1: Why we moved, and what we moved to
The starting point
The fleet started life spread across two shared-hosting providers: A2 Hosting (cPanel/WHM, one cPanel account per domain, 23 accounts) and SiteGround (33 sites across three separate owners on the same account structure). A full domain inventory against the registrar (SRSPlus/TLDS L.L.C.) turned up 76 domains total: 25 already sitting on SiteGround, 46 still resolving through A2’s default DNS, and the rest scattered or parked.
Some of these were live client sites doing real business. Some were personal domains. A few were pure defensive registrations, brand variants nobody actually visits, kept alive only to stop someone else from squatting on them. That distinction mattered constantly during the migration, because it changes what “done” means for a given domain: a live client site needs zero-downtime mail and a real SSL cert; a defensive registration just needs a working 301 redirect.
Why leave managed hosting at all
The main drivers were control and cost at scale. With roughly 40 domains, a single shared-hosting bill scales per-site or per-tier in ways that add up fast, and you’re still constrained by whatever the panel exposes. Running our own box also means we can now host sites at a fraction of what a per-domain shared-hosting plan would cost. Root access on your own VPS means you can fix the thing that’s actually broken (a stray .htaccess rule, a PHP-FPM pool setting, a firewall rule) instead of opening a support ticket and waiting.
The tradeoff: you now own every layer. DNS, TLS issuance, mail transport, spam/blocklist reputation, backups, firewall, and the web server itself all become your problem. A managed host absorbs a huge amount of operational surface you don’t see until it’s gone. Part 8 has the fuller list of questions to ask before starting. This was not a weekend project. This was a lot of work. The hope for this series is that you will better understand what all went into this migration.
What we moved to
Hetzner Cloud, a CPX32 instance: 4 vCPU, 8GB RAM, 160GB disk, running Ubuntu 24.04, for $44/month. On top of that, Hestia Control Panel, an open-source, free alternative to cPanel/Plesk, that gives you nginx (as the SSL-terminating front end), Apache as a backend, Exim for mail, Dovecot for IMAP/POP, and a CLI (v-* commands) for scripting everything. No panel licensing fee, full root access, and a real shell.
For backups and media offload, we attached a 1TB Hetzner Storage Box (mounted over SSHFS at /mnt/storagebox and /mnt/media-yvodcom). An SSHFS mount is not a real block device. It doesn’t support arbitrary chown/chmod, mv across it isn’t atomic, and it is not safe for live, concurrently-written data like an active mail Maildir. We used it strictly for backups and for offloading large, mostly-static media directories. We kept live mail on local disk. If you want real POSIX block storage that can grow independently of your VPS’s fixed CPU/RAM/disk bundle, you will need a block storage add-on from your provider, and these are often billed separately at a much increased rate. We evaluated this and decided to hold off until disk pressure from a specific project justified it; SSHFS-for-backups plus local disk for everything live was enough for the size of this fleet.
One sizing lesson: most VPS plans are fixed CPU+RAM+disk bundles. There is usually no “just add more disk” option, and resizing is often one-way (you can scale up, not down). Decide your growth plan before you provision, or plan to add block storage for the parts of your storage that will actually grow (media, mail, backups) rather than over-provisioning the VPS itself.
The end state
By completion, the fleet was 27 dedicated Hestia accounts on a single VPS, each domain on its own system user (more on why that matters in Part 3), DNS for every live domain hosted on Cloudflare’s free tier, and SSL issued per-domain via Let’s Encrypt. A2 was drained down to zero accounts. SiteGround took longer to fully vacate because a chunk of its sites needed real, careful per-site migration rather than a bulk DNS flip, and because a few of the sites that looked “done” months ago turned out not to be (see Part 6).