Migramos a un cliente de hosting sin downtime: así lo montamos un fin de semana

Un cliente con una tienda de muebles artesanales nos escribió en agosto porque el hosting que tenía desde hacía cuatro años (contratado antes de trabajar con nosotros) le subió el precio un 40% de un mes a otro, sin aviso, solo una factura distinta en el correo. Decidió irse. El problema es que esa tienda recibe pedidos todos los días, también los sábados, y parar la web ni dos horas significaba perder ventas de verdad, no una métrica rara en un dashboard.

Migrar una web a otro hosting sin downtime significa, en la práctica, tener los dos servidores funcionando en paralelo durante el cambio y bajar el TTL de los registros DNS días antes, para que la propagación sea cosa de minutos y no de las 24-48 horas habituales. Esa es la respuesta corta. La larga tiene más matices de los que parece a primera vista.

Lo primero que hicimos, una semana antes de mover nada, fue bajar el TTL de todos los registros a 300 segundos. Por defecto muchos proveedores lo dejan en 3600 o incluso 86400, y si cambias el DNS con ese valor puesto, hay resolvers por el mundo que van a seguir apuntando al servidor viejo durante casi un día entero, dando igual lo que hayas migrado. Con TTL bajo, en cinco minutos la mayoría de visitas ya caen en el servidor nuevo.

Lo que falla si solo cambias el DNS y ya

El error típico es preparar el servidor nuevo, cambiar el registro A, y confiar en que todo fluye solo. No fluye solo. Durante la ventana de propagación, que con TTL bajo seguía siendo de un par de horas y no instantánea, tuvimos tráfico cayendo en los dos servidores a la vez. Si el servidor viejo sigue recibiendo pedidos mientras el nuevo ya tiene su propia base de datos, se te duplican o se te pierden ventas entre medias. Lo resolvimos poniendo el servidor viejo en modo solo lectura 48 horas antes del cambio, con un aviso discreto en el checkout, y sincronizando la base de datos una última vez justo antes de apagarlo del todo.

El correo es lo que casi nadie recuerda

Y luego está el correo, que es lo que de verdad nos la jugó. Cambiamos el registro A pensando solo en la web, y se nos olvidó que los MX seguían apuntando al hosting viejo (cosa lógica, porque el correo no vivía ahí), pero el propio panel del hosting antiguo redirigía internamente el tráfico SMTP de forma rara que no habíamos documentado. Durante cuarenta minutos los formularios de contacto no llegaron a ningún sitio. Nadie se quejó, por suerte, pero fue el tipo de fallo silencioso que solo detectas si estás mirando los logs esa misma tarde, algo que ya hacemos por sistema después del día que un hosting se cayó sin avisar y aprendimos a no confiar en que “si no se queja nadie, va bien”.

Al final migramos ese cliente a uno de los VPS propios que gestionamos nosotros, con monitorización activa desde el primer minuto, no a los tres meses cuando ya nos fiamos. Costó un sábado entero y dos cafés de más, pero el lunes el cliente ni sabía que había cambiado de proveedor.

Lo que me sigue incomodando, meses después, es que todo este proceso depende de una checklist mental que tenemos en la cabeza del equipo y en ningún sitio escrito con el detalle suficiente. Cada migración hemos recordado algo distinto a última hora —el correo esta vez, los webhooks de un plugin de pagos la anterior—. ¿Cuántas cosas invisibles dependen todavía de que alguien se acuerde justo a tiempo?