Checklist antes de migrar una aplicación a otro servidor
Una migración fiable empieza con un inventario de procesos, datos, DNS y dependencias. Esta lista ayuda a preparar pruebas, corte y rollback.
Antes de copiar archivos hay que saber qué mantiene viva la aplicación. El inventario debe cubrir código, procesos, datos, tareas, dominios y servicios externos. Sin él, una portada funcional puede ocultar workers detenidos, archivos ausentes o integraciones que siguen llamando al servidor anterior.
1. Inventario de aplicación y procesos
Registra repositorio y versión desplegada, runtime, dependencias, variables de entorno, puertos, comandos de inicio, proxy web y procesos en segundo plano. Incluye cron, colas, webhooks y scripts ejecutados fuera del flujo HTTP. También conviene identificar qué componentes reinician automáticamente y cuáles dependen de una intervención manual.
2. Datos y almacenamiento persistente
Lista bases de datos, usuarios, extensiones, volúmenes, archivos subidos y rutas que la aplicación escribe. Comprueba el tamaño y el tiempo real de backup y restore. Tener una copia no basta: debe poder restaurarse en el destino y conservar permisos, encoding e integridad.
3. Dependencias externas
Documenta correo, almacenamiento, APIs, pasarelas, DNS, firewall y listas de IP autorizadas. Un cambio de IP puede afectar callbacks o accesos que no forman parte del código. Guarda los contactos y procedimientos necesarios para actualizar cada dependencia.
4. Pruebas antes del cambio
Levanta una copia en el destino y prueba escenarios representativos: login, formularios, operaciones de escritura, archivos, emails, tareas y conexiones externas. Para probar con el dominio real sin cambiar el DNS pueden utilizarse resoluciones locales controladas, siempre evitando ejecutar acciones duplicadas sobre servicios de producción.
5. Ventana, DNS y rollback
Define quién congela escrituras, cuándo se realiza la copia final y qué evidencia autoriza el cambio. Ajustar el TTL con antelación puede ayudar, pero no sustituye el plan de retorno. El origen debe conservarse intacto durante un periodo acordado y el rollback debe indicar cómo tratar datos creados después del corte.
6. Observación posterior
Después del cambio revisa estados HTTP, certificados, logs, colas, cron, correo y métricas del servidor. La migración termina cuando los flujos críticos se han verificado y la operación sabe dónde consultar el estado, no cuando el DNS empieza a resolver.