Migré 6 sistemas a un servidor nuevo y nadie lo notó: el checklist

Un viernes de octubre, a las 11 de la noche, empecé a mudar seis sistemas a un servidor nuevo: Acredita y Comprobia, dos APIs de las que dependen otros sistemas; Podoplus, el sistema de una cadena de 17 centros podológicos; Acopla, FRIDAY, mi asistente, y la demo de FarmaOrden. Venían de dos servidores distintos e iban a uno solo, más grande.

A la 1:27 de la madrugada estaban todos en el servidor nuevo. Cada sistema estuvo detenido entre 3 y 23 minutos, uno por uno, y ningún cliente lo notó.

No fue suerte. Fue una lista, la misma que uso en cualquier mudanza, y te la dejo completa, con lo que salió mal esa noche.

El checklist, en una tabla

Fase	Qué se hace	Para qué
Antes	Preparar el servidor nuevo con las mismas versiones del viejo	Que nada cambie salvo la máquina
Antes	Probar cada sistema en el servidor nuevo sin tocar el DNS	Encontrar los problemas cuando todavía no hay apuro
Antes	Copiar los datos una primera vez, con el sistema funcionando	Que la copia de la noche sea solo la diferencia
Antes	Bajar el TTL del DNS y elegir la ventana	Que el cambio se propague rápido y a una hora tranquila
Corte	Detener, copiar la diferencia y levantar en el servidor nuevo	Que el corte dure minutos, no horas
Corte	Apagar de verdad el sistema viejo	Que no queden dos copias trabajando a la vez
Corte	Cambiar el DNS y verificar con lo que usa el cliente	Saber que funciona, no suponerlo
Después	Dejar el viejo detenido, no borrado, una semana	Tener a dónde volver
Después	Respaldos fuera del servidor, y una restauración de prueba	Saber que el respaldo sirve

Antes del corte

1. Un servidor nuevo igual al viejo, salvo la máquina

La regla es simple: el único cambio de la noche tiene que ser el servidor. Si además subes de versión la base de datos o Docker, y algo falla, no sabrás qué lo rompió.

En el servidor nuevo instalé la misma versión mayor de Docker que tenía el viejo y usé exactamente la misma imagen de PostgreSQL. Antes de mover nada lo dejé listo para producción: acceso por SSH solo con llave, firewall abierto únicamente en los puertos 22, 80 y 443, actualizaciones de seguridad automáticas, memoria swap y tope al tamaño de los logs, para que un log desbocado no llene el disco. Delante de todo puse un proxy que reparte el tráfico por dominio, así cada sistema conservó su docker-compose tal como estaba.

2. Probar sin tocar el DNS

Antes del corte, cada sistema se levanta en el servidor nuevo y se prueba como si el DNS ya apuntara ahí. Con curl --resolve le pides a tu dominio real que conteste desde la IP nueva, sin que ningún usuario llegue todavía:

curl --resolve app.tudominio.com:443:IP_DEL_SERVIDOR_NUEVO https://app.tudominio.com/salud

Si eso responde bien, el corte es casi un trámite. Si no, encontraste el problema un martes por la tarde y no un viernes a medianoche. El script de corte también se prueba en seco antes de la noche.

3. Copiar en dos pasadas

Copiar una base de datos grande con el sistema detenido puede tomar una hora. Por eso la copia se hace dos veces: una primera, en caliente, días u horas antes, con el sistema funcionando; y la final, con el sistema detenido, que solo lleva la diferencia. El corte dura lo que dura esa diferencia, no la copia completa.

La copia final va en frío: primero se detiene el sistema y después se copian los volúmenes, con verificación por suma (rsync --checksum). En los sistemas con colas, antes de detener hay que vaciarlas. En Comprobia pausé los workers y esperé a que la cola quedara en cero, para que ningún comprobante quedara a medio enviar a SUNAT.

4. El TTL y la ventana

El TTL es cuánto tiempo guardan los demás la dirección de tu dominio. Si está en 1800 segundos, hay quien seguirá yendo al servidor viejo hasta media hora después del cambio. Bájalo a 300 un día antes. En una mudanza anterior, con el TTL en 300, la propagación tomó menos de un minuto.

La ventana se elige mirando lo que ya corre en el servidor: yo evité los procesos nocturnos de las 3:00 y de las 4:30. Y cada sistema se corta por separado: si uno se complica, los demás no esperan.

La noche del corte

5. Apagar de verdad el viejo

Detener los contenedores no basta. Si el servidor viejo se reinicia, Docker los vuelve a levantar, y de pronto hay dos copias del mismo sistema escribiendo en dos bases distintas o enviando el mismo comprobante a SUNAT. Lo aprendí en una mudanza anterior.

Por eso, en el viejo, cada sistema queda con restart=no, su carpeta renombrada (sistema.migrado) y sus tareas programadas desactivadas. Así nada lo despierta por accidente.

6. DNS y certificados

Esa noche cambié siete registros de DNS. Para que el HTTPS funcione desde el primer minuto, copié al servidor nuevo los certificados que ya existían y, cuando el DNS ya apuntaba ahí, los pasé a la renovación automática con certbot. La prueba de renovación (certbot renew --dry-run) pasó para los nueve.

Un detalle que me costó un rato: la prueba de renovación falla si no copias también la cuenta de Let's Encrypt (/etc/letsencrypt/accounts). Los certificados solos no bastan.

7. Verificar con lo que usa el cliente

Que la página responda 200 no significa que funcione. Cada sistema se verifica con lo que de verdad hace:

