Cómo migrar un VPS sin downtime: el método que llevamos años aplicando

Por qué importa hacerlo bien

Cualquier negocio que viva online tiene una pesadilla recurrente: que su web se caiga justo cuando empieza una campaña, un fin de semana largo o el día que el cliente importante decide entrar. Y migrar el servidor es uno de los momentos donde ese riesgo se concentra más.

La buena noticia es que la mayoría de las migraciones se pueden hacer sin que nadie lo note. La mala es que requieren método, no improvisación.

El método en cuatro fases

1. Auditoría del entorno actual

Antes de tocar nada, listamos:

• Versiones exactas de cada software (PHP, MySQL, Nginx/Apache, Node, etc.).
• Dependencias de sistema (extensiones de PHP, librerías nativas, paquetes APT).
• Servicios externos que llaman al servidor (cron de terceros, webhooks, integraciones).
• Volumen de datos en disco y en base de datos.
• Reglas de firewall, certificados SSL y DNS actual.

Sin este mapa, cualquier migración es jugar a la lotería.

2. Réplica en paralelo

Construimos el servidor nuevo en paralelo, sin tocar producción. Replicamos los datos:

• Archivos con rsync -avz --delete, programando varias pasadas hasta que el delta sea mínimo.
• Base de datos con un volcado completo y, en bases grandes, replicación binlog para tener el destino casi al día.

Probamos la web nueva en un dominio interno o un /etc/hosts modificado. Validamos cada flujo: alta de usuarios, formularios, pagos si aplica, integraciones externas.

3. Plan de corte (con vuelta atrás)

Aquí está el secreto. Antes del corte:

• Bajamos el TTL del DNS a 5 minutos 24 horas antes para que la propagación del cambio sea casi inmediata.
• Escribimos un plan de vuelta atrás documentado: qué se cambia, en qué orden, y cómo deshacerlo si algo sale mal.
• Avisamos al cliente del momento exacto y de la franja de bajo riesgo.

El día del corte, ejecutamos:

1. Última pasada de rsync con el sitio en modo lectura (mínimos minutos).
2. Cambio de DNS al servidor nuevo.
3. Verificación inmediata: web responde, formulario funciona, certificado SSL válido.

Si todo va bien, seguimos. Si algo no responde, revertimos el DNS y la web sigue como estaba en el servidor antiguo, sin que nadie lo haya notado.

4. Validación post-corte

24 horas vigilando logs, monitorización de uptime y métricas. Cualquier comportamiento extraño se diagnostica en caliente. Cuando tenemos varios días verdes, cerramos el servidor antiguo (no antes).

Errores frecuentes que evitar

• Migrar sin replicar antes: mover en directo es jugársela. Siempre primero clon, luego pruebas, luego corte.
• Olvidarse de los cron: los cron del servidor antiguo se quedan ahí ejecutándose si no los desactivas, y pueden generar duplicados o pagos repetidos.
• No probar formularios reales: enviar un correo de prueba desde el servidor nuevo no es lo mismo que recibirlo en la cuenta del cliente.
• No bajar el TTL antes: si el DNS tarda 24 horas en propagarse, la mitad del tráfico va al sitio viejo durante ese tiempo.

Cuánto suele tardar

Una migración estándar de un VPS pequeño se hace en 2–3 semanas: una de auditoría y réplica, una de pruebas y una para el corte y soporte. No se debe pretender hacerlo en un fin de semana, salvo casos triviales.

Resumen del método en una tabla

Comparativa rápida: hacerlo bien vs hacerlo a la brava

Preguntas frecuentes

¿Habrá downtime? Aspiramos a cero. En la mayoría de casos lo conseguimos. Si por la naturaleza del cambio fuera inevitable, lo planificamos en franja horaria de bajo tráfico y se avisa al cliente con antelación.

¿Y si algo sale mal? Tenemos plan de vuelta atrás documentado antes del corte. Si algo no encaja, el servicio sigue funcionando en el servidor original mientras corregimos.

¿Migráis bases de datos grandes? Sí. Hemos hecho migraciones de bases de varios gigabytes con réplica continua para minimizar el corte final.

¿Hace falta cambiar de proveedor de hosting? No necesariamente. La migración puede ser entre proveedores distintos, entre máquinas del mismo proveedor o incluso a una infraestructura on-premise. El método se adapta.

Conclusión

Migrar un VPS sin downtime no es magia: es disciplina. La parte que cuesta más no es la técnica, es la planificación previa. El día del corte solo se ejecuta lo que ya está validado.

Si tienes una migración pendiente y prefieres que la lleve un equipo con cicatrices reales, escríbenos y te contamos cómo lo plantearíamos en tu caso.