How to Migrate from Hetzner: A Step-by-Step Guide

Hetzner has long been a popular choice for affordable European hosting, but it isn't the right fit for every business. If you've ever had an account flagged without warning, struggled to get billing in your local language, or simply wanted a provider closer to the Central and Eastern European market, this guide walks you through migrating your VPS or dedicated server to MMITech with minimal downtime.

We've helped dozens of customers move from Hetzner over the past year. The process is straightforward when you follow the right sequence, and most workloads can be cut over in under an hour of actual downtime.

When migrating from Hetzner makes sense

Hetzner is a competent provider. Migration is worth your time when one or more of these apply:

• You've experienced sudden account suspensions or holds, often triggered by automated abuse detection on shared subnets.
• You need invoicing in Slovenian, Croatian, Czech, or Hungarian, or VAT documentation that matches your local accounting requirements.
• Your customers are based in the CEE region and latency to Falkenstein or Helsinki is hurting performance.
• You want support in your own time zone with response times measured in minutes rather than business days.
• You need block or object storage with the same Ceph-backed redundancy without paying for separate add-ons.
• You're consolidating multiple providers and want a single billing relationship for VPS, dedicated servers, Nextcloud storage, and domains.

If none of these apply, staying put is a valid choice. If even one does, keep reading.

Pre-migration checklist

Before you provision anything on our side, document what you have on Hetzner. Spending an hour here saves four hours later.

1. Inventory every service running on the server. Web server, databases, cron jobs, mail, message queues, background workers, monitoring agents, VPN endpoints. A simple systemctl list-units --type=service --state=running is a good starting point.
2. List all domains and DNS records. Note current TTLs and where DNS is hosted. If DNS is at Hetzner Console, you'll need to migrate that too or move to a third party like Cloudflare first.
3. Document database sizes and engines. MySQL, MariaDB, PostgreSQL, Redis, MongoDB. Note versions, because version upgrades during migration multiply risk.
4. Note all open firewall ports and any Hetzner Cloud Firewall rules. These don't migrate automatically.
5. Identify external services that whitelist your current IP. Payment gateways, SMTP relays, API partners, monitoring services. Each will need updating after cutover.
6. Check SSL certificate sources. Let's Encrypt certificates regenerate easily. Paid certificates may be tied to the current IP or hostname.
7. Backup before you start. Take a full snapshot or export. If anything goes wrong during migration, you have a known-good restore point.

Step 1: Provision your MMITech VPS

Order a VPS that matches or slightly exceeds your current Hetzner specs. If you're on a Hetzner CX or CCX line, our Cloud VPS plans map cleanly to the same RAM and CPU profile. If you're running CPU-intensive workloads like compilation, video encoding, or large databases, the AMD VPS line offers significantly better single-thread performance on Ryzen cores.

Choose the same operating system version you're running on Hetzner. Migrating Ubuntu 22.04 to Ubuntu 22.04 is straightforward. Migrating across major versions during a host migration is a recipe for surprises. Do that as a separate project.

Once provisioned, complete basic hardening before you copy anything across:

# Update the system
apt update && apt upgrade -y

# Create a non-root user
adduser deploy
usermod -aG sudo deploy

# Copy your SSH key
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

# Disable root SSH and password auth
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

Step 2: Lower DNS TTLs before you migrate

This is the step most people skip and later regret. At least 24 to 48 hours before cutover, lower the TTL on every DNS record you'll be changing.

If your records currently have a TTL of 3600 or 14400 seconds, drop them to 300. This way, when you flip DNS, propagation completes in 5 minutes rather than 4 hours. After migration is verified, raise TTLs back to 3600.

If your DNS is hosted at Hetzner Console and you plan to move it, do that step now too. Move DNS to Cloudflare or another provider while still pointing at the Hetzner IP. This gives you one less variable to change at cutover time.

Step 3: Initial data sync

For most servers, rsync over SSH is the right tool. The trick is doing it in two passes: a first pass while the source is live, then a final delta sync after stopping services at cutover.

From your new MMITech VPS, pull data from Hetzner:

# Sync web roots
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@old-hetzner-ip:/var/www/ \
  /var/www/

# Sync application directories
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@old-hetzner-ip:/opt/ \
  /opt/

# Sync home directories
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@old-hetzner-ip:/home/ \
  /home/

# Sync configurations
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@old-hetzner-ip:/etc/ \
  /etc/hetzner-backup/

Pull /etc/ into a separate directory rather than overwriting your fresh install. You'll reference it for service configurations rather than blindly copying.

For Docker hosts, rsync /var/lib/docker/volumes/ and your compose files. Don't try to copy /var/lib/docker/ wholesale, that path is not safely portable.

Step 4: Migrate databases properly

Databases need a dump-and-restore approach, not a file copy. Copying raw database files between running instances corrupts data more often than not.

For MariaDB or MySQL:

# On the old Hetzner server
mysqldump --all-databases \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  | gzip > /tmp/full-dump.sql.gz

# Transfer
scp /tmp/full-dump.sql.gz root@new-mmitech-ip:/tmp/

