Cómo migrar un sitio web a otro servidor sin downtime

Los dos tipos de downtime en una migración

Cuando migras una web a otro servidor, hay dos momentos donde puedes tener caída. El primero es durante la transferencia de datos — si intentas mover archivos con el sitio en producción, puedes acabar con datos inconsistentes. El segundo es durante el cambio de DNS, cuando el dominio deja de apuntar al servidor antiguo y empieza a apuntar al nuevo.

El primer tipo de downtime es totalmente evitable. El segundo se puede reducir a minutos si se planifica correctamente. La mayoría de las migraciones que salen mal fallan por no planificar el segundo.

Preparación: lo que hay que tener listo antes de tocar nada

La migración no empieza cuando copias archivos. Empieza días antes, con preparación:

1. Bajar el TTL del DNS

Este es el truco más importante y el que más gente ignora. El TTL (Time To Live) es el tiempo que los servidores DNS del mundo cachean tu registro. Si tu TTL está en 86400 (24 horas, un valor común por defecto), cuando cambies el DNS, algunos usuarios seguirán viendo el servidor antiguo durante un día entero.

48 horas antes de la migración, baja el TTL a 300 (5 minutos). Esto hace que cuando llegue el momento del cambio, la propagación sea casi inmediata.

# Antes (valor típico)
ejemplo.com.  86400  IN  A  1.2.3.4

# 48h antes de migrar
ejemplo.com.    300  IN  A  1.2.3.4

¿Por qué 48 horas antes? Porque necesitas esperar a que caduque el TTL antiguo. Si tu TTL era de 24 horas, después de 48 horas puedes estar seguro de que ningún DNS del mundo sigue cacheando con el valor antiguo.

2. Inventario completo del sitio

Antes de mover nada, documenta exactamente qué tiene el servidor:

Archivos del sitio (HTML, CSS, JS, imágenes, uploads)
Bases de datos (con sus usuarios y permisos)
Configuración del servidor web (Nginx, Apache, o lo que uses)
Certificados SSL (o planifica cómo generarlos en el nuevo servidor)
Crons y scripts automatizados
Configuración de email si aplica

He visto migraciones que parecían completas hasta que alguien descubrió que faltaban los cron jobs o que el envío de emails del formulario de contacto dependía de una configuración local del servidor antiguo.

3. Preparar el nuevo servidor

El nuevo servidor debe estar completamente configurado y funcionando antes de la migración:

Sistema operativo actualizado
Servidor web instalado y configurado
Certificados SSL generados (puedes usar validación DNS para generarlos antes de cambiar el registro A)
Firewall configurado
Backups configurados con un sistema externo y verificado

El proceso paso a paso

Una vez que el TTL está bajo y el nuevo servidor está preparado:

Paso 1: Copiar los datos

# rsync es tu mejor amigo para esto
rsync -avz --progress -e ssh /var/www/dominio.com/ nuevo-servidor:/var/www/dominio.com/

rsync es ideal porque si lo ejecutas dos veces, la segunda vez solo copia lo que ha cambiado. Esto permite hacer una primera copia con el sitio en funcionamiento y una segunda copia rápida justo antes del cutover.

Paso 2: Verificar en el nuevo servidor

Antes de cambiar DNS, verifica que el sitio funciona en el nuevo servidor. Puedes hacerlo editando tu archivo hosts local:

# /etc/hosts (Linux/Mac) o C:\Windows\System32\drivers\etc\hosts
IP_NUEVO_SERVIDOR  dominio.com  www.dominio.com

Navega al sitio desde tu navegador. Debería cargar exactamente igual que en el servidor antiguo. Comprueba:

Todas las páginas cargan correctamente
Las imágenes se ven
Los formularios funcionan
El certificado SSL es válido
Las redirecciones funcionan

Paso 3: Última sincronización

Si el sitio tiene datos que cambian (base de datos, uploads de usuarios), haz una última sincronización justo antes de cambiar DNS:

# Para bases de datos
mysqldump -u usuario -p nombre_db | ssh nuevo-servidor "mysql -u usuario -p nombre_db"

# Para archivos
rsync -avz --delete -e ssh /var/www/dominio.com/ nuevo-servidor:/var/www/dominio.com/

Paso 4: Cambiar DNS

Cambia el registro A del dominio a la IP del nuevo servidor. Con el TTL en 300, en menos de 5 minutos la mayoría del tráfico estará llegando al nuevo servidor.

Paso 5: Verificación post-cambio

Comprueba que el sitio responde desde la nueva IP: curl -I https://dominio.com
Verifica el certificado SSL desde el navegador
Prueba el formulario de contacto
Monitoriza los logs del nuevo servidor para confirmar que llega tráfico

Errores típicos que alargan el downtime

Después de hacer varias migraciones, estos son los fallos que más he visto:

No bajar el TTL con antelación: el error más común y el que más impacto tiene. Si tu TTL es de 24 horas cuando haces el cambio, prepárate para un día de inconsistencias.
No probar antes del cutover: “ya funcionará” no es una estrategia. Siempre verificar con hosts file antes de cambiar DNS.
Olvidar la base de datos: copiar los archivos pero no la base de datos (o copiar una versión antigua).
No considerar el email: si el mismo dominio gestiona email, cambiar el registro A puede afectar al correo si los registros MX no están correctamente separados.
Apagar el servidor antiguo demasiado pronto: mantén el servidor antiguo funcionando al menos 48-72 horas después del cambio. Algunos DNS tardan en propagar y algunos usuarios pueden seguir llegando al antiguo.

Periodo de solapamiento

La migración no termina cuando cambias el DNS. Durante las siguientes 48-72 horas, ambos servidores deberían estar funcionando. El antiguo va recibiendo cada vez menos tráfico hasta que deja de recibir por completo.

Solo cuando confirmes que el servidor antiguo no recibe tráfico desde hace al menos 24 horas, puedes apagarlo con seguridad. Si hay datos que cambian (uploads, formularios), necesitas una estrategia para sincronizar los que lleguen al servidor antiguo durante este periodo.

Una migración bien planificada no tiene por qué dar miedo. La diferencia entre una migración limpia y un desastre no es la habilidad técnica — es la preparación.

Si estás valorando migrar porque tu hosting actual se queda corto, puede que te interese la comparativa entre hosting compartido y VPS o la guía para elegir un buen proveedor de hosting. Y una vez migrado, asegúrate de tener acceso seguro mediante Cloudflare Tunnel para evitar exponer SSH al mundo.

Si prefieres que alguien gestione la migración sin riesgo de downtime, puedo encargarme de todo el proceso mientras tú te centras en tu negocio.