Mudar tu VPS a un nuevo proveedor sin cortes

Todas las historias de terror de migraciones tienen el mismo nudo: alguien cambió primero el DNS y luego empezó a copiar. Los cortes durante una mudanza casi nunca se deben a que la copia vaya lenta. Se deben a hacer los pasos en el orden equivocado.

Este es el orden que funciona, tanto si dejas otro proveedor como si pasas de una de nuestras tarifas a otra.

1. Dos días antes: baja el TTL

Localiza los registros DNS que vas a cambiar (normalmente A, AAAA y cualquier CNAME que apunte a ellos) y baja su TTL a 300 segundos. Después espera al menos lo que duraba el TTL antiguo. Un registro con un TTL de un día significa que algunos resolvedores seguirán sirviendo la dirección vieja durante un día después del cambio, y nada de lo que hagas en el servidor lo acelera.

Este es el paso que la gente se salta, y es el que convierte un cambio de cinco minutos en un día en el que la mitad de los usuarios ven el servidor viejo.

2. Haz inventario del servidor viejo

Vas a reconstruir esta máquina en otro sitio, así que apunta lo que hace de verdad. No lo que recuerdas que hace. Lo que hace:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Añade a la lista: los certificados TLS y cómo se renuevan, los archivos de entorno con secretos, las reglas del cortafuegos, los usuarios y sus claves SSH, la base de datos y su tamaño, y todo lo que se comunica con el servidor por su dirección IP. Ese último grupo es el traicionero: la lista de permitidos de un socio, la configuración de webhooks de un proveedor de pagos, una comprobación de monitorización.

3. Monta el servidor nuevo junto al viejo

Contrata el servidor nuevo y deja el viejo en paz. Elige una tarifa de la lista de VPS con igual o más disco del que usas de verdad, no del que te vendieron. Si la máquina vieja recibe cualquier tráfico entrante (una web, webhooks, una API), la nueva necesita su propia IPv4. Una tarifa NAT solo acepta conexiones entrantes en su puerto SSH, y lo que un solo puerto redirigido puede y no puede hacer explica por qué importa.

Conéctate, instala los mismos paquetes, vuelve a crear los usuarios y el cortafuegos. La guía de conexión cubre las claves y el primer acceso.

4. Sincroniza los archivos dos veces

La primera sincronización copia todo mientras el servidor viejo sigue funcionando. Puede durar horas; no pasa nada.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids conserva los propietarios de los archivos por número, lo que evita la sorpresa clásica de «todo pertenece al usuario equivocado» cuando los dos sistemas crearon los usuarios en distinto orden. Si nunca has usado rsync por SSH, cómo transferir archivos a un VPS te lo explica paso a paso.

La segunda sincronización, justo antes del cambio, copia solo lo que ha cambiado desde la primera. Suele durar segundos.

5. Mueve la base de datos con cabeza

Los archivos son fáciles. Una base de datos que recibe escrituras es la única parte en la que «sin cortes» exige un pequeño compromiso o más trabajo.

El camino sencillo: hacer un volcado y restaurarlo una vez para probar, y en el momento del cambio detener las escrituras un minuto (poner la aplicación en solo lectura o pararla), hacer un volcado nuevo, restaurarlo en el servidor nuevo y arrancar allí la aplicación. Para la mayoría de los proyectos pequeños es una pausa de uno o dos minutos, avisada con antelación.

El camino sin pausa: configurar replicación de la base vieja a la nueva, dejar que se ponga al día y promover la nueva en el momento del cambio. Más preparación, y merece la pena cuando ni siquiera un minuto de escrituras perdidas es aceptable.

6. Prueba el servidor nuevo antes de que nadie más lo vea

El DNS sigue apuntando al servidor viejo, así que puedes probar el nuevo en privado. Envía una petición de tu dominio real a la dirección nueva:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Si el certificado aún no está, prueba igual por HTTP, o añade una línea temporal a tu archivo hosts y recorre la web en el navegador. Comprueba los inicios de sesión, las subidas, las tareas en segundo plano y el correo saliente. Es el momento más barato para descubrir que falta una extensión de PHP.

7. Cambia, y deja el servidor viejo encendido

Haz la sincronización final de archivos y el paso de la base de datos, y después cambia los registros DNS. Con un TTL de 300 segundos, la mayor parte del tráfico se mueve en minutos. Vigila el log de acceso del servidor viejo: seguirá recibiendo un goteo de peticiones de resolvedores y clientes que ignoran el TTL. Déjalo encendido, sin cambios, unos días. Luego actualiza todo lo que apunte a la IP vieja: listas de permitidos de socios, URL de webhooks y, para el correo, el DNS inverso de la dirección nueva (en nuestras tarifas con IP dedicada lo configuras tú, ver DNS inverso) y tu registro SPF.

Lo que más se rompe

Más o menos por orden de frecuencia con que lo vemos: un temporizador de systemd que nadie apuntó, un archivo de configuración con la IP vieja escrita a mano, archivos que pertenecen al usuario equivocado, un cortafuegos que bloquea el propio puerto de la aplicación, un certificado que se renueva en el servidor viejo pero no en el nuevo, y correo que acaba en spam porque la dirección nueva aún no tiene DNS inverso.

Dónde no encaja esta checklist

Una base de datos con muchas escrituras constantes y cero tolerancia a pausas necesita replicación de verdad y un ensayo, no una checklist de blog. Los servidores Windows se mudan con herramientas distintas de rsync. Y si la mudanza va en realidad de tamaño, lee esto primero: aquí las tarifas crecen en el sitio. Pasar a una tarifa mayor del mismo tipo de red añade vCPU, RAM y disco con un reinicio, sin ninguna migración. Solo para reducir hace falta un servidor nuevo. Si te mudas porque no tienes claro que la máquina dé para más, cuándo necesitas de verdad 64 GB de RAM puede ahorrarte el viaje, y VPS, hosting compartido, servidor dedicado o nube te ayuda si dudas de que un VPS sea el sitio adecuado.