Tutoriales de VPS
Guía de migración de VPS (2026): cómo reducir el tiempo de inactividad al cambiar de proveedor o de centro de datos
Muchas personas cambian de VPS no porque la máquina anterior sea completamente inutilizable, sino porque subió el precio, la ruta de red se volvió inestable, el negocio creció o simplemente quieren pasar de un centro de datos peor a uno más cómodo. Lo que realmente da dolores de cabeza no es "migrar o no migrar", sino el miedo a que una migración signifique medio día de inactividad, pérdida de datos, DNS roto y certificados SSL caducados. Este artículo te ofrece un orden de migración más estable: primero inventariar los activos, luego hacer una validación con dos máquinas, después cambiar el tráfico y, por último, dar de baja la máquina antigua.
Cuando se habla de migración de VPS, lo primero que se le viene a la cabeza a mucha gente es:
- ¿Habrá mucho tiempo de inactividad?
- ¿Se corromperá la base de datos?
- Después de cambiar el DNS, ¿la mitad de los visitantes verá el sitio nuevo y la otra mitad seguirá en el antiguo?
- Si algo sale mal, ¿habrá que rehacer todo el sitio?
Por eso muchas máquinas que deberían migrarse se van posponiendo indefinidamente.
La máquina es más cara, la ruta de red es peor, el rendimiento ya no es suficiente e incluso el proveedor ha empezado a descuidarse, pero se sigue aguantando.
Pero la realidad es:
- La mayoría de las migraciones de VPS fallan no porque la migración en sí sea demasiado difícil, sino porque el orden es incorrecto.
Este artículo no da discursos vacíos del tipo "primero haz copia de seguridad, luego migra y al final prueba". Voy a desglosar directamente un proceso más práctico:
- En qué casos conviene migrar
- Qué hay que inventariar exactamente antes de migrar
- Cómo reducir el tiempo de inactividad al mínimo
- Dónde es más fácil meterse en problemas uno mismo
Si vas a cambiar de proveedor, de centro de datos o incluso solo a mover el negocio de una máquina antigua a una nueva, este proceso se puede aplicar directamente.
1) Primero la conclusión: el núcleo de una migración con poco tiempo de inactividad no es "copiar archivos", sino "hacer que el nuevo entorno funcione primero"
Mucha gente entiende la migración como una sola cosa:
- Mover los archivos de la máquina antigua a la nueva
Eso es solo la capa más superficial.
Lo que realmente determina si la migración va bien es esto:
- Antes de cambiar formalmente el tráfico, ¿la nueva máquina ya puede funcionar de forma independiente?
Es decir, la clave de una migración con poco tiempo de inactividad no es:
- Detener el sitio mientras se arregla todo poco a poco
Sino:
- Preparar primero la nueva máquina
- Sincronizar de antemano la mayor parte del contenido
- Hacer solo un breve cambio incremental en la ventana final
La diferencia entre estos dos enfoques es enorme.
El primero suele convertirse en:
- Inactividad
- Copia
- Corrección de errores
- Ajuste de configuración
- Volver a poner en línea
El segundo se parece más a:
- Montar la nueva máquina con antelación
- Sincronizar los datos primero
- Validar el negocio con antelación
- Cambiar al final el DNS / proxy inverso / punto de entrada del tráfico
Si solo vas a recordar una cosa, recuerda esta:
- Primero deja el nuevo entorno en un estado en el que pueda recibir tráfico, y luego habla de la migración.
Muchos administradores de sitios migran su VPS demasiado tarde.
Normalmente siguen retrasándolo incluso cuando ya han aparecido estas situaciones:
- La renovación sube de forma desorbitada
- La ruta de red del centro de datos empeora cada vez más
- Las versiones del panel, del sistema y de la base de datos son demasiado antiguas y no se atreven a actualizarlas
- El disco, la memoria y la CPU ya están al límite
- El soporte del proveedor responde muy lento
En ese momento, seguir retrasando suele ser más arriesgado que la propia migración.
Varias señales que hacen que valga la pena iniciar la migración:
Por ejemplo:
- Compra inicial barata, renovación al doble
- Planes antiguos caros pero con rendimiento inferior
- El ancho de banda y el tráfico no valen en absoluto el precio actual
Por ejemplo:
- Antes se servía tráfico internacional y ahora hay más usuarios de China continental
- Antes estaba en Estados Unidos y ahora el negocio está principalmente en Asia
- En las horas punta de la noche empiezan a aparecer fluctuaciones o pérdidas de paquetes prolongadas
Por ejemplo:
- Una sola máquina ya no aguanta
- Poner la base de datos y la aplicación juntas es demasiado peligroso
- Quieres adoptar almacenamiento de objetos, CDN o despliegue por capas
En una frase:
- Migrar no es una señal de fracaso; en muchos casos es una acción normal a medida que el negocio madura.
Este es el paso que creo que más se omite pero que en realidad es el más importante.
Mucha gente, en cuanto se menciona la migración, empieza de inmediato con rsync, scp, empaquetado y exportación de bases de datos.
Pero si ni siquiera has inventariado claramente qué hay en la máquina antigua, más adelante es fácil que ocurran accidentes como estos:
- Se migraron los archivos del sitio, pero no las tareas programadas
- Se migró Nginx, pero no los servicios systemd
- Se migró la base de datos, pero se olvidó el directorio de subidas
- Se migraron los certificados SSL, pero no el script de renovación automática
- Se migraron los sitios del panel, pero no las reglas del firewall ni la configuración de fail2ban
Así que antes de empezar formalmente, haz primero una lista.
- Directorios de código del sitio
- Directorios de archivos subidos
- Bases de datos
- Configuración de Nginx / Apache
- Entornos de ejecución PHP / Node / Python
- Servicios systemd
- Tareas cron
- Certificados SSL y métodos de renovación automática
- Reglas de firewall y seguridad
- Dependencias externas (almacenamiento de objetos, SMTP, API de terceros)
Si tienes WordPress o un sitio de blog, este paso es especialmente fácil de omitir:
wp-content/uploads.env- Directorios de caché
- Tareas programadas
- Diferencias de juego de caracteres y versión de la base de datos
Inventariar los activos antes de migrar no suena a "acción técnica", pero es el requisito previo para todo lo que viene después.
4) El enfoque de migración más estable: una sincronización completa y luego una sincronización incremental antes de cambiar el tráfico
Este es el método más común y más estable.
Puedes entenderlo como mudarse dos veces:
El objetivo es:
- Trasladar primero la mayor parte de los datos estáticos y el entorno base a la nueva máquina
Por ejemplo:
rsync -avz --delete /var/www/ root@new-vps:/var/www/
Para la base de datos, primero puedes exportar una versión de prueba de los datos:
mysqldump -u root -p --single-transaction app_db > app_db.sql
scp app_db.sql root@new-vps:/root/
Después de este paso, tu nueva máquina ya debería poder:
- Iniciar servicios
- Abrir el sitio de prueba
- Ejecutar páginas básicas
- Verificar el entorno de ejecución
La verdadera ventana de inactividad suele reservarse para este paso.
La idea es:
- Detener brevemente las escrituras o entrar en modo de mantenimiento
- Sincronizar los últimos archivos modificados y la base de datos
- Cambiar el punto de entrada
- Verificar el sitio nuevo
¿Por qué esto reduce el tiempo de inactividad?
Porque la gran mayoría del traslado de datos ya se ha hecho de antemano.
En la ventana final solo queda:
- El último pequeño lote de datos modificados
- El cambio de configuración
- El cambio de DNS / proxy inverso / entrada
Muchas migraciones parecen "no cambiar", pero el problema no está en el servidor, sino en la caché DNS.
Si planeas cambiar al nuevo servidor mediante el nombre de dominio, es mejor hacer una cosa con antelación:
- Bajar con antelación el TTL de los registros DNS
Por ejemplo, 24 horas antes o más, bajar el TTL de valores como 3600/7200 a un valor más bajo.
Así, cuando se produzca el cambio real:
- Las cachés antiguas caducan más rápido
- La nueva IP entra en vigor más rápido
- La ventana de observación es más corta
De lo contrario, lo más habitual es que:
- Crees que ya se ha cambiado
- Resulta que una parte de los usuarios sigue en la máquina antigua
- Una parte del tráfico ya ha llegado a la nueva máquina
- Los datos empiezan a mostrar confusión por doble escritura
Para los sitios con escrituras en base de datos, esta situación es especialmente peligrosa.
Por eso, para sitios dinámicos, la forma realmente segura de cambiar el tráfico no suele ser "apostar directamente a que el DNS cambie al instante", sino combinar:
- Modo de mantenimiento
- Detención breve de escrituras
- Una última sincronización incremental
- Y luego cambiar el tráfico
Muchos sitios fallan no porque falten archivos, sino porque:
- La versión de la extensión PHP no es la correcta
- La versión de Node no es la correcta
- La versión de la base de datos es incompatible
- Falta la configuración de systemd
Este tipo de problema es el más oculto.
La página de inicio abre, pero:
- No se envían correos
- No se ejecutan las copias de seguridad
- No se consumen las colas
- Los scripts programados están rotos
Mucha gente copia el directorio de certificados y cree que ya está.
Pero lo que realmente hay que confirmar es:
- Cuál es el método de renovación
- Si la tarea programada sigue existiendo
- Si han cambiado el webroot / las reglas del proxy inverso
Los lugares donde más fácilmente surgen problemas normalmente no son la página de inicio, sino:
- El inicio de sesión
- El envío de formularios
- La subida de archivos
- Las devoluciones de pago
- El guardado en el panel
En cuanto cambia la IP del nuevo servidor, muchas integraciones de terceros tendrán problemas:
- SMTP
- Interfaces de pago
- Origen del CDN
- Listas blancas del almacenamiento de objetos
- Listas blancas del firewall
El enfoque más estable normalmente no es borrar la máquina antigua en cuanto todo termina, sino:
- Mantener la máquina antigua durante un periodo de observación
Aunque solo sea durante 2-7 días, también puede salvar muchas reversiones posteriores.
Si necesitas migrar ahora mismo, te recomiendo seguir esta checklist.
- Inventariar los activos
- Hacer recuento de los servicios
- Registrar la configuración de DNS / SSL / cron / firewall
- Bajar el TTL con antelación
- Preparar el entorno de la nueva máquina
- Instalar el entorno de ejecución
- Crear los directorios del sitio
- Restaurar una versión completa de los datos
- Configurar Nginx / Apache / base de datos / servicios
- Verificar el acceso con un dominio temporal o hosts
- Probar la página de inicio
- Probar el panel
- Probar formularios/escrituras
- Probar subidas
- Probar tareas programadas
- Probar HTTPS
- Activar el modo de mantenimiento o pausar las escrituras
- Hacer la última sincronización incremental de base de datos y archivos
- Cambiar DNS / proxy inverso / entrada
- Observar los registros y los accesos
- Mantener la máquina antigua
- Observar durante 24-72 horas
- Vigilar especialmente los registros de errores, las conexiones a la base de datos, el SSL, las devoluciones de llamada y las subidas
Este proceso parece tener muchos pasos, pero la verdadera clave para ahorrar tiempo de inactividad es precisamente:
- Hacer el trabajo complejo con antelación; el día del cambio, hacer solo el último paso.
Este tipo de usuarios es el que más fácilmente cree que "el panel tiene importación/exportación" y con eso basta.
En la práctica hay que mirar varias cosas más:
- WordPress: directorio de subidas, base de datos, enlaces permanentes, caché, SMTP, tareas programadas
- BaoTa / aaPanel: configuración del sitio, versión de PHP, usuarios de base de datos, método de renovación de SSL, reglas de seguridad
- Aplicaciones Docker:
docker-compose.yml, variables de entorno, montajes de volúmenes, configuración del proxy inverso
Es decir:
- Lo que se migra no es "que el sitio parezca que abre"
- Sino que "todo el estado de ejecución tiene que irse con él"
Si más adelante quieres separar la arquitectura de una sola máquina, también puedes leer este artículo:
Mucha gente solo mira una cosa después de migrar:
- Si el sitio web abre
Eso está muy lejos de ser suficiente.
Como mínimo también debes vigilar:
- Si los registros de errores se han disparado
- Si las conexiones a la base de datos son anómalas
- Si las escrituras en el panel son normales
- Si las subidas y descargas son normales
- Si han fallado las devoluciones de llamada externas
- Si se han perdido correos y notificaciones
Si no tienes monitorización, los problemas posteriores a la migración pueden tardar hasta el día siguiente o incluso varios días en salir a la luz.
Así que después de migrar, como mínimo añade:
- Revisión de registros
- Observación del uso de recursos
- Regresión manual de las rutas críticas
Si aún no has montado la monitorización, echa un vistazo a esto:
10) Última frase: el verdadero secreto para reducir el tiempo de inactividad no son trucos técnicos, sino reducir la ventana de cambio al mínimo
Mucha gente cree que la "migración con poco tiempo de inactividad" requiere tecnología especialmente avanzada.
En realidad, en la mayoría de los escenarios solo hay tres cosas realmente eficaces:
- Montar el nuevo entorno con antelación
- Sincronizar de antemano la gran mayoría de los datos
- En el cambio formal del tráfico, hacer solo el último tramo incremental y el cambio de entrada
Cuanto más acumules trabajo para el día del cambio, más fácil será que algo falle.
Cuanto más adelantes la preparación, más se parecerá el día de la migración a un cambio de ventana corta en lugar de una gran operación quirúrgica.
Así que si estás pensando en cambiar de proveedor o de centro de datos, no preguntes primero:
- ¿Debería migrar?
Pregúntate primero estas tres cosas:
- ¿Puede el nuevo entorno funcionar de forma independiente primero?
- ¿Cuánto tardará mi última sincronización incremental?
- ¿He tenido en cuenta mi DNS / escrituras / SSL / dependencias externas?
Una vez que tengas claras estas tres cosas, la migración de VPS ya no parecerá una operación a vida o muerte.