• Acredita pasó su batería de pruebas de punta a punta, y comprobé que la IP real de cada cliente siguiera llegando a través de los proxies.
• Comprobia emitió una factura de prueba desde el servidor nuevo, y SUNAT la aceptó en su entorno de pruebas.
• Acopla, con su monitor y su respaldo funcionando.

En una mudanza posterior aprendí lo del 200 por las malas: dos servicios chocaron en el mismo puerto, y la página respondía 200 sin mostrar lo que tenía que mostrar. Desde entonces reviso el contenido, no solo el código de respuesta.

Después del corte

8. Tener a dónde volver

Los sistemas viejos quedaron detenidos, no borrados, durante una semana, junto con un respaldo cifrado tomado durante la ventana. Si algo grave aparecía en esos días, volver era levantar el viejo y devolver el DNS. Esa semana se duerme distinto.

9. Lo que se olvida: el CI y los scripts

Justo al terminar, a la 1:27, un despliegue automático de Podoplus falló: el CI seguía apuntando al servidor viejo. En el checklist ahora está, con su propia casilla: los secretos del CI, los scripts de despliegue y las tareas programadas también se mudan.

Lo que salió mal esa noche

Nada de esto llegó a los usuarios, pero cada punto me costó tiempo:

• El corte de Acredita duró 19 minutos y medio, contra los 5 a 10 que había calculado. Calcula el doble.
• ssh servidor 'bash -s' < script.sh falla en silencio si el script usa ssh o apt adentro: se comen la entrada del script. La solución: copiar el script con scp y ejecutarlo como archivo, con < /dev/null.
• Las tareas largas mueren si se corta tu conexión SSH. Se corren con nohup en el servidor.
• pkill -f patrón puede matar a la propia shell que lo ejecuta, porque el patrón también aparece en su comando. Se evita con un corchete: pkill -f '[m]i-proceso'.
• nginx -t | tail -1 && systemctl reload nginx esconde el error: el && mira el resultado de tail, no el de nginx. Lo correcto: nginx -t -q && systemctl reload nginx.
• Una imagen se levantó con la etiqueta :latest porque faltaba la variable con su versión. Fija siempre la versión.

Un respaldo que nunca restauraste no es un respaldo

Esa es la frase que más repito, y la mudanza la confirmó.

Hasta esa semana, varios sistemas guardaban sus respaldos en su propio disco: si se perdía el servidor, se perdían con él. Y al revisar encontré algo peor que un respaldo sin probar: dos sistemas en producción que no tenían ninguna copia.

Al día siguiente de la mudanza quedaron los respaldos cruzados: cada servidor guarda los del otro. La llave que usa cada uno solo puede escribir: no puede borrar, no abre una consola y solo acepta conexiones desde el otro servidor. Si alguien entra a un servidor, no puede destruir los respaldos del otro.

Y cada respaldo se restauró antes de darlo por bueno. La copia más grande, de 21 bases de datos, se restauró en 15 minutos, con los conteos idénticos a los de producción. Otra prueba falló la primera vez: el disco nuevo era más rápido y el script revisaba la base antes de que terminara de arrancar. El respaldo estaba bien; la prueba no. Lo encontré porque restauré.

Hoy, además, una alerta me avisa si un respaldo no llegó a tiempo, y el envío se reintenta solo.

Dónde entró la IA

Hice la mudanza con Claude Code como copiloto de DevOps: escribió y corrió los scripts, revisó cada paso y llevó la bitácora de la noche. Las decisiones fueron mías: cuándo cortar cada sistema, cuándo seguir y cuándo volver. Los cambios de DNS los hice yo, a mano.

La IA no hace segura una mudanza. La hace más rápida, y por eso la lista importa más: lo que no está escrito en el checklist tampoco lo revisa nadie.

Preguntas frecuentes

¿Cuánto dura el corte al migrar a otro servidor?

Con la copia en dos pasadas, lo que tarde en copiarse la diferencia y en levantar el sistema: en mi caso, entre 3 y 23 minutos por sistema. Sin la primera pasada, el corte dura lo que tarda la copia completa, que con bases grandes puede ser una hora o más.

¿Se puede migrar sin detener el sistema ni un minuto?

Sí, con replicación de la base de datos y un cambio gradual del tráfico, pero es bastante más trabajo y más riesgo. Para la mayoría de los sistemas, unos minutos de madrugada, ensayados y con vuelta atrás, son el mejor balance.

¿Qué hago si algo falla a mitad del corte?

Volver: por eso el viejo se detiene y no se borra. Si el sistema nuevo no pasa la verificación, levantas el viejo, devuelves el DNS y lo intentas otro día, con el problema ya identificado. Decide antes de empezar cuánto tiempo le das a cada sistema antes de volver.

¿Cada cuánto conviene probar los respaldos?

Al menos una vez al mes, y siempre después de cambiar algo en el servidor o en el respaldo. La prueba es restaurar en una base aparte y comparar con producción, no solo ver que el archivo existe.

En resumen

Mudar un sistema en producción no es difícil. Es largo, y lo que lo vuelve seguro es hacer casi todo antes del corte: el servidor nuevo igual al viejo, la prueba sin tocar el DNS, la primera copia y el TTL bajo. La noche del corte queda para copiar la diferencia, apagar de verdad el viejo y verificar con lo que usa el cliente. Después, una semana con el viejo detenido y respaldos que ya restauraste.

El mismo servidor recibió días después este sitio y mi propio n8n. Si tienes que mudar un sistema, o no sabes si tus respaldos sirven, eso es lo que hago en despliegue e infraestructura. Agenda una llamada de 20 minutos y lo vemos.