La mayoría de las migraciones no fallan durante la copia. Fallan en los veinte minutos posteriores al cambio de DNS, cuando media internet todavía habla con el servidor antiguo y la otra mitad ya ha pasado al nuevo — y las dos máquinas aceptan escrituras. Los archivos llegan intactos, el sitio carga, y sin embargo los pedidos aterrizan en dos bases de datos que nunca se van a reconciliar. Evitar esto tiene poco que ver con la velocidad de transferencia y casi todo que ver con la secuencia: qué cambias primero, qué congelas, y qué mantienes en marcha hasta estar seguro.
Qué significa realmente no tener caídas
Merece la pena ser precisos, porque la frase cubre dos promesas muy distintas y cuestan cantidades de esfuerzo muy distintas. Decidir cuál de las dos estás comprando es la primera decisión real de la migración.
Si tienes que sacrificar una de las dos, sacrifica la disponibilidad. Una página de mantenimiento durante cuatro minutos es algo que puedes explicar. Unos datos divergentes son algo que no puedes arreglar, porque ya no queda ninguna autoridad que diga qué copia era la correcta.
Antes de empezar, anota la congelación de escrituras más larga que puedes tolerar. Cuatro minutos, treinta segundos, cero. Ese único número decide todo lo que viene después — si basta con un volcado y una restauración, si necesitas replicación, o si necesitas un proxy delante de todo el conjunto. Elegir las herramientas antes que el número es la forma en que las migraciones acaban dándote sus sorpresas.
Haz el inventario antes de hacer la copia
Un servidor acumula cosas que nadie documentó: una tarea de cron añadida durante un incidente, una regla de firewall para la dirección de un socio, una clave de API pegada en un archivo de servicio. La copia no las va a arrastrar, y las irás encontrando una a una durante la quincena siguiente. Media hora de inventario ahora elimina casi todo eso.
Qué escucha
Ejecuta ss -tulpn y da cuenta de cada socket a la escucha. Cada uno es un servicio que debe existir en la máquina nueva, y cada puerto sin explicación merece entenderse antes de replicarlo — una migración es un buen momento para darte cuenta de qué lleva funcionando desde 2023.
Qué se ejecuta con un temporizador
crontab -l para cada usuario, incluido root, systemctl list-timers, y cualquier planificador dentro de la propia aplicación. Los temporizadores son lo que con más frecuencia sobrevive a una migración por duplicado, y los duplicados son peores que las ausencias.
Qué no está en el disco
Los registros DNS, el DNS inverso de tu dirección, las reglas de firewall, las claves de API en manos de terceros, los destinos de los webhooks, y cualquier lista de permitidos en otro sitio que nombre tu IP actual. Nada de esto vive en el sistema de archivos que estás a punto de copiar.
Qué da por hecho la aplicación
Rutas absolutas escritas a fuego, un nombre de host en un archivo de configuración, la ubicación de un socket de base de datos, una dirección en una directiva bind. Estas son las cosas que fallan en silencio — el servicio arranca, y luego no funciona.
Escríbelo en un archivo que mantengas en control de versiones, no en el historial de una terminal. Lo vas a leer tres veces durante el corte, una de ellas en un momento en el que no vas a estar pensando con claridad.
Elige el destino según lo que ya no podrás cambiar después
Las especificaciones son ajustables; unas pocas propiedades no lo son, y esas merecen decidirse de forma deliberada mientras todavía tienes libertad de elección. Ya que vas a mudarte de todos modos, este es el momento más barato que vas a tener nunca para arreglar una limitación con la que llevas lidiando.
- Ubicación, porque de ella dependen tanto la latencia hacia tus usuarios como la legislación aplicable. /locations enumera las regiones y sus características de ida y vuelta; elige una que falle de forma independiente a la que estás dejando.
- Base legal, si el motivo del traslado es que tu proveedor actual reenvía las quejas más rápido de lo que reenvía los paquetes. /offshore-hosting explica qué controla realmente la jurisdicción y qué no.
- Identidad de facturación, porque un proveedor que exige documentos antes de aceptar un pago tiene, por construcción, un expediente sobre ti. /no-kyc-vps y /pay-with describen la alternativa — un saldo recargado en cripto, sin tarjeta, sin ningún nombre asociado a la máquina.
- Margen de crecimiento, porque migrar dos veces es el resultado que nadie planea. /vps enumera los planes, y /guides tiene el método de dimensionamiento si la máquina actual nunca se ha llegado a medir.
- IPv6 y una IPv4 limpia, ya que una dirección reciclada puede llegar cargando con la reputación de otro — compruébalo antes de que se convierta en un problema de correo.
Baja el TTL de DNS primero, días antes
Este es el único paso de preparación que no se puede dejar para el final con prisas, porque su efecto está condicionado por un reloj que no controlas. El TTL de tus registros indica a los resolvers cuánto tiempo guardar en caché una respuesta. Si está fijado en un día, un resolver que preguntó hace una hora seguirá enviando usuarios al servidor antiguo durante las próximas veintitrés horas, publiques lo que publiques.
- 1
Consulta el TTL actual
dig +noall +answer yourdomain.com muestra el tiempo de caché restante; consultar directamente a tu servidor de nombres autoritativo con dig @ns1.example.net yourdomain.com muestra el valor configurado. Anótalo — es lo que fija la duración de tu periodo de espera.
- 2
Bájalo a 300 segundos
Baja el TTL de cada registro que vaya a cambiar: A, AAAA, y cualquier MX o CNAME que apunte al servidor. Cinco minutos es lo bastante corto para que el corte sea cómodo y lo bastante largo para no machacar tus servidores de nombres.
- 3
Espera a que expire el TTL antiguo, y luego espera un poco más
El nuevo TTL corto solo llega a un resolver después de que expire el antiguo, más largo. Espera al menos un periodo completo del TTL antiguo — un día, si era un día — antes de dar por real el TTL bajo. Empezar esto pronto no cuesta nada y le da a todo el corte su margen.
Algunos resolvers ignoran tu TTL y cachean con su propio mínimo de todos modos, y una fracción de los clientes cachea durante toda la vida del proceso. Cuenta con una cola larga de tráfico llegando a la dirección antigua durante horas, incluso después de un cambio de manual. Eso no es una razón para saltarte el trabajo del TTL — es la razón por la que el servidor antiguo tiene que seguir vivo después.
Construye el servidor nuevo, no clones el antiguo
El instinto es crear una imagen del disco actual y restaurarla en otro sitio. Es el movimiento equivocado, por la misma razón que lo es en una restauración: un clon a nivel de bloque reproduce fielmente la deriva de configuración, los paquetes huérfanos, el servicio a medio configurar que alguien abandonó, y cualquier persistencia que haya dejado un intruso anterior. Además, te ata a la versión antigua de la distribución.
Construye la máquina nueva a partir de una imagen base actual, instala los servicios desde un script, y copia solo los datos. El script es el verdadero entregable — es lo que convierte la siguiente migración en una tarde en lugar de una quincena, y lo que te permite reconstruir después de un incidente sin hacer arqueología.
- Aprovisiona, actualiza y endurece la máquina antes de que nada más la toque: SSH solo con claves, un firewall que deniega por defecto, actualizaciones de seguridad desatendidas. /guides tiene la versión de una hora de esa checklist.
- Instala las mismas versiones mayores del runtime y de la base de datos que en producción. Una migración es un mal momento para además actualizar PostgreSQL de la 14 a la 17 — haz un cambio cada vez, para que un fallo tenga exactamente una explicación.
- Recrea usuarios y grupos con los mismos ID numéricos antes de copiar archivos, o arregla la propiedad a mano después. Transferir con --numeric-ids mantiene los números intactos; volver a mapearlos a los nombres correctos es trabajo tuyo.
- Añade la dirección nueva a cada lista de permitidos que hoy nombra la antigua — APIs de socios, firewalls de bases de datos gestionadas, pasarelas de pago, tu propia monitorización — mientras las dos siguen siendo válidas.
Instala los servicios, y luego detenlos y desactívalos. Un servidor web que arranca al iniciar y responde en la dirección nueva será encontrado por escáneres, indexado bajo el nombre de host equivocado y — peor aún — servirá encantado una copia a medio poblar de tu sitio a cualquiera que resuelva antes de tiempo. Nada en la máquina nueva debería responder públicamente hasta que tú decidas que lo haga.
Copia los archivos en dos pasadas
Una única transferencia de un sistema de archivos en marcha es una instantánea de un objetivo en movimiento. Dos pasadas lo resuelven con limpieza: la primera es larga y se ejecuta contra un sistema vivo, la segunda es corta y se ejecuta durante la congelación, y solo la segunda tiene que ser rápida.
Ejecuta la primera pasada cuando quieras — adelantarla varios días no tiene ningún problema. Se lleva el grueso: el directorio de subidas, la cola de correo, los volúmenes de contenedor, los años de contenido multimedia acumulado. Estará desactualizada para cuando hagas el corte, y para eso está exactamente la segunda pasada.
- Usa rsync -aAXH --numeric-ids --info=progress2 por SSH: -a para los atributos habituales, -A para las ACL, -X para los atributos extendidos, -H para los enlaces duros, que importan si algo en la máquina deduplica.
- Excluye lo que no debe viajar: /proc, /sys, /dev, /run, los directorios temporales, la caché de paquetes y los registros que no necesitas. Copiar interfaces del kernel malgasta tiempo en el mejor de los casos y cuelga la transferencia en el peor.
- Añade --delete solo en la segunda pasada. En la primera es inofensivo; en la segunda elimina archivos que se borraron en el origen desde entonces, que es precisamente la deriva que estás intentando eliminar.
- Copia la configuración del sistema de forma selectiva, no en bloque. Quieres los vhosts de tu servidor web, tus unidades de servicio y la configuración de tu aplicación — no la tabla de sistemas de archivos de la máquina antigua, ni su configuración de red, ni su ID de máquina.
- Genera una clave SSH desechable para la transferencia, autorízala en el destino, y elimínala cuando termine la migración. Una clave de migración que se queda dando vueltas durante dos años es una credencial que nadie recuerda haber emitido.
Entre pasadas, verifica en lugar de dar por hecho. Ejecutar la segunda pasada con --dry-run imprime exactamente lo que cambiaría: una lista de unos pocos cientos de archivos recientes es sana, y una lista de cuarenta mil significa que una exclusión está mal o que algo está reescribiendo las marcas de tiempo sin motivo.
Mueve la base de datos sin perder escrituras
Aquí es donde se gasta el presupuesto de congelación, y la técnica correcta depende por completo del número que anotaste al principio. Las tres opciones siguientes son correctas — para números distintos.
Elijas lo que elijas, la base de datos antigua debe dejar de aceptar escrituras antes de que empiece la nueva. No poco después — antes. El solape en el que las dos admiten escritura es la ventana de split-brain, y es el único fallo de toda esta guía sin una recuperación limpia: dos historiales divergentes y ninguna forma de fusionarlos que no implique leer filas a mano.
Vuelca el esquema y los datos por separado cuando el conjunto de datos es grande. Restaurar primero el esquema te permite verificar pronto la estructura, los índices y los permisos en el servidor nuevo, lo que convierte la carga de datos en una única operación larga que puedes iniciar durante la congelación ya con la confianza de que va a llegar a buen puerto.
Emite el certificado TLS antes del cambio, no después
El certificado del servidor nuevo tiene que ser válido en el instante en que llega el primer usuario. Descubrir lo contrario significa que cada visitante se encuentra con una pantalla intersticial del navegador, y si envías cabeceras HSTS — que deberías — no pueden saltársela. Hay dos formas de tener un certificado que funcione antes de que el DNS apunte a ningún sitio nuevo.
- Copia el existente. Todo el directorio de estado de ACME, o solo el certificado y la clave de donde sea que los guarde tu cliente. Es válido de inmediato, porque la validez no tiene nada que ver con qué servidor guarda el archivo, y la renovación se reanuda con normalidad en cuanto el DNS se ha movido.
- Emite uno nuevo con un desafío DNS-01, que demuestra el control del dominio mediante un registro TXT en lugar de una petición HTTP a la dirección actual. Eso funciona antes de la migración, antes del corte, y para wildcards, algo que HTTP-01 no puede hacer en absoluto.
- No intentes la validación HTTP-01 en el servidor nuevo antes del cambio. El desafío se obtiene por el puerto 80 en el nombre de dominio, el dominio todavía resuelve a la máquina antigua, y la validación falla siempre.
Verifícalo sin tocar el DNS resolviendo el nombre de host a la dirección nueva para un único comando: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — sustituyendo la dirección real. Esa línea es la comprobación de mayor valor de toda la migración. Ejercita el vhost real, el certificado real y la pila de aplicación real en la máquina nueva, y es como encuentras el error de configuración mientras encontrarlo todavía no cuesta nada.
Si el servidor envía correo, empieza antes
El correo es la parte de una migración que falla días después, en silencio, y se le echa la culpa a otra cosa. Una dirección nueva no tiene reputación de envío y puede haber heredado la de otro, y cada registro de autenticación que publicas está atado a la dirección que estás dejando.
- Comprueba la dirección nueva contra las listas de bloqueo principales antes de comprometerte con ella. Una IP reciclada con historial merece cambiarse mientras cambiarla todavía es gratis.
- Fija el registro DNS inverso de la dirección nueva a tu nombre de host de correo. Los servidores receptores comprueban que la resolución directa e inversa coinciden, y un PTR ausente basta por sí solo para que te archiven como spam.
- Añade la dirección nueva a SPF antes del corte y elimina la antigua después — las dos listadas durante el solape, para que el correo se autentique venga del servidor que venga en cada momento.
- Copia las claves privadas DKIM en lugar de generar unas nuevas, para que el selector ya publicado en el DNS siga validando. Regenerarlas significa volver a publicarlas, y volver a publicarlas tiene su propio retraso de propagación.
- Calienta la dirección nueva de forma gradual si envías algún volumen de correo. Un servidor que no ha enviado nada en toda su existencia y de repente emite diez mil mensajes es, para quien los recibe, indistinguible de un servidor comprometido.
El corte
Todo lo anterior era preparación para que esta parte sea corta, ordenada y reversible. Hazlo en tu mínimo real de tráfico y no a las 3 de la madrugada por superstición — consulta tus propias analíticas. Ten la reversión anotada por escrito antes de empezar, porque el momento en que la necesites es el momento en que menos ganas vas a tener de redactarla.
- 1
Congela las escrituras en el servidor antiguo
Modo mantenimiento, un usuario de base de datos de solo lectura, o un error en las rutas de escritura a nivel del proxy inverso. Las lecturas se siguen sirviendo desde la máquina antigua durante todo el proceso — eso es lo que mantiene el sitio en pie mientras los datos se mueven.
- 2
Desactiva cada temporizador en el servidor antiguo
Comenta los crontabs, detén los temporizadores, detén los workers de la cola. A partir de este punto la máquina antigua no debe procesar nada, o las tareas se ejecutarán dos veces: dos facturas, dos correos, dos entregas de webhook.
- 3
Ejecuta el delta final
La segunda pasada de archivos con --delete, y luego el volcado final de la base de datos o la puesta al día de la réplica. Esta es la corta, minutos como mucho, porque la primera pasada ya movió el grueso.
- 4
Verifica el servidor nuevo contra su nombre de host real
Con el truco de --resolve de antes, ejercita una página que lea de la base de datos, un inicio de sesión, y una ruta de escritura. Confirma que el número de filas coincide con el origen. Haz todo esto antes de cambiar el DNS, mientras revertir todavía no cuesta absolutamente nada.
- 5
Cambia el DNS y arranca los servicios
Actualiza A y AAAA a la dirección nueva, y luego activa y arranca la aplicación y sus temporizadores en el servidor nuevo. El tráfico empieza a llegar dentro de un TTL y sigue desplazándose durante la hora siguiente.
- 6
Mantén el servidor antiguo sirviendo lecturas
Déjalo encendido, en solo lectura, durante al menos veinticuatro horas. Los clientes con cachés obsoletas seguirán llegando a él, y un servidor antiguo de solo lectura devuelve páginas ligeramente desactualizadas en lugar de una conexión rechazada — la diferencia entre una migración invisible y una visible.
El solape es también donde vive el truco más limpio. En lugar de un cambio de DNS a lo bruto, reconfigura el servidor antiguo como proxy inverso hacia el nuevo al final del paso cinco. Cada rezagado que todavía resuelve a la dirección antigua se reenvía de forma transparente, el corte deja de depender por completo de la propagación del DNS, y desmontas el proxy en cuanto el tráfico hacia él llega a cero. Pasa X-Forwarded-For para que tus registros y tus límites de tasa sigan viendo las direcciones reales de los clientes.
Las primeras 48 horas
La migración no termina cuando el sitio carga. Termina cuando ya nada depende de la máquina antigua, y encontrar esas dependencias es un ejercicio activo, no un juego de esperar.
- Vigila el registro de acceso del servidor antiguo. Cada petición que sigue llegando ahí es una dependencia sin migrar — una dirección escrita a fuego en una integración de un socio, un cliente móvil con una caché obsoleta, una sonda de monitorización que ya nadie reclama como suya. El registro es la lista de tareas pendientes.
- Confirma que los temporizadores realmente se ejecutaron en el servidor nuevo. No que estén activados — que se ejecutaron, a la hora esperada, con el resultado esperado. Una tarea de cron que en silencio no hace nada tiene exactamente el mismo aspecto que una que funciona.
- Comprueba de verdad la renovación del certificado con una ejecución de prueba, en lugar de descubrir dentro de sesenta días que tu cliente ACME llevaba renovando contra un servidor que ya no recibe el desafío.
- Comprueba el flujo de correo de principio a fin en las dos direcciones, incluido lo que la aplicación envía automáticamente. Los restablecimientos de contraseña son la víctima clásica, porque nadie los prueba hasta que un usuario necesita uno.
- Haz una copia de seguridad del servidor nuevo y restáurala en algún sitio. Una máquina nueva sin una copia de seguridad verificada está en peor posición que la que dejaste atrás; /guides tiene la versión completa de ese argumento.
- Restaura el TTL de DNS a su valor normal en cuanto tengas confianza. Dejarlo en 300 segundos para siempre es un pequeño coste permanente en consultas y latencia sin ningún beneficio que ya siga aplicando.
Dar de baja el servidor antiguo
El último paso es el que se salta, y es el único con una consecuencia de privacidad. El disco antiguo guarda tus claves, tu base de datos, los datos de tus clientes y tus registros, y cancelar el servicio no borra nada de eso — libera el volumen de vuelta a un fondo común donde el siguiente inquilino recibe lo que sea que haya dejado la política de borrado del proveedor.
- Espera a que el registro de acceso antiguo se quede en silencio antes de tocar nada. Cancelar mientras un proveedor de pagos todavía está enviando webhooks a la dirección antigua es cómo una migración se convierte en un incidente una semana después.
- Rota en lugar de limitarte a borrar: cada credencial que tenía el servidor antiguo — claves de API, contraseñas de base de datos, claves de despliegue, la clave temporal de migración. Da por hecho que cualquier cosa que viviera en una máquina que ya no controlas está comprometida, porque tarde o temprano lo estará.
- Sobrescribe los datos antes de liberar el volumen. Borra de forma segura los directorios sensibles, o llena el espacio libre con un archivo grande de datos aleatorios y bórralo. Imperfecto en un disco virtualizado, y muchísimo mejor que nada.
- Guarda un archivo final de cualquier cosa que puedas querer de referencia — registros, configuración, el historial de shell que documenta lo que realmente se hizo — y almacénalo cifrado en algún sitio que no sea ninguno de los dos servidores.
- Cancela el servicio solo después de que el nuevo haya sobrevivido a un ciclo de facturación completo y a una prueba completa de copia de seguridad y restauración. Ese mes de solape es el seguro más barato de todo el proceso.
Un cronograma que puedes copiar
Nada de esto es difícil por separado. La razón por la que las migraciones salen mal es que los pasos se comprimen en una sola noche, en la que el TTL no ha expirado, el certificado no se ha probado y la reversión no se ha escrito. Repartido a lo largo de una semana, cada día son veinte minutos de trabajo.
Cómo salen mal las migraciones en la práctica
No por la copia. Por las cosas que nunca estuvieron en el disco, y las cosas que se ejecutaron dos veces.
- Los dos servidores escribiendo a la vez — la ventana de split-brain, y el único fallo de esta lista sin una solución limpia. Se evita con el orden, no con las herramientas: detén el antiguo, y luego arranca el nuevo.
- Temporizadores ejecutándose en las dos máquinas, que es como los clientes reciben todo por duplicado. Desactiva los antiguos antes de la sincronización final, no después.
- Un TTL que nunca se bajó, que convierte un corte de cinco minutos en una cola de un día entero que nadie planeó cubrir.
- La propiedad de los archivos queda mal asignada porque los ID numéricos difieren entre las máquinas, así que la aplicación arranca y luego no puede escribir en su propio directorio de subidas.
- Un certificado que se iba a resolver después del cambio, topándose con una cabecera HSTS que deja a los visitantes sin forma de continuar.
- Una dirección escrita a fuego en algún sitio que no controlas — una integración de un socio, una regla de firewall, un registro DNS de un subdominio del que te habías olvidado que existía.
- Cancelar el servidor antiguo el mismo día del traslado, lo que elimina la vía de reversión precisamente en el momento en que las estadísticas dicen que más la vas a necesitar.
¿Cuánto tarda una migración de VPS?
El trabajo son típicamente unas pocas horas repartidas a lo largo de una semana, y la parte visible para el usuario son minutos. La transferencia masiva y la reducción del TTL ocurren con días de antelación mientras todo sigue en marcha; el corte en sí es una sincronización delta final, un cambio de DNS y una pasada de verificación. Un sitio con unos pocos gigabytes de datos y una base de datos modesta es, sin problema, un corte de treinta minutos con una congelación medida en minutos de un solo dígito.
¿Puedo migrar sin ninguna caída en absoluto?
Sí, para las lecturas — el servidor antiguo sigue respondiendo hasta que se mueve el DNS, y convertirlo después en un proxy inverso elimina incluso la cola de propagación. Las escrituras son el caso más difícil: una congelación breve es, con diferencia, la forma más sencilla de garantizar que no se pierde nada, y la replicación reduce esa congelación a segundos. Una congelación cero real en las escrituras exige que la aplicación escriba en las dos bases de datos durante el solape, algo alcanzable pero que añade un modo de fallo que la mayoría de los sitios no necesita.
¿Debería clonar el disco o reconstruir el servidor?
Reconstrúyelo. Un clon arrastra la deriva de configuración, los paquetes huérfanos y cualquier persistencia dejada por un compromiso pasado, y te ata a la versión antigua de la distribución. Instalar desde un script y copiar solo los datos te da una máquina limpia más una receta repetible — que es también lo que hace rápida la siguiente reconstrucción.
¿Qué pasa con mi dirección IP y mi posicionamiento en buscadores?
La dirección cambia; el dominio no, y los enlaces, el posicionamiento y el historial siguen al dominio. Mantén las URL idénticas, mantén el servidor antiguo respondiendo durante el solape para que ningún rastreador vea nunca un error de conexión, y el cambio resulta prácticamente invisible para los buscadores. Cambiar de país puede mover un poco las métricas sensibles a la latencia, así que elige en /locations una región cercana a tu audiencia real.
¿Cómo migro una base de datos sin perder datos?
Detén las escrituras en el origen antes de empezar a escribir en el destino — ese orden es toda la garantía. Para conjuntos de datos pequeños, congela, vuelca con pg_dump o mysqldump --single-transaction, restaura, y cambia. Para los más grandes, replica con antelación y promueve la réplica en el corte para que ponerse al día lleve solo segundos. Verifica comparando el número de filas en las tablas que importan antes de enviar ningún tráfico.
¿Puedo trasladarme a un proveedor offshore sin darle mi identidad?
Sí. Un proveedor que factura desde un saldo en cripto no tiene ni tarjeta ni dirección de facturación que asociar a la máquina, así que la cuenta que hay detrás del servidor no guarda nada sobre ti. La migración en sí es técnicamente idéntica — las mismas pasadas de archivos, el mismo volcado, el mismo cambio de DNS. /offshore-vps explica cómo funciona el modelo y /pay-with cubre la parte del pago.
¿Cuándo es seguro cancelar el servidor antiguo?
Después de que su registro de acceso haya estado en silencio durante al menos un día, de que se haya rotado cada credencial que tenía, y de que hayas hecho una copia de seguridad del servidor nuevo y la hayas restaurado en algún sitio con éxito. Un mes extra de un VPS pequeño es el seguro más barato de todo el proceso — es la diferencia entre una reversión y un incidente.
