WordPress hosting for sites moving off self-managed Hetzner servers.
Nothing is wrong with the hardware. The problem is that one person built the stack, the documentation is in their head, and the site has become something only they can safely touch.
A stack somebody built by hand.
A self-managed server accumulates behaviour that nothing records. Finding it is the migration; copying the files is the easy half.
Cron jobs nobody wrote down
System crontabs routinely hold jobs the site depends on — feed imports, backups, cache warmers — that exist nowhere in WordPress. Each is found and reproduced deliberately.
Web server rules doing real work
Redirects, rewrites, access rules and rate limits often live in nginx or Apache config rather than in the site. Left behind, the site loses behaviour with nothing in WordPress to explain it.
A database tuned to that box
Buffer pools and connection limits were sized for one specific server. Those settings are re-derived from what the site actually uses rather than copied across.
Certificates and their renewal
Certbot timers, custom renewal hooks and any pinned configuration are replaced by managed TLS, so nobody has to remember why a renewal script exists.
Backups that stop being your job
Whatever script was writing snapshots is replaced by daily backups replicated off the origin, restorable from a dashboard rather than from a command you have to look up.
Find what the server was doing for you.
The failure mode here is not data loss. It is a site that works for three weeks and then misses the thing a forgotten cron job was doing every month.
- System crontab audited line by line
- Web server rewrites and rules ported
- TLS renewal replaced with managed certificates
- Backups moved off a hand-written script
The same hardware class, without the pager.
Self-managed servers are usually fast until something needs attention at an inconvenient hour. The gain here is operational rather than raw speed.
What we change moving from a self-managed server
These differ from a standard migration on the same plan, because the source has no defined configuration to import — only whatever the last administrator left behind.
| Setting | What we do | Why |
|---|---|---|
| Crontab audit | Every system cron entry reviewed and re-created explicitly | Self-managed sites accumulate scheduled work outside WordPress entirely, and because those jobs run monthly or quarterly their absence is discovered weeks after the migration looked successful. |
| Web server rules | Redirects, rewrites and rate limits extracted from server config and reproduced | Behaviour implemented in nginx or Apache is invisible from inside WordPress, so a migration that only moves the application silently drops rules the site's SEO and security depend on. |
| Database sizing | Re-derived from measured working set rather than copied from the old my.cnf | Those values were chosen for one machine's memory, often years ago and often by guesswork, so carrying them across preserves a decision nobody has revisited since the server was commissioned. |
| TLS renewal | Hand-rolled certbot timers and hooks replaced with managed certificates | Renewal scripts fail silently and are noticed when the certificate expires, which is the one failure mode that takes the entire site offline at an hour nobody chose. |
| Operational handover | Backups, monitoring and updates moved from personal scripts to the platform | The real risk on a hand-built server is that one person understands it, so the migration is complete only when nothing important depends on their memory. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
My Hetzner server is fast. Why move?
What is most commonly missed in this migration?
Do my nginx redirects come across?
Can you match my current MySQL tuning?
Will I still have SSH and WP-CLI?
Move off a hand-built server without losing what it did.
Free migration, every cron job accounted for, and TLS that renews without you.