12 · 5 hosting decisions · 2017 to today
Hosting Migration.
Sometimes the fastest fix is a different server. This page is about the move itself: picking the target for the right reason, rebuilding on staging, cutting over without downtime, and tuning after. Different from server tuning, which is about making the current host fast.
Routes discussed most in the archive.
- SiteGroundHetznertraveled: trykinshape.com, the AX52 single-thread play
- CloudwaysHetznerdiscussed in 13 threads; no named case
- WP Engineawaydiscussed in 11 threads; no named case
- BluehostLightSailtraveled: veteos.com, the budget-to-AWS move
- any hostLiteSpeeddiscussed in 17 threads; no named case
- no CDNCloudflare33 threads; sculpiflex runs behind it
How a migration runs.
- 01
Audit the current host
Field data first: TTFB distribution, cache-hit ratio, PHP worker saturation. If the numbers say the host is fine, the fix is cheaper than a move. We say so and stop.
- 02
Pick the target for the right reason
Single-thread PHP performance, not headline specs: the AX52 was chosen because WordPress renders on one core. LiteSpeed only when the plugin stack tolerates it.
- 03
Rebuild on staging
Fresh server, PHP version bump, cache layers rebuilt from scratch (not copied), DNS-low TTLs pre-set. The unstable new box gets kernel-level debugging before any site touches it.
- 04
Cut over without downtime
Data sync, parity checks on real URLs, then DNS flip with the old host kept warm for instant rollback. A cutover you cannot roll back is not a cutover, it is a bet.
- 05
Post-move tuning
The first week on new hardware is tuning, not celebration: cache warming, cron schedules, object-cache hit ratios, 28-day field-data watch.
The migrations.
TTFB was ~70% of LCP failure: geolocation currency switcher busted the page cache. Cloudflare/Hetzner migration, cache-control conflicts resolved, 504 checkout storms fixed, FunnelKit checkout stabilized. Ads-heavy store: every cache experiment gone wrong showed up same-day as a conversion crash, so per-currency page caching was built to be safe to test.
rousehome.com
WooCommerce on AWS EC2
Five-year server optimization on AWS EC2 (the stay-put counterexample): erratic TTFB (200 ms vs 3,000 ms for the same page, spikes to 10 s) stabilized with W3TC + Redis object caching on EC2.
SiteGround to Hetzner dedicated (AX52, chosen for single-thread performance): kernel-level debugging of unstable hardware on the new box, PHP 8.1 to 8.2, measured 25-30 percent faster server response mid-migration, mobile 24h-average TTFB pulled under 1s. Facts paraphrased from project records.
veteos.com
Video production site
Bluehost to Amazon LightSail migration with post-move speed work. Five-year relationship.
Ben James
AWS/EC2 hosted WordPress
Site creation and migration onto AWS EC2 with server-level configuration. Returning client for all WordPress and server needs.
"It's very hard to find people of this calibre, and we'll be using Milan in future for all our Wordpress/Server needs."
When NOT to migrate.
Most "we need better hosting" tickets are cache-coverage or plugin problems wearing a hosting costume. If field TTFB is fine on a cached page and terrible on real traffic, the page cache is being bypassed, and a new host inherits the same bug at a higher price. The audit phase exists to stop bad migrations before they start: several engagements on this page ended with the site staying put and getting fast anyway.
Unsure whether you need a new host or a better cache?
The audit answers that in the first hour. Free, honest, no obligation.
Get a free audit