La gente imagina una migración como un único momento dramático en el que desconectan algo de un lado y conectan otra cosa del otro, y cruzan los dedos. No tiene por qué sentirse así. Una mudanza transcurre sin problemas cuando el nuevo servidor está completamente listo y probado antes de tocar cualquier cosa de la que dependan los usuarios, y cuando el DNS se ha preparado para que el cambio se propague en segundos en lugar de horas. La conmutación en sí se convierte entonces en unos minutos de trabajo cuidadoso en vez de una caída del servicio.
Esta guía recorre la mudanza de una aplicación web típica a un VDS de Cybeward en Santiago. El mismo plan aplica tanto si vienes de otro proveedor como de otro centro de datos.
Antes de empezar, anota exactamente qué está corriendo en el servidor antiguo: servicios, puertos abiertos, tareas cron, certificados TLS y dónde residen los datos. Una migración es tan limpia como lo sea tu inventario de lo que estás migrando.
1. Aprovisiona el VDS de destino con recursos equivalentes
Contrata un servidor en Santiago que iguale o supere al de origen: la misma clase de CPU y RAM, al menos tanto disco, y la misma versión mayor del sistema operativo. Igualar la versión del sistema operativo importa más de lo que la gente espera — pasar de Debian 11 a Debian 12 a mitad de la migración añade variables que no quieres mientras además estás moviendo datos.
Anota la IP pública del nuevo servidor. Mantendrás ambas máquinas funcionando en paralelo durante todo el proceso, así que no hay prisa ni riesgo para el sitio en producción todavía.
2. Prepara y endurece el nuevo servidor
Antes de que cualquier dato de la aplicación llegue a él, lleva la nueva máquina a una base sensata: claves SSH en lugar de contraseñas, un usuario sudo distinto de root, un firewall que permita solo lo que necesitas, y actualizaciones de seguridad automáticas. Lo cubrimos en detalle en nuestra checklist de seguridad de los primeros 15 minutos — haz esa pasada ahora, mientras el servidor está vacío y un error no cuesta nada.
Luego instala el entorno de ejecución que tu aplicación necesita (servidor web, runtime del lenguaje, motor de base de datos) en las mismas versiones mayores que el origen. No importes datos todavía. El objetivo aquí es un entorno limpio, asegurado y correctamente configurado a la espera de recibir contenido.
3. Sincronización inicial de datos mientras el servidor antiguo sigue en línea
Con ambos servidores funcionando, copia los datos con rsync. Como el origen sigue atendiendo tráfico, esta primera pasada puede tardar lo que haga falta — nadie está esperándola.
# trae los archivos de la aplicación desde el servidor antiguo $ rsync -aHAX --info=progress2 \ root@203.0.113.10:/var/www/ /var/www/ # trae las subidas / contenido de usuario $ rsync -aHAX --info=progress2 \ root@203.0.113.10:/srv/data/ /srv/data/
Para las bases de datos, toma un volcado consistente en el origen y restáuralo en el destino para que el motor reconstruya correctamente sus propios archivos:
# en el servidor ANTIGUO: volcado consistente $ mysqldump --single-transaction --routines --triggers \ appdb | gzip > /tmp/appdb.sql.gz # en el servidor NUEVO: impórtalo $ gunzip < appdb.sql.gz | mysql appdb
Ahora levanta la aplicación en el nuevo servidor y pruébala directamente por IP (o con un nombre de host temporal). Recorre flujos reales: inicia sesión, envía un formulario, sube un archivo. Corrige los problemas de configuración aquí, donde no hay consecuencias.
La migración se gana o se pierde en el ensayo, no en la conmutación. Si la aplicación funciona perfectamente por IP en la nueva máquina, el cambio es pura tramitación.
4. Baja el TTL de tu DNS un día antes
Este es el paso que convierte una ventana de caída de varias horas en un par de minutos, y es el que la mayoría de la gente se salta. Tus registros DNS tienen un TTL — cuánto tiempo los resolutores los mantienen en caché. Si está fijado en 3600 o más, los visitantes pueden seguir llegando a la IP antigua durante una hora después de que la cambies.
Al menos un día completo antes de la conmutación, baja el TTL de los registros que vas a cambiar:
; antes: app.example.com. 3600 IN A 203.0.113.10 app.example.com. 300 IN A 203.0.113.10
Un TTL de 300 segundos significa que, una vez cambies el registro, el mundo se pone al día en cinco minutos. Configúralo con un día de anticipación para que toda copia en caché del TTL antiguo y más largo haya expirado al momento de la conmutación.
Nota. Bajar el TTL es inofensivo y reversible — pero solo surte efecto después de que el TTL antiguo haya envejecido en las cachés. Hazlo con tiempo. Vuelve a subirlo a un valor normal uno o dos días después de confirmar que la migración es estable.
5. La conmutación: pausa breve, sincronización final del delta, cambio de DNS
Ahora la única ventana corta de todo el plan. Pon la aplicación antigua en un breve estado de mantenimiento para que no ocurran nuevas escrituras, y luego ejecuta un rsync final — solo copia lo que cambió desde la primera pasada, así que termina rápido:
# en el nuevo servidor: captura los últimos cambios $ rsync -aHAX --delete --info=progress2 \ root@203.0.113.10:/var/www/ /var/www/ $ rsync -aHAX --delete --info=progress2 \ root@203.0.113.10:/srv/data/ /srv/data/
Vuelve a ejecutar el volcado e importación de la base de datos para el delta final, inicia la aplicación en el nuevo servidor y luego cambia el registro A a la IP de Santiago. Como el TTL ya es 300, la propagación es casi inmediata.
6. Verifica antes de celebrar
Confirma que el mundo realmente está viendo el nuevo servidor, y no tu caché local:
# ¿a qué IP está resolviendo el registro ahora? $ dig +short app.example.com @1.1.1.1 # ¿está sana la aplicación sobre HTTPS de extremo a extremo? $ curl -sS -o /dev/null -w "%{http_code}\n" https://app.example.com/health # observa los logs del nuevo servidor con tráfico en vivo $ tail -f /var/log/nginx/access.log
Observa cómo llegan peticiones reales en los logs del nuevo servidor, comprueba que los logs de error están en silencio, y recorre los mismos flujos que ensayaste en el paso 3. Levanta el estado de mantenimiento solo una vez que hayas confirmado que el tráfico está llegando correctamente.
7. Mantén el servidor antiguo como plan de reversión
No desmanteles el origen de inmediato. Déjalo funcionando, sin tocarlo, durante unos días. Si surge algo sutil, puedes apuntar el DNS de vuelta en cinco minutos — precisamente porque bajaste el TTL. Una vez que hayas pasado unos días con logs limpios y sin sorpresas, vuelve a subir el TTL a la normalidad y retira la máquina antigua.
Si algo de esto te genera dudas para tu stack en particular, habla con el soporte de Cybeward antes de empezar. Hacemos migraciones cada semana y podemos asesorarte sobre la secuencia más segura para tu caso — y durante la conmutación hay una persona al otro lado de la línea, no una cola de tickets.
- Nuevo VDS en Santiago aprovisionado con CPU, RAM, disco y versión del sistema operativo equivalentes
- Nuevo servidor endurecido y entornos de ejecución instalados antes de que llegue cualquier dato
rsyncinicial e importación de la base de datos hechos mientras el servidor antiguo sigue en línea- Aplicación probada directamente por IP en el nuevo servidor — flujos reales de inicio de sesión, subida y formularios
- TTL del DNS bajado a
300al menos un día antes de la conmutación - Pausa de mantenimiento,
rsyncfinal del delta, y luego registro A cambiado a la nueva IP - Verificado con
dig,curly logs en vivo que el tráfico llega a Santiago - Servidor antiguo mantenido sin tocar como plan de reversión durante unos días, y luego TTL subido de nuevo
