Migrar una aplicación entre VPS sin perder datos: plan y rollback

Publicado el 2026-11-14 por frfrand

Inventario, transferencia, sincronización, DNS y recuperación segura ante incidentes.

Una migración fallida suele ser un problema de estado

Copiar el código a otro VPS resulta sencillo comparado con trasladar bases de datos, archivos subidos, colas, correos y tareas programadas sin perder escrituras. La primera decisión es cuánto tiempo de mantenimiento acepta el negocio y qué pérdida de datos sería tolerable. Define un RPO y un RTO realistas antes de tocar DNS.

Inventario antes de cambiar nada

Anota dominios, registros DNS, versión de runtime, variables privadas, puertos, servicios systemd o contenedores, certificados TLS, jobs, dependencias externas, almacenamiento y volumen de datos. Localiza rutas de uploads y los servicios que escriben fuera de la base: backups y exportaciones incompletos son una causa frecuente de pérdida.

Preparar el destino

Instala y configura el nuevo servidor con usuarios no privilegiados, firewall, SSH endurecido, monitorización, proxy, runtimes y dependencias compatibles. Copia los artefactos inmutables del código desde un commit conocido. Antes de cambiar tráfico, comprueba los servicios localmente con dominios de prueba o resolución controlada, sin interferir con el dominio público.

Base de datos: elige un método según tamaño y ventana

Para bases pequeñas, un respaldo lógico consistente y una restauración ensayada pueden ser suficientes si suspendes escrituras durante el corte. Para sistemas que no pueden detenerse, evalúa replicación o una estrategia de sincronización continua, comprobando compatibilidad de versiones y mecanismos del motor.

No des por hecho que pg_dump crea una réplica que continúa actualizándose: es una instantánea lógica. Verifica extensiones, roles, propietarios, secuencias, trabajos externos y permisos tras la restauración. Un backup solo es útil si puedes restaurarlo y validar los datos.

Archivos y tareas en segundo plano

Sincroniza uploads mediante mecanismos que preserven permisos y permitan repetir copias. Una segunda sincronización tras detener las escrituras ayuda a capturar los cambios finales. Congela cron y workers en un lado para evitar facturación doble, correos duplicados o ejecución concurrente de procesos no idempotentes.

Corte y DNS

Reduce el TTL con antelación cuando controles la zona, pero recuerda que algunos resolvers y clientes pueden retener registros. Mantén el servidor anterior disponible durante la transición según tu plan. Valida TLS, webhooks, redirecciones, envío de email, DNS y flujos críticos desde el exterior. No interpretes que el primer curl exitoso representa a todos los usuarios.

Rollback que protege la información

Antes del corte, establece quién decide volver atrás, con qué señales y cómo se tratarán las nuevas escrituras realizadas en el destino. Reapuntar DNS sin reconciliar datos puede perder reservas o pedidos nuevos. En incidentes complejos, detener temporalmente operaciones puede ser más seguro que forzar un retorno.

Después de migrar

Monitoriza errores, latencia, colas, envíos, almacenamiento y consistencia. Mantén el origen accesible pero protegido durante la ventana acordada. Solo cancélalo después de validar las copias y el funcionamiento.

Más contexto en migración Docker desde Coolify y despliegue Next.js en VPS. Los VPS y despliegues desde GitHub de ArduMaker pueden participar en la transición, pero el plan de datos y rollback depende de cada aplicación.

Preguntas frecuentes

### ¿Bajar el TTL garantiza migración instantánea? No: reduce parte del tiempo de caché, pero no controla todos los clientes. ### ¿Qué datos se olvidan más? Uploads, colas, tareas, secretos, webhooks y configuración de correo. ### ¿Puedo migrar sin downtime? A veces, con replicación y sincronización cuidadosamente diseñadas; no es una propiedad automática.