El cambio DNS debe exponer una web ya demostrada en su nuevo servidor. No es el momento de descubrir uploads ausentes, PHP incompatible o un checkout roto. Prueba con el hostname real y conserva una ruta de rollback clara.
Registra DNS y propietarios actuales
Exporta o captura A, AAAA, CNAME, MX, TXT y CAA autoritativos con sus TTL. Confirma quién controla registrador, DNS y Cloudflare. Identifica DNSSEC antes de cambiar nameservers.
No recrees únicamente los registros web. Autenticación de correo y verificaciones de servicios se omiten con facilidad.
Confirma el estado final de la migración
Establece una congelación o un delta final. Compara entradas, usuarios, formularios o pedidos recientes entre origen y destino. Transfiere archivos creados tras la primera copia.
Crea una copia previa al corte en ambos lados y registra ubicación y hora.
Prueba el hostname contra la IP nueva
Usa hosts o una petición que conserve Host y SNI:
curl -I --resolve example.com:443:203.0.113.20 https://example.com/Prueba raíz y www, HTTP y HTTPS, e interiores importantes. Navegar solo por IP puede seleccionar otro virtual host.
Valida TLS y redirecciones
Confirma que el certificado cubre cada hostname público y lo sirve el origen nuevo. Revisa toda la cadena hasta un único destino canónico sin bucles.
Si Let’s Encrypt necesita DNS público, planifica la emisión y qué recibirán los visitantes durante el intervalo. No desactives HTTPS sin una ventana y reversión definidas.
Ejercita rutas críticas
Verifica login, editor, medios, búsqueda, enlaces, REST, cron, formularios y correo. Prueba transacciones críticas mediante sandbox aprobado y revisa logs PHP y web.
Comprueba robots, canonical y sitemaps con URLs de producción. Retira restricciones de staging solo cuando el lanzamiento sea intencionado.
Inventaría callbacks externos antes del corte: pasarelas, formularios, CRM, licencias, APIs, copias y monitorización pueden conservar una IP, URL de staging o allowlist del servidor anterior. Actualiza únicamente los que dependan del origen y realiza una prueba con identificadores rastreables. Un webhook firmado no debe validarse mediante una redirección genérica.
Revisa el correo por separado
Conserva MX si los buzones no se mueven. Verifica que SPF, DKIM y DMARC autorizan el servicio de envío y prueba SMTP saliente desde el servidor nuevo.
Cambiar el A normalmente no exige cambiar MX. Sin embargo, un MX que apunta al dominio raíz merece revisión porque su IP cambiará. Guarda el message ID de la prueba.
Comprueba proxy y caché
Si interviene Cloudflare, confirma IP de origen, modo SSL, exclusiones de caché y acceso del firewall. Purga únicamente cuando el destino esté listo.
Revisa A y AAAA. Un IPv6 antiguo envía solo a algunos usuarios al servidor anterior y genera fallos aparentemente intermitentes.
Define criterios de corte y rollback
Escribe registros exactos, responsable, periodo de observación y disparadores medibles para volver atrás. Mantén el hosting antiguo intacto y preferiblemente en solo lectura.
No mezcles el corte con cambios de diseño o plugins. Baja el TTL con antelación; hacerlo justo antes no modifica respuestas ya cacheadas.
Monitoriza después del cambio
Consulta varios resolvers públicos y observa tráfico real, estados, errores PHP, certificado y eventos de aplicación. Compara logs de origen para saber cuándo se mueve el tráfico.
Vigila formularios, correo y cron, no solo uptime. Algunos usuarios conservarán legítimamente el DNS anterior hasta agotar el TTL.
Cierra la migración con cuidado
Tras la observación, reconcilia escrituras que llegaran al sitio antiguo, aumenta el TTL si corresponde y elimina accesos temporales. Conserva el entorno anterior durante el periodo de rollback antes de cancelarlo.
El mantenimiento debe guardar exportaciones DNS, alertas de certificados y un checklist actual. Un cambio controlado es reversible, observable y deliberadamente aburrido.