Ya contrataste el hosting nuevo y tienes fecha. Copiar los archivos toma poco. El momento crítico es cuando cambias el DNS y ves si el correo, el certificado y los formularios quedaron bien. Para migrar hosting sin caídas, el orden pesa más que la herramienta. Si aún no defines qué mover ni a dónde, parte por la guía para planificar la migración de tu web. Acá partimos de que la decisión ya está tomada.
Qué significa “sin caídas” en una migración
Durante toda la ventana tienen que seguir funcionando tres cosas:
- La web responde en el dominio real, no solo en una URL de prueba.
- El correo entra y sale con las mismas cuentas.
- Tú mantienes acceso al panel del hosting y al dominio.
Cuando algo se corta, casi siempre es por una de estas causas: el registro A sigue apuntando al servidor viejo, el SSL no se emitió en el destino o los MX se copiaron mal. Las tres se evitan antes del corte, no durante. Si todavía comparas proveedores, revisa qué mirar antes de contratar un hosting.
Antes del corte: checklist de preparación
Inventario de lo que se mueve
Haz la lista por escrito. Si no sabes qué tienes, no vas a saber qué se perdió.
- Archivos del sitio y su ruta real (document root).
- Bases de datos, con usuario y contraseña.
- Cuentas de correo: cuántas, cuáles y cuánto pesa cada buzón.
- Tareas cron: horario y comando exacto.
- Certificados y subdominios activos.
- Redirecciones y reglas del servidor (.htaccess o configuración de nginx).
- Versión de PHP y extensiones que usa el sitio (por ejemplo imagick, intl, soap): una diferencia de versión con el servidor nuevo es la causa más común de error 500 después del corte.
Respaldo completo y prueba de restauración
Un respaldo que nunca restauraste no está probado. Descarga una copia, levántala en el servidor nuevo y ábrela. Si no funciona ahí, tampoco va a funcionar el día del corte. El procedimiento está en cómo comprobar que puedes recuperar tu web.
Bajar el TTL antes del cambio
El TTL está definido en el RFC 1035 y se expresa en segundos: es el tiempo que un resolver puede guardar un registro en caché. Bájalo, por ejemplo, a 300 segundos. Hazlo con una anticipación al menos igual al TTL original; para la mayoría de las zonas, 24 a 48 horas bastan. Anota el valor original y el nuevo para restaurarlo después.
No existe un tiempo de propagación universal. Depende del TTL que tenías y de la caché de cada resolver. Con un TTL de 86400 segundos, un resolver puede seguir entregando la IP vieja hasta un día después del cambio.
Montar el sitio en el hosting nuevo y probarlo sin tocar el DNS
Usa el archivo hosts de tu equipo o la URL temporal del proveedor. Prueba la home, los formularios, el login y una página interna pesada. Si es WordPress, guarda un post de prueba: eso pone a prueba rutas, permisos y base de datos.
Emitir el certificado SSL antes del corte
El certificado tiene que existir antes de que llegue el tráfico. Con Let’s Encrypt, la validación HTTP falla mientras el dominio apunte al servidor viejo. Usa validación por DNS o la alternativa que ofrezca tu proveedor (depende del proveedor). Si el sitio ya muestra advertencia, el problema viene de antes: por qué tu web aparece como no segura.
Anotar accesos al dominio .cl y al panel DNS
Necesitas saber quién tiene la clave del registrador .cl, quién administra la zona DNS y a qué correo llegan las notificaciones. Si esa clave está en la casilla de alguien que ya no trabaja en la empresa, la migración se detiene ahí. Deja todo en una cuenta corporativa: accesos y renovación de tu dominio .cl.
Ojo con una confusión común: en NIC Chile solo se cambian los NS (nameservers). Los registros A, MX, TXT y CAA se editan en el panel DNS del proveedor que tengas hoy, sea cPanel, DirectAdmin o Cloudflare.
Orden de los cambios DNS
Qué registros cambian y cuáles no
| Registro | Para qué sirve | ¿Cambia en la migración? |
|---|---|---|
| A | IP IPv4 del servidor | Sí, al servidor nuevo |
| AAAA | IP IPv6 | Sí si el destino tiene IPv6; si no, se elimina |
CNAME de www | Alias de www | Sí, si cambia el destino |
| MX | Servidores que reciben correo | Solo si migras el correo |
| TXT (SPF, DKIM, DMARC) | Autenticación de correo | Se copian idénticos; el SPF se ajusta si el servidor nuevo envía correo (formularios) |
| CAA | Autoridades que pueden emitir SSL | Solo si la autoridad del nuevo hosting no está permitida |
| NS | Quién hospeda la zona | Solo si cambias de proveedor DNS |
Secuencia paso a paso
- Si cambias de proveedor DNS, copia la zona completa al nuevo: MX, TXT de SPF, DKIM y DMARC, CAA y subdominios.
- Compara registro por registro. Un TXT con una comilla corrida rompe el SPF y el correo empieza a caer en spam.
- Si corresponde, cambia los NS y espera a que respondan los nuevos.
- Cambia el A y el AAAA al servidor nuevo.
- Ajusta el CNAME de
www. - Verifica desde fuera antes de tocar nada más.
- Deja el servidor viejo encendido y con los archivos intactos: es tu plan de reversión.
Primero se asegura el correo, copiado idéntico; después se mueve la web. Al revés, puedes quedarte sin sitio y sin forma de avisar a nadie.
Si Cloudflare está delante del sitio
El proxy cubre solo tráfico web. Los registros que usa el correo, como el A de mail.tudominio.cl, quedan en modo solo DNS (nube gris). El cambio de IP se hace dentro de Cloudflare. Con el proxy activo, los visitantes ven IPs de Cloudflare, así que el cambio de origen no depende de la caché de los resolvers. El detalle está en cómo poner Cloudflare delante del hosting sin cortar el correo.
Manejo del correo durante la ventana
Por qué el correo se corta
El MX indica a qué servidor entregar los mensajes. Si lo cambias antes de crear los buzones en el destino, los correos rebotan o quedan en un buzón que nadie revisa.
Opción A: el correo se queda donde está
Es la opción recomendada si tu correo está en un proveedor externo. No tocas MX, DKIM ni DMARC. Cambias el A y el certificado. Solo revisa el SPF si el sitio envía correos desde el servidor nuevo.
Opción B: migrar buzones por IMAP y cambiar el MX al cierre
Si el correo vive en el hosting viejo:
- Crea las cuentas en el destino.
- Sincroniza los buzones por IMAP (imapsync o la herramienta del panel).
- El día del corte, haz una segunda pasada y cambia el MX.
- Mantén el servidor viejo recibiendo hasta que expire el TTL y haz una última sincronización para rescatar lo que llegó ahí.
Calcula el espacio antes: cuántas cuentas y cuánto espacio necesita tu correo.
Ventana de corte: cuándo y cuánto
Día y hora
Una referencia habitual es martes o miércoles de madrugada, hora de Chile. Confírmalo con la analítica de tu sitio. Evita lunes, viernes, fin de mes y campañas activas.
Plan de ejecución
| Hora | Acción |
|---|---|
| H-1 día | Congelar cambios de contenido y plugins |
| H-30 min | Último respaldo y segunda sincronización de correo |
| H-0 | Cambio de DNS |
| H+15 min | Primera verificación completa |
| H+2 h | Revisión de logs y correo |
Si el sitio tiene tienda online, congelar 24 horas no es gratis: deja de entrar pedidos. Para esos casos, pon la tienda en modo mantenimiento 15 a 30 minutos antes del corte y haz un volcado final solo de la base de datos, en vez de congelar el día completo.
Define el tope antes de empezar. Si a las dos horas quedan problemas abiertos, reviertes. No se improvisa de madrugada.
Verificación después del corte
Pruebas de la web
Hazlas desde fuera de la red del hosting: home, dos páginas internas, un formulario enviado de verdad, el login del panel y una URL con https. Confirma que el navegador muestre el certificado nuevo.
Pruebas de DNS
Consulta resolvers públicos, no el DNS de tu computador:
dig +short A tudominio.cl @1.1.1.1
dig +short MX tudominio.cl @8.8.8.8
dig +short TXT tudominio.cl @1.1.1.1
La IP tiene que ser la del hosting nuevo. Si un resolver todavía entrega la vieja, es caché: espera a que venza el TTL.
Pruebas de correo
Envíate un correo desde una cuenta externa y respóndelo. En las cabeceras, SPF, DKIM y DMARC tienen que aparecer en pass. Si alguno falla, el correo puede ir a spam o ser rechazado, según la política DMARC del dominio.
Monitoreo durante 48 horas
Deja un monitor externo apuntando al dominio y revisa los logs de errores cada mañana. Cuando el tráfico esté estable, devuelve el TTL al valor anotado.
Cuándo revertir
Criterios concretos
Revierte si la web cae más de 15 minutos seguidos, si el certificado da error en el dominio real o si deja de llegar correo. Estos umbrales se acuerdan antes de la ventana con quien decide en la empresa, no a las tres de la mañana.
Cómo revertir
Vuelve a los valores anotados de A, AAAA, CNAME y MX. Mantén el TTL bajo para que la reversión se vea rápido, y restaura el original cuando todo esté estable. En Cloudflare, devuelve la IP anterior en el registro. Por eso se anota todo antes: revertir es pegar un valor y esperar unos minutos de caché.
Qué no es motivo de reversión
Si el sitio está lento o el CSS se ve raro, casi nunca es el hosting. Suele ser la caché de WordPress, un plugin o el CDN, y se corrige en el destino con el sitio funcionando. Si el problema es de rendimiento, revisa cómo identificar por qué tu WordPress está lento.
Errores que más cortan una migración
- Cambiar MX y A a la vez: si algo falla, no sabes qué deshacer.
- No bajar el TTL antes: el corte se alarga lo que dure el TTL original.
- Emitir el SSL después del cambio de DNS: los primeros visitantes ven una advertencia.
- Apagar el servidor viejo el mismo día: te quedas sin reversión.
Lo que evita la caída es la lista escrita, el TTL bajo y el servidor viejo encendido hasta que el nuevo responda bien.
¿Necesitas ayuda para migrar tu sitio?
Cuéntanos qué sitio quieres trasladar con su plataforma, cuántas casillas de correo usas y la fecha que tienes en mente. Si prefieres que la ejecute nuestro equipo, revisa hosting para empresas y hosting para WordPress administrado, y pide que la propuesta detalle la ventana de corte y las responsabilidades de cada parte.