⏱️ Lectura: 12 min
La migración hetzner desde DigitalOcean se volvió un tema recurrente en foros de DevOps durante 2026: con el dólar fuerte, facturas de infraestructura de cuatro cifras al mes y cargas de trabajo bastante estables, muchos equipos en LATAM están descubriendo que un servidor dedicado en Alemania puede costar una fracción de un droplet equivalente en la nube. En este artículo vamos a desarmar, paso a paso, una migración real documentada por Isa Yeter: una empresa de software que pasó de pagar $1,432 al mes en DigitalOcean a $233 al mes en Hetzner, moviendo 248 GB de MySQL, 34 sitios de Nginx, GitLab EE y varias apps móviles sin un solo segundo de downtime.
📑 En este artículo
- Qué es una migración sin downtime y por qué cuesta tanto hacerla
- Cómo funciona una migración hetzner bien planeada
- Casos de uso reales para esta estrategia
- Ventajas y desventajas de una migración hetzner
- Preguntas frecuentes
- ¿Cuánto tiempo toma una migración hetzner real?
- ¿Sirve esta estrategia si uso Docker o Kubernetes?
- ¿Qué pasa con los registros MX y el correo durante la migración?
- ¿Es Hetzner confiable para producción crítica?
- ¿Puedo hacer algo parecido en LATAM sin mandar datos a Europa?
- ¿Qué herramientas necesito para replicar esto?
- Referencias
El objetivo no es venderte Hetzner ni enterrar a DigitalOcean. Es explicarte, con código y analogías, cómo se planifica este tipo de operación para que puedas replicarla en tu propio stack, sea cual sea el proveedor de origen y destino. Si nunca migraste una base de datos en caliente o nunca configuraste un proxy inverso para tapar un cambio de DNS, vas a salir con un mapa mental claro.
Qué es una migración sin downtime y por qué cuesta tanto hacerla
Cuando hablamos de migración sin downtime nos referimos a mover una aplicación viva de un servidor a otro sin que los usuarios perciban interrupción. No es lo mismo que un deploy: acá cambia el hardware, el sistema operativo, la IP pública, y muchas veces también la versión de MySQL, PHP o Nginx. La analogía más útil que conozco es la de reemplazar el motor de un avión en pleno vuelo: necesitás que el segundo motor ya esté encendido y girando antes de apagar el primero.
En un escenario ingenuo, un ingeniero apaga la app, hace un mysqldump, lo sube al servidor nuevo, cambia DNS y reza. Eso funciona para un blog personal, pero no para una plataforma con cientos de miles de usuarios móviles activos. Durante horas —el tiempo que tarde el dump y la propagación de DNS— el servicio queda caído, las apps fallan, el soporte se inunda de tickets y tu NPS se hunde. Una migración hetzner seria apunta a que siempre exista un camino vivo hacia los datos, incluso mientras el nuevo servidor se está terminando de armar.
Los tres enemigos de una migración
- Pérdida de escrituras: si se escribe en la base vieja después del dump, esos datos se pierden al apuntar DNS al server nuevo.
- Cachés de DNS: los resolvers de los ISP ignoran TTLs cortos si no los anticipaste; hay clientes que siguen pegándole a la IP vieja durante horas.
- Diferencias sutiles de entorno: una versión distinta de OpenSSL, un
php.inicon un límite diferente o un módulo de Nginx compilado con otras flags pueden romper en producción lo que funcionaba en el viejo server.
Cómo funciona una migración hetzner bien planeada
La estrategia documentada por Yeter se organiza en seis fases que puedes aplicar, con ajustes, a casi cualquier par de proveedores. La idea central es construir el nuevo servidor en paralelo, sincronizar todos los estados (archivos, base de datos, certificados) y recién entonces hacer el cutover, con el servidor viejo actuando de red de seguridad.
flowchart LR
A[DO droplet<br/>CentOS 7] -->|rsync web files| B[Hetzner AX162-R<br/>AlmaLinux 9.7]
A -->|replicación MySQL| B
A -->|rsync letsencrypt| B
C[DNS 300s TTL] -->|fase 6| D[nuevo IP]
A -->|proxy_pass| B
D -->|tráfico directo| BFase 1 — Instalar el stack espejo
En el servidor nuevo se instala exactamente el mismo stack que corre en producción: Nginx compilado desde fuente con las mismas flags, PHP desde el repo Remi con los mismos .ini, MySQL 8.0, Node.js, Supervisor, Gearman, Neo4j y GitLab EE. Cada servicio se prueba en aislamiento con datos sintéticos para detectar diferencias antes de tocar DNS. Los certificados Let’s Encrypt se clonan con rsync del directorio completo:
rsync -avz --progress \
/etc/letsencrypt/ \
root@new-server:/etc/letsencrypt/
Fase 2 — Clonar archivos web con rsync
El directorio /var/www/html del caso real pesaba ~65 GB con 1.5 millones de archivos. rsync sobre SSH con verificación por checksum es la herramienta correcta: transfiere solo lo que cambió y valida integridad. El truco para acercarse al cero downtime es correr una sincronización final incremental minutos antes del cutover:
# Sync inicial (lenta, una vez)
rsync -avzP --checksum /var/www/html/ \
root@new-server:/var/www/html/
# Sync incremental justo antes del cutover (rápida)
rsync -avzP --delete --checksum /var/www/html/ \
root@new-server:/var/www/html/💡 Tip: en Windows podés correr estos comandos desde WSL2 o desde Git Bash; en macOS rsync ya viene instalado. Si tus archivos son pocos pero pesan mucho (vídeos, dumps), considera usar rclone con paralelismo alto en lugar de rsync.
Fase 3 — Replicación MySQL master-slave
Acá está el corazón del zero downtime. En lugar de un mysqldump que bloquea tablas, el servidor viejo se vuelve master y el nuevo slave de solo lectura. Para la carga inicial de 248 GB de datos se usa mydumper, que paraleliza el export aprovechando los 48 núcleos del AX162-R. Lo que con mysqldump tradicional tomaría días, con mydumper termina en horas.
# Instalación en Linux (Debian/Ubuntu)
sudo apt install mydumper
# macOS
brew install mydumper
# Windows: usar WSL2 con Ubuntu
# Dump paralelo desde el master
mydumper \
--host=old-server \
--user=repl \
--password=*** \
--outputdir=/backup/dump \
--threads=16 \
--compress \
--triggers --events --routinesUna vez terminado el dump, el archivo metadata que genera mydumper contiene la posición exacta del binlog en la que se tomó la foto. Con ese dato se arranca la replicación en el slave:
CHANGE MASTER TO
MASTER_HOST='old-server',
MASTER_USER='repl',
MASTER_PASSWORD='***',
MASTER_LOG_FILE='mysql-bin.000123',
MASTER_LOG_POS=456789;
START SLAVE;
-- Verificar que no hay lag
SHOW SLAVE STATUS\GDesde ese momento, cada INSERT, UPDATE o DELETE que entre al master se replica casi instantáneamente al slave. Cuando llegue el momento del cutover, las dos bases están idénticas.
Fase 4 — Bajar el TTL del DNS
Los registros DNS tienen un Time To Live que le dice a los resolvers cuánto tiempo cachear la IP. Si tu TTL es de 3600 segundos (una hora) y cambiás el registro, puede pasar hasta una hora antes de que todos los clientes vean la nueva IP. Solución: bajar el TTL a 300 segundos un día antes del cutover, esperar que expiren los caches viejos, y recién entonces hacer el cambio.
# Script con la API de DigitalOcean
curl -X PUT \
-H "Authorization: Bearer $DO_TOKEN" \
-H "Content-Type: application/json" \
-d '{"ttl": 300}' \
"https://api.digitalocean.com/v2/domains/example.com/records/$ID"⚠️ Ojo: no toques los registros MX ni TXT. Cambiar TTL de registros de correo puede romper SPF/DKIM temporalmente y disparar falsos positivos en filtros antispam. Solo A y AAAA.
Fase 5 — Convertir el servidor viejo en proxy inverso
Este es el truco más elegante de toda la operación. Como la propagación de DNS nunca es instantánea, durante minutos u horas habrá clientes que sigan golpeando la IP vieja. En vez de devolverles un 502, el Nginx del servidor viejo se reconfigura para pasarle todas las peticiones al servidor nuevo:
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass https://new-server-ip;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Un script Python parsea los 34 archivos de configuración de Nginx, respalda los originales y reemplaza cada bloque server {} por uno con proxy_pass. El usuario final no nota nada: ve la misma IP, el mismo certificado, el mismo contenido. Solo que detrás de escena el contenido ahora lo sirve el servidor de Hetzner.
Fase 6 — Cutover y decomisión
Antes de mover el DNS, se hace STOP SLAVE en el server nuevo y se promueve a master. Luego, un script flipa todos los registros A y AAAA a la IP nueva en segundos. Durante la siguiente hora, el tráfico se va repartiendo: parte llega directo al servidor nuevo (clientes con el DNS ya actualizado) y parte pasa por el proxy inverso del viejo. En ambos casos la respuesta es idéntica. Una semana después, con todo el tráfico yendo directo, el droplet de DigitalOcean se apaga.
💭 Clave: el mantra a memorizar es “siempre hay un camino vivo hacia los datos”. Mientras eso sea cierto en cada fase, no hay downtime posible.
Casos de uso reales para esta estrategia
- Reducción de costos en startups LATAM: una startup con infraestructura dolarizada puede ahorrar entre 70% y 85% migrando cargas estables a servidores dedicados en Europa.
- Escape de distribuciones en EOL: muchos servidores que corren CentOS 7 (fin de soporte en 2024) aprovechan la migración para saltar a AlmaLinux 9, Rocky Linux o Debian 12.
- Consolidación de múltiples droplets: un AX162-R con 256 GB de RAM y 48 núcleos puede reemplazar 3 o 4 droplets medianos, simplificando operación y reduciendo factura.
- Cumplimiento de residencia de datos: equipos con clientes europeos muchas veces eligen Hetzner (Nuremberg, Falkenstein, Helsinki) por cumplimiento GDPR.
- Migración entre cloud providers sin que importe el destino: la misma receta sirve para ir de AWS EC2 a OVH, de Linode a DigitalOcean, o entre cualquier par de proveedores.
Ventajas y desventajas de una migración hetzner
Ventajas
- Price-performance brutal: un AX162-R entrega más CPU, RAM y NVMe que un droplet de $1,432 por $233 al mes.
- Hardware dedicado real: sin vecinos ruidosos robándote IOPS ni CPU steal.
- NVMe en RAID1 incluido: latencias de disco más bajas que casi cualquier SSD de nube pública.
- Red 1 Gbit/s sin cargos por tráfico: ideal para apps con salida de datos alta.
Desventajas
- Sin ecosistema gestionado: no hay Managed Databases, App Platform, Spaces o Functions. Todo lo administrás vos.
- Escalado vertical limitado: para crecer pedís otro servidor y lo configurás; no hay autoscaling.
- SLA y soporte más básicos: el modelo es “hardware funciona, lo demás es tuyo”. No esperes el mismo nivel de soporte 24/7 que en AWS.
- Setup inicial más pesado: la primera vez te toca instalar todo a mano o con Ansible, no con un click.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Cuánto tiempo toma una migración hetzner real?
El caso documentado llevó varias semanas de preparación (instalar stack, scripts, pruebas) y el cutover efectivo duró menos de 5 minutos. Para un proyecto mediano con una base de datos de decenas de GB, planeá entre 2 y 4 semanas desde el inicio del plan hasta el DNS flip.
¿Sirve esta estrategia si uso Docker o Kubernetes?
Sí, con variaciones. En vez de clonar /var/www/html, sincronizás los volúmenes. En vez de replicación MySQL manual, podés usar el operador del motor correspondiente. El principio —servidor paralelo, sync de estado, cutover con proxy— se mantiene igual.
¿Qué pasa con los registros MX y el correo durante la migración?
Si tu correo corre en el mismo servidor, primero migrá el mail por separado con un MX de transición. Si usás un proveedor externo (Google Workspace, Fastmail), no tocás los MX y listo. La regla es: nunca mezcles migración de web con migración de mail.
¿Es Hetzner confiable para producción crítica?
Sí. Hetzner opera desde 1997 y hostea cargas serias en Europa. Lo que no ofrece es el mismo nivel de servicios gestionados que un hyperscaler. Si tu arquitectura depende de Lambda, DynamoDB o IAM específico, Hetzner no es el destino correcto; si tu stack es servidor Linux + base de datos + workers, encaja perfecto.
¿Puedo hacer algo parecido en LATAM sin mandar datos a Europa?
Sí: proveedores como Vultr (Ciudad de México, São Paulo), DigitalOcean (São Paulo) u OVH (Beauharnois) ofrecen dedicados regionales. El precio no baja tanto como en Hetzner, pero la latencia para usuarios LATAM mejora. La receta de migración es exactamente la misma.
¿Qué herramientas necesito para replicar esto?
Lo mínimo: rsync, ssh, mydumper/myloader, certbot, acceso a la API DNS de tu proveedor, y un par de scripts en Python o Bash para automatizar el cutover. Todo es open source y gratuito.
Referencias
- Migrating from DigitalOcean to Hetzner — Isa Yeter — caso real documentado que inspiró este artículo.
- mydumper en GitHub — herramienta de dump paralelo para MySQL usada en la migración.
- Hacker News — discusiones recurrentes sobre costos de infraestructura y comparativas entre VPS.
- Hetzner en Wikipedia — contexto histórico y operativo del proveedor alemán.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios