Cómo migrar tu servidor de hosting sin perder datos

Todo lo que vive alrededor

La carpeta con el sitio o la aplicación se copia sola: salta a la vista y va la primera. Lo que se queda atrás es todo lo que vive alrededor de ella y que, sin hacer ruido, sostiene el conjunto.

Los mismos culpables aparecen una y otra vez: los usuarios del sistema y sus permisos, que en la máquina nueva hay que recrear con el mismo identificador para que los archivos copiados sigan perteneciendo a quien deben; las tareas programadas —esos cron que hacen la copia de seguridad de madrugada o envían un aviso los lunes— que no están dentro de ninguna carpeta del proyecto; los certificados TLS y su renovación automática; las reglas del firewall que dejan pasar un par de puertos y cierran el resto; las variables de entorno y los secretos, que casi por definición nunca acaban en el repositorio; y los registros DNS que no son la web —el correo, los subdominios, el SPF— que se rompen en silencio si solo miras la dirección principal.

El patrón es siempre el mismo: lo visible se copia sin esfuerzo, y lo invisible es lo que tira la migración abajo tres días después, cuando resulta que el aviso de los lunes ya no llega o el correo empieza a rebotar. Una migración seria arranca sacando esa mitad invisible a la luz.

Antes de mover nada, el inventario

Un servidor es una carpeta más un montón de decisiones tomadas hace meses que nadie apuntó. Migrar bien consiste, en buena parte, en reconstruir esas decisiones en un sitio nuevo; y para reconstruirlas primero hay que encontrarlas.

El inventario responde a preguntas concretas. ¿Qué procesos arrancan solos cuando la máquina se enciende? ¿Qué se ejecuta en un horario, aunque nadie lo mire? ¿Qué puertos están abiertos y por qué? ¿Con qué servicios de fuera habla la máquina —una pasarela de pago, el correo saliente, algún API— y con qué credenciales? ¿Qué versiones exactas de cada pieza hacen falta para que todo encaje igual que hoy?

Anotar todo esto marca la diferencia entre una migración que se puede repetir y verificar y otra que se improvisa de memoria y descubre los huecos en producción. Cuando el inventario está completo, montar el servidor nuevo se convierte en una lista que se va tachando.

El orden que deja fuera los sustos

Con el inventario en la mano, el trabajo cae en una secuencia natural. No es arbitraria: el orden existe para que nada irreversible ocurra hasta que el servidor nuevo se haya ganado tu confianza. Cada paso deja intacto el anterior por si hay que retroceder.

1. Preparar el servidor nuevo: usuarios, servicios, certificados, reglas de firewall y bajar el TTL del DNS a unos minutos con un par de días de antelación.
2. Copiar datos y configuración; verificar que arranca y funciona igual.
3. ¿El nuevo pasa una prueba real? Sí → cambia el DNS (el TTL ya lleva días bajo). No → sigues en el viejo, sin drama.
4. Cuando todo el tráfico ya va al nuevo, apaga el viejo.

Fíjate en dónde está la decisión. Todo lo que va antes de esa pregunta es reversible —montar, copiar, verificar— y no se ha tocado a un solo usuario real. El único paso que expone a la gente al servidor nuevo es el cambio de DNS, y llega detrás de una prueba que tiene permiso para decir «todavía no». Ese es el punto de no retorno, y por eso se cruza el último y con red debajo.

El DNS va el último, y es reversible casi hasta el final

El DNS es la guía telefónica de internet: traduce el nombre del dominio a la dirección de la máquina que responde. Cambiarlo es lo que manda a los visitantes al servidor nuevo, así que se deja para el final, cuando ya no queda nada por comprobar.

Ese cambio no es instantáneo. Los intermediarios de medio mundo guardan la respuesta durante un tiempo —el TTL, o «tiempo de vida»— y siguen mandando gente al servidor viejo hasta que esa copia caduca. Con un TTL de veinticuatro horas, hay quien tardará casi un día en ver el cambio.

El truco es preparar ese momento con antelación. Un par de días antes se baja el TTL a unos minutos. Así, el día del cambio, la propagación es cuestión de minutos en vez de horas y —esto es lo importante— si algo va mal, volver a apuntar al servidor viejo también surte efecto enseguida. Mientras dura la propagación conviven los dos: parte del tráfico va a uno y parte al otro. Por eso el viejo sigue encendido y sirviendo, y no se toca hasta que los registros confirman que ya no le llega nadie.

Qué cuenta como «una prueba real»

La decisión de arriba se apoya entera en una prueba, así que conviene ser exigente con qué significa «pasar». Que cargue la portada demuestra poco: demuestra que el servidor sirve una página, no que la aplicación funciona.

Una prueba real ejercita los caminos que importan. Si hay que entrar con usuario y contraseña, se entra. Si un formulario guarda en la base de datos, se envía uno y se comprueba que llega y se almacena. Si algo se ejecuta de madrugada, se fuerza a mano y se mira que haga su trabajo. Si sale correo, se manda uno y se confirma que ni rebota ni acaba en spam. Si se suben archivos, se sube uno de tamaño real.

Lo mejor es probar contra el dominio real sin que el mundo se entere todavía. Eso se consigue apuntando solo tu ordenador al servidor nuevo —editando el fichero hosts de tu equipo— mientras el DNS público sigue mandando a todos los demás al viejo. Ves exactamente lo que verán los usuarios, con el nombre real del dominio y su certificado, y sin arriesgar a nadie. Si algo chirría, se arregla en el nuevo con calma; el público sigue tan tranquilo en el viejo.

El dato que cambia mientras copias

La parte más delicada de cualquier migración es el dato que no se queda quieto. Copiar archivos estáticos es fácil; copiar una base de datos que sigue recibiendo pedidos, mensajes o altas mientras la copias es donde la gente tropieza. Lo que copiaste hace media hora ya está desactualizado.

Hay varias formas honestas de resolverlo, según cuánto puedas parar. La más sencilla es una ventana de mantenimiento: se avisa, se deja el sitio en modo solo lectura o cerrado un rato corto, se hace la copia final con el dato ya quieto y se cambia el DNS. Cuando parar no es opción, se copia el grueso con todo en marcha y, justo antes del cambio, se sincroniza solo lo que ha cambiado desde entonces —el «delta»—, que al ser poco viaja en segundos.

Sea cual sea el método, la idea es la misma: entre «la última foto buena» del dato viejo y el primer visitante que escribe en el nuevo no debe colarse ni un cambio sin copiar.

Ese instante —la sincronización final pegada al cambio de DNS— es el que hay que planificar con más cuidado de todo.

El plan de vuelta

Toda la secuencia está montada para que dar marcha atrás sea aburrido, y aburrido es justo la sensación que buscas. Como el DNS se cambió el último y con el TTL bajo, volver es apuntar de nuevo al servidor viejo, que ha seguido ahí todo el rato, encendido y con su dato intacto.

Merece la pena decidir de antemano qué señales disparan esa vuelta: errores que antes no aparecían, cifras que no cuadran, correo que deja de salir. Con el criterio pactado antes, en caliente no se discute; se ejecuta. Y como en el viejo no se borró nada, retroceder no cuesta datos, solo tiempo.

Después del cambio: no apagues el viejo todavía

Cambiar el DNS no cierra la migración; abre su última fase. Durante unos días conviene mirar los registros del servidor nuevo con más atención de la normal: los errores que solo salen con tráfico real, las tareas programadas la primera vez que les toca, el correo, los picos de las horas punta.

El servidor viejo se mantiene encendido un tiempo prudencial —días o semanas, según el caso— como red de seguridad. Solo cuando los registros confirman que ya no le llega absolutamente nada, y el nuevo lleva un ciclo completo comportándose bien, se apaga. Y antes de que se apague del todo, una última copia de seguridad completa guardada aparte: el día que la necesites, la agradecerás; el día que no, no costó nada tenerla.