Nadie traslada un sitio en producción por entretenimiento. Ocurre porque el proveedor actual pide de pronto una foto de tu pasaporte, o reenvía una denuncia con un plazo de 24 horas, o porque el país donde está su centro de datos dejó de parecer un lugar sensato para guardar tus datos. Sea cual sea el motivo, el traslado en sí es la parte peligrosa: es el único momento en que el sitio puede quedarse a oscuras, y el único momento en que un paso descuidado puede vincular el servidor nuevo a la identidad que intentabas dejar atrás.
Ambos riesgos tienen la misma cura, y no es una herramienta. Es el orden. Una migración ejecutada en la secuencia correcta no tiene ninguna ventana en la que el sitio quede inalcanzable, porque los dos servidores están vivos al mismo tiempo y el DNS es lo último en moverse. Una migración ejecutada en la secuencia equivocada produce una interrupción y un rastro a la vez. Lo que sigue es esa secuencia, escrita para quien se muda a un proveedor offshore sin KYC en lugar de saltar entre dos proveedores convencionales: la mecánica es la misma, pero la limpieza posterior no lo es.
Qué significa en realidad «inactividad cero»
La frase se usa con ligereza, y esa ligereza es lo que hace daño. Servir HTTP desde dos máquinas a la vez es fácil. Mantener el estado coherente mientras dos máquinas sirven a la vez es la parte difícil, y es la única parte que llega a perder datos. Así que antes de planear nada, decide cuál de estos casos es realmente el tuyo, porque la respuesta determina la forma de toda la noche.
| Qué estás moviendo | La parte que realmente muerde | Cuál debería ser el plan |
|---|---|---|
| Sitio estático, sitio de folleto, salida generada | Nada. No hay estado que dividir | Copia, verifica, haz el corte. Inactividad cero de verdad |
| CMS con base de datos: WordPress, Ghost, un foro | Comentarios, inicios de sesión y publicaciones que caen en dos bases de datos a la vez | Una congelación de solo lectura medida en minutos, en tu hora más tranquila |
| Una tienda, o cualquier cosa que reciba pedidos | Un split-brain pierde pedidos pagados en silencio | Tómate la ventana de mantenimiento corta. Sale más barato que la reconciliación |
| Cualquier cosa con tareas cron o workers en segundo plano | La misma tarea se dispara en los dos servidores: correos duplicados, cobros duplicados | Desactiva la programación en el servidor antiguo antes de que arranque el nuevo |
| Correo en el mismo dominio | Los registros MX caducan en las cachés según su propio reloj, sin relación con tu registro A | Mueve el correo otra noche distinta, y deja que el MX antiguo siga aceptando durante una semana |
Fíjate en que solo la primera fila es realmente gratis. En todo lo demás, «inactividad cero» significa «una congelación de escritura tan corta que nadie abre un ticket por ella». Dos minutos de solo lectura a las 04:00 son un error de redondeo; dos horas de escrituras divididas entre dos bases de datos son un fin de semana de reconciliación. Elige la congelación.
Baja el TTL del DNS días antes de mudarte
Este es el único paso con tiempo de antelación, y por eso va primero, y por eso es el que la gente se salta. Tu TTL, el tiempo de vida, le dice a cada resolver de internet cuánto tiempo puede guardar en caché tu registro antes de volver a preguntar. Si tu registro A tiene un TTL de 86400, un resolver que lo consultó hace una hora seguirá entregando la IP antigua durante otras 23 horas más, sin importar lo que cambies en el registrador.
El detalle crítico es que bajar el TTL está a su vez sujeto al TTL antiguo. Los resolvers solo se enteran del valor nuevo y más corto cuando caduca la copia antigua en caché. Así que baja el TTL a 300 segundos al menos un período completo del TTL antiguo antes del corte: con un TTL de un día, eso significa hacerlo entre 24 y 48 horas antes. Entonces el mundo converge en tu registro nuevo en cinco minutos desde el cambio, y el corte deja de ser un momento de suspense.
Vuelve a subir el TTL a algo razonable unos días después del traslado. Un TTL de 300 segundos es una buena herramienta y un mal ajuste permanente: multiplica tu volumen de consultas y convierte a tu proveedor de DNS en un punto único de fallo mucho más crítico.
Haz un inventario de lo que mueves, no de lo que recuerdas
Toda migración fallida tiene el mismo post-mortem: algo que nadie apuntó no se copió. La raíz web y la base de datos son las dos cosas que todo el mundo recuerda; la lista de abajo es el resto, y merece la pena recorrerla al pie de la letra en vez de fiarse de la memoria.
- Trabajo programado.
crontab -lde cada usuario, más los timers de systemd. Aquí se esconden los hooks de renovación y las tareas nocturnas. - Definiciones de servicio. Unidades de systemd personalizadas, los vhosts del servidor web, los pools de PHP-FPM, cualquier configuración de supervisor.
- Secretos y entorno. Archivos
.env, claves de API, contraseñas de bases de datos, sales de la aplicación: y ten en cuenta que estas hay que rotarlas, no solo copiarlas. - Material TLS. Los certificados y, más importante aún, la cuenta ACME y la configuración de renovación.
- Identidad de correo. Claves privadas DKIM, registros SPF y DMARC. Un desajuste aquí no falla de forma ruidosa; simplemente manda tu correo a spam en silencio.
- Medios subidos. A menudo fuera de la raíz web, a menudo lo más pesado que tienes.
- Todo lo externo que confía en tu IP. Listas blancas de pasarelas de pago, destinos de webhooks, firewalls de bases de datos, APIs de terceros con restricciones de IP. Esta es la causa número uno de que «el sitio funciona pero el checkout está roto» a las 03:00.
- La lista de paquetes.
dpkg --get-selectionso el equivalente, para que la máquina nueva tenga las mismas extensiones y bibliotecas en lugar de casi las mismas.
Apunta la lista antes de empezar a copiar. El inventario es también tu plan de pruebas más adelante: cada línea es algo que verificar en el servidor nuevo antes de que el DNS sepa que existe.
Construye primero el servidor nuevo, y endurécelo antes de que aloje nada
Pide el servidor de destino con antelación y déjalo vacío en marcha durante uno o dos días. Solapar los dos no cuesta nada (un VPS offshore pequeño son unos pocos dólares al mes), y tiene mucho valor no hacer la construcción bajo presión de tiempo con una base de datos congelada esperando.
Iguala el entorno antiguo de forma deliberada: la misma distribución y versión mayor, la misma versión mayor de PHP, Node o Python, la misma versión mayor de la base de datos. La tentación de modernizar ya que estás es enorme y hay que resistirla por completo. Si el sitio se rompe después del corte, quieres que haya cambiado exactamente una variable. Actualiza el stack dos semanas después, una tarde aburrida, con la posibilidad de revertir.
Endurécelo mientras sigue vacío. SSH solo con claves, un firewall que deniega por defecto, actualizaciones de seguridad automáticas: la checklist de endurecimiento de la primera hora es exactamente esta lista, y es mucho más fácil aplicarla a una máquina que no tiene nada encima. Si los datos son lo bastante sensibles como para justificar un cambio de jurisdicción, este es también el momento de decidir sobre el cifrado en reposo, porque añadirlo después significa otra migración.
Copia los datos dos veces: un pase lento y luego uno rápido
El instinto es copiarlo todo durante la ventana de mantenimiento. Haz lo contrario. Ejecuta una copia completa con días de antelación mientras el sitio antiguo sigue sirviendo tráfico tranquilamente, y luego haz un segundo pase en el corte que solo mueva lo que cambió. El primer pase puede tardar seis horas y nadie lo nota. El segundo tarda noventa segundos, y ese es todo tu presupuesto de inactividad.
Para los archivos, rsync -aHAX --numeric-ids conserva permisos, propietarios, enlaces duros y atributos extendidos; el flag --numeric-ids importa porque los UIDs casi nunca coinciden entre dos máquinas recién construidas. Ejecútalo una vez con antelación, y otra vez justo antes del corte con los mismos argumentos: la segunda ejecución transfiere solo el delta.
Las bases de datos necesitan el mismo tratamiento en dos fases pero con herramientas distintas. Un mysqldump --single-transaction o pg_dump te da una foto consistente y temprana contra la que construir y probar. En el corte, o bien haces un segundo volcado durante tu breve congelación de escritura, o bien (para una base de datos grande donde incluso una congelación corta duele) configuras el servidor nuevo como réplica del antiguo con días de antelación, dejas que se ponga al día, y luego la promueves. La replicación reduce la congelación a segundos. También convierte una migración de dos horas en un proyecto de dos días, así que úsala solo cuando el tamaño realmente lo exija.
Haz pull, no push, y nunca a través de tu laptop. Inicia la copia desde el servidor nuevo para que la transferencia vaya de servidor a servidor a la velocidad del centro de datos. Enrutar gigabytes por tu conexión doméstica es lento, y deja tu IP residencial en los registros de acceso de ambas máquinas, que es precisamente el vínculo que una migración motivada por la privacidad busca evitar. Si ni siquiera es aceptable que el proveedor antiguo llegue a conocer tu IP nueva, no copies directamente en absoluto: restaura el servidor nuevo desde tu propio backup cifrado fuera del sitio, y las dos máquinas nunca llegan a hablar entre sí.
Prueba el servidor nuevo antes de que el DNS sepa que existe
Puedes servir el hostname real desde la IP nueva sin cambiar ni un solo registro público, y deberías hacerlo: esto es lo que hace que el corte no tenga sobresaltos. Añade una línea a tu /etc/hosts local que apunte el dominio a la IP nueva, o sáltate eso y deja que curl lo haga para una sola petición:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
Ahora recorre el inventario. Carga la portada y tres páginas internas. Inicia sesión. Envía un formulario. Sube un archivo. Comprueba que la conexión a la base de datos es la nueva local y no sigue apuntando al servidor antiguo a través de internet, un error que funciona perfectamente hasta el momento en que cancelas el servidor antiguo. Ejecuta las tareas cron a mano y lee su salida. Verifica las redirecciones y que una URL inexistente sigue devolviendo 404 en lugar de 200.
Emite el certificado TLS ahora, antes del corte, no después. Usa un desafío DNS-01, que demuestra el control del dominio mediante un registro TXT y por tanto funciona mientras el registro A todavía apunta al servidor antiguo. Si esperas a la validación HTTP-01 después del cambio de DNS, todos los visitantes tempranos reciben un aviso de certificado durante ese hueco: una interrupción autoinfligida justo en la ventana que intentabas proteger.
El corte, en orden
Llegados a este punto, el servidor nuevo está construido, endurecido, poblado, probado con el hostname real y tiene un certificado válido. El corte en sí es ahora una lista corta y aburrida, que es justo el objetivo.
- Anuncia la ventana si alguien más depende del sitio, y luego pon el sitio antiguo en modo de solo lectura o mantenimiento.
- Desactiva cron y los workers en segundo plano en el servidor antiguo. Hazlo antes de arrancarlos en el nuevo, nunca después.
- Ejecuta el pase final de delta con
rsyncy el volcado final de la base de datos, e impórtalo. - Arranca la aplicación en el servidor nuevo y vuelve a ejecutar tus pruebas de humo mediante
--resolve, contra los datos finales. - Cambia los registros A y AAAA a la IP nueva. Con un TTL de 300 segundos, el mundo sigue el cambio en cinco minutos.
- Activa cron y los workers en el servidor nuevo.
- Vigila los dos registros de acceso en paralelo. El tráfico se drena del servidor antiguo y aparece en el nuevo; cuando el antiguo queda en silencio, el corte está completo.
- Deja el servidor antiguo encendido, sirviendo tráfico y sin tocar durante una semana. Es tu vía de reversión.
El octavo paso es el que la gente se salta, y es el seguro más barato de toda la lista. Por el precio de unos pocos dólares conservas la posibilidad de volver a apuntar el DNS hacia atrás (una recuperación de cinco minutos) durante todo el tiempo que necesites para estar seguro.
Lo que la migración deja atrás
Aquí está la parte que las guías genéricas de migración omiten, y la que más importa si te mudaste por privacidad y no por precio. Trasladar un sitio no borra su historia. Varios registros públicos y semipúblicos del arreglo antiguo sobreviven al traslado de forma permanente, y saber cuáles son es la diferencia entre una ruptura limpia y la falsa sensación de tenerla.
| Qué registra el traslado | Quién puede leerlo | Qué puedes hacer de verdad |
|---|---|---|
| DNS pasivo: registros A históricos | Cualquiera, mediante servicios comerciales de histórico | Nada. La IP antigua queda asociada al nombre para siempre. Da por hecho que es pública, porque lo es |
| Registros de Certificate Transparency | Cualquiera, para siempre, buscable por dominio | Se lista cada certificado emitido, incluidos los subdominios con pinta de internos que olvidaste. Prefiere un wildcard a los nombres descriptivos |
| Los registros de cuenta del proveedor antiguo | El proveedor antiguo, y quien pueda obligarlo a entregarlos | Datos de tarjeta, email de alta, IPs de inicio de sesión. Un destino sin KYC protege el futuro, no el pasado |
| Historial de WHOIS | Archivos comerciales de histórico de WHOIS | Si el dominio se registró alguna vez con datos reales, esa foto queda capturada. Aplicar privacidad después no la retira |
| Identificadores de analítica y publicidad | El proveedor, y cualquiera que lea el código fuente de tu página | Llevar el mismo ID de seguimiento conecta los dos sitios de forma concluyente. Emite uno nuevo, o elimínalo |
| Volcados y backups que quedan en el disco antiguo | A quien le toque ese almacenamiento después | Borra y sobrescribe antes de cancelar. En almacenamiento compartido, da por hecho que borrar es solo una pista, no una garantía |
Cabeceras Received: en el correo enviado | Cada destinatario, para siempre | Nada retroactivo. Solo el correo que envíes después del traslado lleva la ruta nueva |
| Tus propias conexiones durante la copia | Tu ISP, y los registros de acceso de ambos proveedores | Esta es la única totalmente bajo tu control. Nunca toques ninguna de las dos máquinas desde una IP que te identifique |
El resumen honesto es que una migración no puede reescribir el pasado: solo puede dejar de sumarle cosas. Eso ya vale mucho, pero cambia la decisión: si tu modelo de amenaza exige que ningún observador pueda vincular el sitio nuevo con el antiguo, trasladar el mismo dominio a un proveedor nuevo no lo consigue, y ningún cuidado durante el corte lo conseguirá tampoco. Ese caso necesita un nombre nuevo y un comienzo limpio, del que hablamos a continuación. Si en cambio tu objetivo es dejar de generar registros identificativos a partir de hoy, y trasladar el centro de gravedad legal a una jurisdicción que hayas elegido tú, el traslado logra exactamente eso. Nuestra guía de OpSec del servidor cubre los hábitos que lo mantienen limpio después.
La cuestión del dominio: ¿lo conservas, o empiezas de cero?
El sitio y el dominio son decisiones independientes, y es habitual confundirlas. Puedes trasladar el alojamiento hoy mismo y dejar el registrador en paz para siempre; nada en el cambio de servidor obliga a tocar el dominio. Que debas hacerlo depende por completo de lo que el dominio ya sepa de ti.
- Conserva el dominio, cambia de registrador. Tiene sentido cuando el dominio tiene valor: enlaces, posicionamiento, un nombre que la gente teclea. Arregla el futuro del registro WHOIS, no su historia, y mantiene intacta cada señal de posicionamiento. Esta es la respuesta correcta para la mayoría de los sitios comerciales.
- Conserva el dominio, no cambies nada más que el proveedor. Perfectamente razonable cuando te mudaste por jurisdicción, disponibilidad o postura ante la DMCA, y no por anonimato. El traslado más simple posible, riesgo de SEO cero.
- Dominio nuevo, redirige el antiguo. Conserva el posicionamiento, y vincula los dos nombres pública y permanentemente. Elígelo por continuidad, nunca por privacidad: la redirección es el vínculo.
- Dominio nuevo, ruptura limpia. La única opción que realmente corta la asociación, y te cuesta todo el posicionamiento y todos los enlaces entrantes que tenías. Regístralo de forma privada desde el principio, porque un dominio es tan anónimo como lo fue su primer registro. Nuestra guía de registro anónimo de dominios con cripto cubre cómo hacerlo bien.
Elige con criterio, y elige antes del corte, no durante él. Cambiar de opinión sobre el dominio después de que el DNS se haya movido significa hacer la parte delicada dos veces.
Da de baja el servidor antiguo correctamente
Una semana o dos después del corte, cuando los registros del servidor nuevo son aburridos y los del antiguo están vacíos, es hora de cerrar la cuenta antigua. Hazlo en este orden, porque el atajo tentador (pulsar cancelar) es el que deja tus datos en el disco de otra persona.
- Confirma que nada sigue apuntando a la IP antigua: revisa direcciones fijadas a mano en webhooks de terceros, listas blancas, monitorización, y cualquier registro DNS que se te haya olvidado, como un subdominio suelto tipo
mailocpanel. - Rota todos los secretos que llegaron a vivir en esa máquina: contraseñas de bases de datos, claves de API, sales de la aplicación, claves DKIM, claves SSH. No las copies al servidor nuevo.
- Elimina tus claves públicas SSH y cualquier acceso de soporte del servidor antiguo.
- Borra la aplicación, los volcados y los backups, y luego sobrescribe el espacio libre para que una lectura superficial del volumen reciclado no arroje nada.
- Solo entonces da de baja el servicio, y elimina cualquier método de pago guardado en la cuenta antigua.
Todo lo que vivió en un hardware que ya no controlas está comprometido por definición. No porque tu proveedor antiguo sea malicioso, sino porque ese disco va a volver a un pool y nunca sabrás qué sobrevivió al borrado. Rotar una contraseña de base de datos lleva dos minutos. Descubrir meses después que una clave de un servidor dado de baja todavía abre algo lleva bastante más tiempo.
Toda la secuencia en una sola página
Quitando el razonamiento, una migración de servidor son nueve pasos, de los que solo dos tienen alguna urgencia:
- Dos días antes: baja el TTL del DNS a 300 segundos.
- Dos días antes: pide y endurece el servidor de destino, igualando el stack antiguo versión por versión.
- Días antes: escribe el inventario: cron, secretos, TLS, claves de correo, medios, listas blancas de IP, paquetes.
- Días antes: ejecuta la primera copia completa de datos, de servidor a servidor.
- Antes de la ventana: emite el certificado por DNS-01 y prueba todo mediante
--resolve. - La ventana (minutos): congela las escrituras, desactiva el cron antiguo, ejecuta la copia delta y el volcado final, arranca la aplicación nueva.
- La ventana (segundos): cambia el registro A, y luego activa cron en el servidor nuevo.
- La semana siguiente: mantén vivo el servidor antiguo como vía de reversión, vigila los dos archivos de registro, y luego vuelve a subir el TTL.
- Después: rota los secretos, borra, cancela... y recuerda lo que el traslado no pudo borrar.
Nada de esa lista es difícil. Cada paso que duele es un paso hecho fuera de orden: un TTL bajado la misma noche, un certificado emitido después del cambio de DNS, una tarea cron que queda activa en una máquina que ya no es la autoritativa. Consigue que la secuencia sea correcta y la parte interesante de una migración es elegir dónde poner el servidor, no el traslado en sí. Si todavía no has decidido eso, la guía de jurisdicciones es el sitio por donde empezar.