[Inicio](https://servhidden.com/es) / [Guías de Alojamiento Privado](https://servhidden.com/es/guides) / Cómo migrar un sitio web a alojamiento offshore sin inactividad Operaciones # Migra a alojamiento offshore sin inactividad Casi toda migración dolorosa es un fallo de orden, no un fallo técnico: un TTL bajado la misma noche en lugar de dos días antes, un certificado emitido después del cambio de DNS en lugar de antes, una tarea cron que sigue activa en un servidor que ya no es el autoritativo. Esta es la secuencia que elimina por completo la ventana de inactividad, más la parte que las guías genéricas se saltan: qué registra el traslado de forma permanente sobre ti, y qué puedes hacer todavía al respecto. [Leer la guía](#guide-body) [Preguntas frecuentes](#guide-faq) ## En esta página - [Guía](#guide-body) - [Preguntas frecuentes](#guide-faq) - [Guías relacionadas](#guide-related) - [Páginas recomendadas](#guide-cta) Sin KYC Solo cripto Sin registros DMCA ignorado Root completo NVMe SSD 18 min de lectura Actualizado Aug 2026 En esta página [01Qué significa en realidad «inactividad cero»](#qué-significa-en-realidad-inactividad-cero) [02Baja el TTL del DNS días antes de mudarte](#baja-el-ttl-del-dns-días-antes-de-mudarte) [03Haz un inventario de lo que mueves, no de lo que recuerdas](#haz-un-inventario-de-lo-que-mueves-no-de-lo-que-recuerdas) [04Construye primero el servidor nuevo, y endurécelo antes de que aloje nada](#construye-primero-el-servidor-nuevo-y-endurécelo-antes-de-qu) [05Copia los datos dos veces: un pase lento y luego uno rápido](#copia-los-datos-dos-veces-un-pase-lento-y-luego-uno-rápido) [06Prueba el servidor nuevo antes de que el DNS sepa que existe](#prueba-el-servidor-nuevo-antes-de-que-el-dns-sepa-que-existe) [07El corte, en orden](#el-corte-en-orden) [08Lo que la migración deja atrás](#lo-que-la-migración-deja-atrás) [09La cuestión del dominio: ¿lo conservas, o empiezas de cero?](#la-cuestión-del-dominio-lo-conservas-o-empiezas-de-cero) [10Da de baja el servidor antiguo correctamente](#da-de-baja-el-servidor-antiguo-correctamente) [11Toda la secuencia en una sola página](#toda-la-secuencia-en-una-sola-página) [FAQPreguntas frecuentes](#guide-faq) [→Páginas recomendadas](#guide-cta) 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. Ambos servidores funcionan a la vez y el DNS cambia el último: por eso un corte bien secuenciado no tiene ninguna ventana en absoluto. ## 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 -l de 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-selections o 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](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) 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](https://servhidden.com/es/guides/full-disk-encryption-on-a-vps), 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](https://servhidden.com/es/guides/vps-backup-strategy), 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 rsync y 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](https://servhidden.com/es/guides/server-opsec-staying-anonymous) 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](https://servhidden.com/es/guides/anonymous-domain-registration-with-crypto) 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 mail o cpanel. - 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](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) es el sitio por donde empezar. Preguntas frecuentes ## Migración de servidor: preguntas frecuentes ### 01 ¿Cuánta inactividad debo esperar en realidad? Para un sitio estático, ninguna: los dos servidores pueden servir el mismo contenido a la vez, así que el cambio de DNS pasa inadvertido. Para cualquier cosa con base de datos, tu inactividad es exactamente la duración de tu congelación de escritura, que suele ser de dos a diez minutos si ya has hecho una copia completa de los datos de antemano. El número que importa no es la velocidad con la que se mueve el DNS, sino cuánto copias durante la ventana. Copia casi todo con días de antelación y la ventana se reduce al tamaño del delta. ### 02 ¿Cuánto tarda la propagación del DNS? No existe tal propagación: esa palabra describe algo que no ocurre. Los resolvers simplemente guardan en caché tu registro durante el tiempo que indica su TTL, y vuelven a preguntar cuando caduca. Si el TTL vigente era 86400, algunos resolvers seguirán sirviendo la IP antigua durante 24 horas más. Baja el TTL a 300 segundos al menos un período completo del TTL antiguo antes del corte, y todo internet seguirá tu cambio en cinco minutos. ### 03 ¿Tengo que trasladar también mi dominio? No. El registrador y el proveedor de alojamiento son completamente independientes, y trasladar el sitio dejando el dominio exactamente donde está funciona perfectamente. Que te convenga moverlo o no depende de tu motivo para migrar: si fue la jurisdicción, el precio o tu postura ante la DMCA, deja el dominio tal cual. Si fue el anonimato, ten en cuenta que el dominio arrastra su propia historia por separado: los archivos de WHOIS conservan los datos con los que se registró por primera vez, y un cambio de alojamiento no lo toca. ### 04 ¿Puedo migrar sin que el proveedor antiguo llegue a saber adónde me fui? No si copias directamente entre las dos máquinas: un extremo se conecta con el otro, y los registros de acceso de ambas quedan grabados. Si ese vínculo importa de verdad para tu modelo de amenaza, no copies de servidor a servidor en absoluto: restaura el servidor nuevo desde tu propio backup cifrado fuera del sitio, de modo que los dos proveedores nunca intercambien un paquete. En cualquier caso, nunca inicies la transferencia desde una conexión que te identifique, y no menciones el destino en ningún ticket de soporte que abras con el proveedor antiguo. ### 05 ¿Debería actualizar el sistema operativo o el stack al mismo tiempo? No, y este es el fallo autoinfligido más común en una migración. Cambia una sola cosa. Si el sitio se comporta mal después del corte, quieres una única causa posible, no tener que elegir entre la máquina nueva, la versión nueva de PHP y la versión mayor nueva de la base de datos. Iguala el entorno antiguo versión por versión, completa el traslado, confirma una semana de registros limpios, y luego actualiza por separado con la posibilidad de revertir. ### 06 ¿Migrar perjudicará mi posicionamiento en buscadores? No de forma significativa, siempre que el dominio, las URLs y el contenido se mantengan iguales: Google indexa URLs, no direcciones IP, y un cambio de proveedor por sí solo no es una señal de posicionamiento. Mantén la estructura de URL idéntica, devuelve los mismos códigos de estado, y no combines el traslado con un rediseño o un cambio de esquema de URL. Si en cambio te mudas a un dominio nuevo, espera una caída temporal aunque uses redirecciones 301 correctas, y ten en cuenta que esas redirecciones también conectan públicamente los dos nombres. ### 07 ¿Necesito volver a emitir los certificados TLS? Sí: el servidor nuevo necesita su propio certificado y su propia clave privada, y arrastrar la clave antigua es una mala costumbre incluso cuando funciona técnicamente. Emítelo antes del corte usando un desafío DNS-01, que valida a través de un registro TXT y por tanto funciona mientras el registro A todavía apunta al servidor antiguo. Esperar a la validación HTTP-01 después del cambio de DNS garantiza un tramo de avisos de certificado justo en la ventana que intentabas proteger. ### 08 ¿Cuándo es seguro cancelar el servidor antiguo? Después de una semana o dos con registros silenciosos en la máquina antigua y registros limpios en la nueva: la espera es tu vía de reversión, y cuesta unos pocos dólares. Antes de cancelar, comprueba que nada externo siga apuntando a la IP antigua, rota todos los secretos que vivieron alguna vez en ese servidor, y luego borra tus datos y sobrescribe el espacio libre. Cancela al final. Pulsar terminar primero deja tu base de datos en un disco que ya no controlas. Guías relacionadas ## Seguir leyendo [### Cómo Elegir una Jurisdicción de Alojamiento Offshore en 2026 Compra Un marco práctico de decisión para elegir una jurisdicción offshore: legislación de retención de datos, exposición al MLAT, postura ante DMCA, velocidad judicial y aplicación real — país por país. FAQ de 6 preguntas](https://servhidden.com/es/guides/choosing-an-offshore-jurisdiction) [### VPS vs Servidor Dedicado para Cargas de Trabajo Críticas de Privacidad Compra Cuándo un VPS es suficiente, cuándo la tenencia compartida es un riesgo y cuándo el bare metal es la única respuesta honesta. Aislamiento de hardware, riesgo de hipervisor y coste frente a modelo de amenazas. FAQ de 6 preguntas](https://servhidden.com/es/guides/vps-vs-dedicated-for-privacy) [### VPN Autogestionada en un VPS Sin KYC: WireGuard vs OpenVPN Operaciones Por qué una VPN autogestionada supera a los proveedores comerciales, y cómo WireGuard y OpenVPN se comparan realmente en privacidad, rendimiento y riesgo operativo en 2026. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 para inferencia IA (y dónde encaja la RTX 5090) Compra Guía de decisión de compra: qué GPU NVIDIA elegir para LLM, imagen, video, voz y cargas de trabajo de fine-tuning autoalojadas en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, rendimiento, $/token, cuándo gana cada una. FAQ de 6 preguntas](https://servhidden.com/es/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows Offshore para Trading Forex con MT4 / MT5 / cTrader Operaciones Guía completa: por qué usar un RDP Windows para trading forex, cómo elegir una jurisdicción offshore de baja latencia, configuración de MT4 / MT5 / cTrader / Expert Advisor, latencia a servidores de broker, y el proceso de checkout sin KYC. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-windows-rdp-for-forex-trading) [### Alojamiento Ignorado por DMCA: Lo Que Realmente Significa en 2026 Compra Qué ofrece realmente el alojamiento «ignorado por DMCA», qué jurisdicciones lo respaldan de verdad, para qué cargas de trabajo es necesario, y las trampas sobre derechos de autor que el término no cubre. FAQ de 6 preguntas](https://servhidden.com/es/guides/dmca-ignored-hosting-explained) [### Registro Anónimo de Dominios con Cripto: Privacidad WHOIS en 2026 Privacidad Una guía práctica de 2026 para registrar dominios sin revelar tu identidad: regímenes WHOIS por TLD, elección de registrador, opciones de pago en cripto, y los errores operativos que te delatan igualmente. FAQ de 6 preguntas](https://servhidden.com/es/guides/anonymous-domain-registration-with-crypto) [### Pagos Cripto para Alojamiento: Monero vs Bitcoin vs USDT Privacidad Cómo la elección de la moneda afecta lo que tu proveedor aprende sobre ti. Privacidad, comisiones, finalidad y exposición al análisis de cadena para XMR, BTC y USDT — con una recomendación clara. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### ¿Es realmente anónimo el hosting offshore? Una respuesta honesta Privacidad El hosting offshore sin KYC elimina la identidad que un proveedor normal recopila, pero «anónimo» depende del pago, del registro de logs del proveedor y de tu propia opsec. Esto es lo que realmente se puede rastrear. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-truly-anonymous) [### La primera hora de hardening de un VPS: una checklist Operaciones Una checklist concreta y ordenada para asegurar un VPS nuevo en menos de una hora: claves SSH, un firewall, fail2ban, actualizaciones automáticas y la reducción de superficie de ataque que detiene la mayoría de los ataques oportunistas. FAQ de 6 preguntas](https://servhidden.com/es/guides/first-hour-vps-hardening-checklist) [### ¿Qué es el Hosting sin KYC? Definición, Legalidad y Cómo Funciona Privacidad El hosting sin KYC te permite alquilar un servidor sin ninguna verificación de identidad: sin nombre, sin correo electrónico, sin identificación. Aquí encontrarás exactamente qué significa, cómo funciona técnicamente, si es legal y cómo elegir un proveedor genuino. FAQ de 6 preguntas](https://servhidden.com/es/guides/what-is-no-kyc-hosting) [### ¿Es Legal el Hosting Offshore? La Respuesta Honesta para 2026 Compra El hosting offshore es legal, tanto para ti como para el proveedor. Aquí explicamos qué significa realmente el término, dónde está la línea legal, los mitos que vale la pena descartar y cómo utilizarlo de forma responsable. FAQ de 6 preguntas](https://servhidden.com/es/guides/is-offshore-hosting-legal) [### Cómo pagar el alojamiento con Monero (XMR) — Guía paso a paso Privacidad Guía paso a paso para pagar un VPS o servidor dedicado con Monero (XMR): por qué XMR es la opción más privada, cómo adquirirlo y cómo funciona el proceso de pago — desde la factura hasta un servidor en funcionamiento en minutos. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-pay-for-hosting-with-monero) [### Cómo alojar un sitio web de forma anónima — Guía práctica 2026 Privacidad Una guía práctica y por capas para alojar un sitio web sin revelar tu identidad: la cuenta, el pago, el dominio, la jurisdicción, la conexión y el contenido — cada capa explicada en detalle. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-website-anonymously) [### Cómo configurar una VPN WireGuard en un VPS — Guía paso a paso Operaciones Crea tu propia VPN privada en un VPS con WireGuard: por qué una VPN autoalojada supera a una comercial, la configuración completa desde la instalación hasta el primer cliente conectado, y cómo reforzar la seguridad. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Cómo alojar tu propio LLM en un servidor GPU — Guía 2026 Operaciones Ejecuta tu propio modelo de lenguaje en un servidor GPU alquilado: por qué el autoalojamiento supera a una API, qué GPU y modelo elegir, la configuración con Ollama o vLLM, y cuánto cuesta. FAQ de 6 preguntas](https://servhidden.com/es/guides/self-host-an-llm-on-a-gpu-server) [### Hosting Bulletproof vs Hosting Offshore — ¿Cuál es la diferencia? Compra El hosting bulletproof y el hosting offshore se confunden constantemente, pero no son lo mismo. Aquí encontrarás la diferencia real, por qué importa y cuál es el que verdaderamente necesitas. FAQ de 6 preguntas](https://servhidden.com/es/guides/bulletproof-vs-offshore-hosting) [### Cómo comprar un VPS con Bitcoin — paso a paso (2026) Compra Una guía accesible para comprar un VPS con Bitcoin: cómo obtener BTC, elegir un plan, pagar la factura y lo que obtienes a cambio — un servidor en funcionamiento sin tarjeta y sin nombre vinculado. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-buy-a-vps-with-bitcoin) [### Los mejores países para hosting ignorado por DMCA en 2026 Compra Dónde alojar cuando necesitas servidores fuera del alcance de las órdenes de retirada al estilo estadounidense: las jurisdicciones que funcionan, qué significa realmente «ignorado por DMCA» y cómo elegir. FAQ de 6 preguntas](https://servhidden.com/es/guides/best-countries-for-dmca-ignored-hosting) [### Cómo alojar un servicio oculto de Tor (sitio .onion) — Guía 2026 Operaciones Configura un servicio onion de Tor en un VPS: qué es un servicio oculto, por qué es la forma más sólida de alojamiento anónimo, el proceso completo de configuración y cómo mantener el anonimato real. FAQ de 6 preguntas](https://servhidden.com/es/guides/how-to-host-a-tor-hidden-service) [### Configuración de un servidor de correo offshore — Aloja tu propio email privado en 2026 Operaciones Ejecuta tu propio servidor de correo privado en un VPS offshore: por qué alojar el email tú mismo, qué necesitas, la configuración práctica con una solución todo-en-uno y cómo garantizar la entregabilidad. FAQ de 6 preguntas](https://servhidden.com/es/guides/offshore-mail-server-setup) [### Guía de alojamiento de nodos cripto — Ejecuta un nodo blockchain en un VPS Operaciones Cómo alojar un nodo blockchain en un servidor: por qué ejecutar tu propio nodo, cómo dimensionar el servidor para Bitcoin, Ethereum, Monero y otras redes, la configuración inicial y cómo mantenerlo privado. FAQ de 6 preguntas](https://servhidden.com/es/guides/crypto-node-hosting-guide) [### Hosting GPU para Stable Diffusion — Monta tu propio servidor de imágenes Operaciones Ejecuta Stable Diffusion en tu propio servidor GPU: por qué autoalojar la generación de imágenes, qué GPU elegir, la configuración con una interfaz web y qué cuesta frente a un servicio alojado. FAQ de 6 preguntas](https://servhidden.com/es/guides/gpu-hosting-for-stable-diffusion) [### OpSec para servidores — Mantener el anonimato cuando gestionas un servidor Privacidad Seguridad operacional para quien gestiona un servidor anónimo: los errores que desvelan identidades, los hábitos que los previenen y cómo mantener las identidades verdaderamente separadas. FAQ de 6 preguntas](https://servhidden.com/es/guides/server-opsec-staying-anonymous) [### Guía de configuración de seedbox — Crea tu propio seedbox privado en 2026 Operaciones Cómo construir tu propio seedbox en un servidor: qué es un seedbox, cómo dimensionarlo, instalar un cliente torrent con interfaz web y mantenerlo privado y seguro. FAQ de 6 preguntas](https://servhidden.com/es/guides/seedbox-setup-guide) [### Cómo eludir la censura DPI con tu propio VPS (guía 2026) Privacidad ¿Tu VPN dejó de funcionar? Cómo eludir la censura DPI con tu propio VPS: qué detecta realmente la inspección profunda de paquetes, cuál de los cinco protocolos de 2026 vence a cada tipo de bloqueo, y una guía completa de VLESS+REALITY paso a paso. FAQ de 6 preguntas](https://servhidden.com/es/guides/bypass-dpi-censorship-with-your-own-vps) [### Cifrado de disco completo en un VPS: configurar LUKS y qué protege Operaciones Cómo cifrar un VPS con LUKS: volúmenes cifrados, cifrado de raíz completa con desbloqueo remoto por SSH, los ajustes que importan en un servidor pequeño, y qué detiene realmente el cifrado de disco. FAQ de 8 preguntas](https://servhidden.com/es/guides/full-disk-encryption-on-a-vps) [### Ocultar la IP de origen: CDN, proxy inverso y qué se filtra Privacidad Si conviene poner un CDN delante de un servidor offshore: qué oculta, el servicio de abuso que heredas, las seis formas en que la IP de origen se filtra igualmente, y cómo auditar la tuya. FAQ de 8 preguntas](https://servhidden.com/es/guides/hiding-your-origin-server-ip) [### Backup de VPS: cifrado, fuera del sitio y que realmente restaura Operaciones Tu proveedor no guarda copias. Qué destruye realmente un servidor, por qué el backup por push muere con él, restic vs Borg, y cómo probar que restaura de verdad. FAQ de 8 preguntas](https://servhidden.com/es/guides/vps-backup-strategy) [### Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE Operaciones Qué cambia autoalojar tu propio servidor Matrix: Synapse frente a Conduit, el server_name que no puedes cambiar y lo que la federación sigue revelando. FAQ de 8 preguntas](https://servhidden.com/es/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operaciones Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 preguntas](https://servhidden.com/es/guides/self-host-a-crypto-payment-gateway) ## Dale a la migración un lugar donde aterrizar Servidores KVM offshore en siete jurisdicciones desde $7.50/mes, con root completo, almacenamiento NVMe y ancho de banda ilimitado, desplegados en menos de cinco minutos en cuanto se confirma el pago en cripto. Pon en marcha el destino con antelación, copia a tu ritmo y haz el corte cuando esté listo. [Ver planes VPS](https://servhidden.com/es/vps) [Hosting offshore](https://servhidden.com/es/offshore-hosting) [Todas las ubicaciones](https://servhidden.com/es/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS y servidores dedicados offshore en 7 jurisdicciones privacy-friendly. Sin KYC, sin registros, solo criptomonedas. Privacidad por arquitectura.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Cómo migrar un sitio web a alojamiento offshore sin inactividad", "description": "El orden que convierte una migración de servidor en algo aburrido: baja el TTL de DNS con días de antelación, mantén los dos servidores en paralelo, congela las escrituras solo minutos, no horas, y limpia el rastro de DNS pasivo, Certificate Transparency y WHOIS que deja el traslado.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "es", "keywords": "migrar sitio web a hosting offshore, cambiar de hosting sin downtime, migración de servidor sin tiempo de inactividad, mover un VPS a otro proveedor, bajar el TTL antes de migrar, migrar a hosting sin KYC, checklist de migración web, migrar servidor con rsync", "articleSection": "Operaciones", "wordCount": 3584 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "¿Cuánta inactividad debo esperar en realidad?", "acceptedAnswer": { "@type": "Answer", "text": "Para un sitio estático, ninguna: los dos servidores pueden servir el mismo contenido a la vez, así que el cambio de DNS pasa inadvertido. Para cualquier cosa con base de datos, tu inactividad es exactamente la duración de tu congelación de escritura, que suele ser de dos a diez minutos si ya has hecho una copia completa de los datos de antemano. El número que importa no es la velocidad con la que se mueve el DNS, sino cuánto copias durante la ventana. Copia casi todo con días de antelación y la ventana se reduce al tamaño del delta." } }, { "@type": "Question", "name": "¿Cuánto tarda la propagación del DNS?", "acceptedAnswer": { "@type": "Answer", "text": "No existe tal propagación: esa palabra describe algo que no ocurre. Los resolvers simplemente guardan en caché tu registro durante el tiempo que indica su TTL, y vuelven a preguntar cuando caduca. Si el TTL vigente era 86400, algunos resolvers seguirán sirviendo la IP antigua durante 24 horas más. Baja el TTL a 300 segundos al menos un período completo del TTL antiguo antes del corte, y todo internet seguirá tu cambio en cinco minutos." } }, { "@type": "Question", "name": "¿Tengo que trasladar también mi dominio?", "acceptedAnswer": { "@type": "Answer", "text": "No. El registrador y el proveedor de alojamiento son completamente independientes, y trasladar el sitio dejando el dominio exactamente donde está funciona perfectamente. Que te convenga moverlo o no depende de tu motivo para migrar: si fue la jurisdicción, el precio o tu postura ante la DMCA, deja el dominio tal cual. Si fue el anonimato, ten en cuenta que el dominio arrastra su propia historia por separado: los archivos de WHOIS conservan los datos con los que se registró por primera vez, y un cambio de alojamiento no lo toca." } }, { "@type": "Question", "name": "¿Puedo migrar sin que el proveedor antiguo llegue a saber adónde me fui?", "acceptedAnswer": { "@type": "Answer", "text": "No si copias directamente entre las dos máquinas: un extremo se conecta con el otro, y los registros de acceso de ambas quedan grabados. Si ese vínculo importa de verdad para tu modelo de amenaza, no copies de servidor a servidor en absoluto: restaura el servidor nuevo desde tu propio backup cifrado fuera del sitio, de modo que los dos proveedores nunca intercambien un paquete. En cualquier caso, nunca inicies la transferencia desde una conexión que te identifique, y no menciones el destino en ningún ticket de soporte que abras con el proveedor antiguo." } }, { "@type": "Question", "name": "¿Debería actualizar el sistema operativo o el stack al mismo tiempo?", "acceptedAnswer": { "@type": "Answer", "text": "No, y este es el fallo autoinfligido más común en una migración. Cambia una sola cosa. Si el sitio se comporta mal después del corte, quieres una única causa posible, no tener que elegir entre la máquina nueva, la versión nueva de PHP y la versión mayor nueva de la base de datos. Iguala el entorno antiguo versión por versión, completa el traslado, confirma una semana de registros limpios, y luego actualiza por separado con la posibilidad de revertir." } }, { "@type": "Question", "name": "¿Migrar perjudicará mi posicionamiento en buscadores?", "acceptedAnswer": { "@type": "Answer", "text": "No de forma significativa, siempre que el dominio, las URLs y el contenido se mantengan iguales: Google indexa URLs, no direcciones IP, y un cambio de proveedor por sí solo no es una señal de posicionamiento. Mantén la estructura de URL idéntica, devuelve los mismos códigos de estado, y no combines el traslado con un rediseño o un cambio de esquema de URL. Si en cambio te mudas a un dominio nuevo, espera una caída temporal aunque uses redirecciones 301 correctas, y ten en cuenta que esas redirecciones también conectan públicamente los dos nombres." } }, { "@type": "Question", "name": "¿Necesito volver a emitir los certificados TLS?", "acceptedAnswer": { "@type": "Answer", "text": "Sí: el servidor nuevo necesita su propio certificado y su propia clave privada, y arrastrar la clave antigua es una mala costumbre incluso cuando funciona técnicamente. Emítelo antes del corte usando un desafío DNS-01, que valida a través de un registro TXT y por tanto funciona mientras el registro A todavía apunta al servidor antiguo. Esperar a la validación HTTP-01 después del cambio de DNS garantiza un tramo de avisos de certificado justo en la ventana que intentabas proteger." } }, { "@type": "Question", "name": "¿Cuándo es seguro cancelar el servidor antiguo?", "acceptedAnswer": { "@type": "Answer", "text": "Después de una semana o dos con registros silenciosos en la máquina antigua y registros limpios en la nueva: la espera es tu vía de reversión, y cuesta unos pocos dólares. Antes de cancelar, comprueba que nada externo siga apuntando a la IP antigua, rota todos los secretos que vivieron alguna vez en ese servidor, y luego borra tus datos y sobrescribe el espacio libre. Cancela al final. Pulsar terminar primero deja tu base de datos en un disco que ya no controlas." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Inicio", "item": "https://servhidden.com/es/" }, { "@type": "ListItem", "position": 2, "name": "Guías de Alojamiento Privado", "item": "https://servhidden.com/es/guides" }, { "@type": "ListItem", "position": 3, "name": "Cómo migrar un sitio web a alojamiento offshore sin inactividad", "item": "https://servhidden.com/es/guides/migrate-website-to-offshore-hosting" } ] } ```