# On the new MMITech server
zcat /tmp/full-dump.sql.gz | mysql

For PostgreSQL:

# On Hetzner
pg_dumpall -U postgres | gzip > /tmp/pg-dump.sql.gz

# On MMITech
zcat /tmp/pg-dump.sql.gz | psql -U postgres

Run a test dump and restore well before cutover. Confirm the new server boots applications cleanly against the restored data. Fix any version-mismatch errors now, not during a 2 AM cutover.

Step 5: Reinstall and configure services

Don't copy binaries or systemd units verbatim from the Hetzner server. Install services fresh on MMITech, then layer your configurations on top.

Typical reinstall sequence:

# Web server
apt install -y nginx

# PHP if needed
apt install -y php-fpm php-mysql php-redis php-curl php-gd \
               php-imagick php-mbstring php-xml php-zip

# Database client tools (servers already done in step 4)
apt install -y mariadb-client redis-tools

Then copy specific config files from your /etc/hetzner-backup/ directory:

cp /etc/hetzner-backup/nginx/sites-available/* /etc/nginx/sites-available/
cp /etc/hetzner-backup/php/8.2/fpm/pool.d/* /etc/php/8.2/fpm/pool.d/

# Test before enabling
nginx -t

This approach catches Hetzner-specific assumptions in your old configs, like hardcoded private network interfaces or Hetzner Cloud metadata service references, before they break things.

Step 6: Final sync and cutover

Schedule the cutover during a low-traffic window. For most European businesses, this is between 23:00 and 05:00 CET.

Cutover sequence:

1. Put a maintenance page on the Hetzner server, or enable read-only mode in your application.
2. Stop write-heavy services on Hetzner: web server, application workers, cron.
3. Run a final rsync delta from MMITech to pull any changes since the initial sync.
4. Take a final database dump and restore it on MMITech.
5. Start services on MMITech and run a smoke test against the new IP directly (use curl --resolve or edit your local hosts file).
6. Verify SSL certificates are valid. Re-issue Let's Encrypt certs with the new IP if needed once DNS propagates.
7. Flip DNS A and AAAA records to the new MMITech IP.
8. Monitor logs on both servers. Hetzner traffic should taper to zero over 5 to 30 minutes as caches expire.

Step 7: Post-migration verification

Don't decommission Hetzner yet. Leave it running in read-only or shut-down state for at least 7 days. This gives you a fast rollback option and time to catch issues.

Verify these items in the first 24 hours:

• All websites load correctly with valid SSL.
• Email delivery works in both directions. Re-do SPF, DKIM, and DMARC if you self-host mail.
• Cron jobs are running. Check log files at expected times.
• Application logs show no recurring errors.
• External services that whitelist by IP have been updated.
• Monitoring agents report from the new server.
• Backups are running on the new server.

After 7 days of clean operation, you can safely cancel the Hetzner server. We can help you reclaim any remaining prepaid balance via a final invoice reconciliation on our side.

Common pitfalls when migrating from Hetzner

Hetzner Cloud private networks don't exist on the new side. If your applications reference 10.x.x.x addresses for inter-server communication, you'll need to set up equivalent private networking or VPN connectivity at MMITech. We support private VLANs for multi-server setups.

rDNS isn't automatic. Reverse DNS for mail-sending servers needs to be set up on our side via a support request. Do this before cutting over mail.

Cloud-init metadata is provider-specific. Anything relying on Hetzner's metadata service will fail silently. Search your codebase for 169.254.169.254 references.

Hetzner Storage Box paths break. If you mount a Hetzner Storage Box for backups, set up alternative backup storage. We offer dedicated backup space with Proxmox Backup Server compatibility.

Frequently asked questions

How long does a typical Hetzner to MMITech migration take?

For a single VPS running a standard LAMP or LEMP application with under 50 GB of data, expect 2 to 4 hours of preparation and 30 to 60 minutes of actual downtime. Larger databases or complex multi-service setups need proportionally more planning.

Can MMITech help with the migration?

Yes. We offer migration assistance for customers ordering VPS or dedicated plans. Contact our team before you start and we can plan the migration window, advise on sizing, and assist with the cutover.

Will I lose data during migration?

If you follow the dump-and-restore database approach and run a final rsync at cutover, no. The risk window is the few minutes between final sync and DNS propagation, which is why lowering TTLs in advance matters.

Do I need to migrate all my services at once?

No. Many customers migrate workload by workload. Move a development VPS first, validate the experience, then move production. This is also the right approach if you're consolidating from multiple Hetzner servers.

What about my domains registered with Hetzner?

Domain transfers are separate from server migrations. Once your services are running on MMITech, you can transfer domains to us at any time. We support most TLDs through our domain transfer service.

Ready to migrate?

If you've read this far, you have a clear picture of what migration involves. We've built our infrastructure on enterprise Ceph storage, redundant 40 GbE networking, and EU-located(Slovenia) datacenter specifically for customers who need reliability without the corporate overhead of larger providers.

Order a Cloud VPS or AMD VPS and reach out to our team if you want help planning the cutover. We'll respond in your language, in your time zone, and we'll be the same people you talk to next month when you need something else.