Durante una migración, los resolvers pueden conservar la respuesta anterior hasta que expire el TTL publicado. El tráfico dividido también puede continuar por un AAAA o www sin actualizar, nameservers inconsistentes, archivo hosts o un origen antiguo en la CDN.
Protege primero las escrituras: dos bases de datos activas pueden divergir aunque ambas webs parezcan normales.
Demuestra qué servidor respondió
Añade temporalmente una cabecera de diagnóstico segura o un marcador estático distinto en cada servidor y prueba desde las redes afectadas.
Registra:
hostname solicitado
resolver utilizado
respuesta A y AAAA
marcador del servidor
certificado TLS
fecha, hora y zona horariaNo expongas públicamente nombres internos, versiones o IPs más tiempo del necesario.
Consulta los registros autoritativos
Confirma la delegación del registrador y consulta directamente al proveedor autoritativo. Revisa raíz, www, wildcard, A, AAAA y CNAME.
Si cambiaron los nameservers, también influyen el TTL de la delegación padre y las cachés. Editar el proveedor antiguo ya no tiene efecto cuando la delegación se ha movido.
No alternes repetidamente entre valores: cada cambio crea otra población de caché.
Calcula la ventana real
Utiliza el TTL que estaba publicado antes del cambio, no el valor reducido posteriormente. Un resolver puede conservar la IP anterior durante el tiempo restante de aquel TTL.
Algunos resolvers aplican mínimos. El navegador, sistema operativo, service worker y CDN añaden capas separadas. Documenta el máximo esperado y consulta varios resolvers; un verificador global solo ofrece una muestra.
Revisa IPv6 y subdominios
Un AAAA antiguo afecta a usuarios IPv6 aunque el A sea correcto. www, idiomas o administración pueden apuntar aparte.
Prueba A y AAAA con hostname y SNI reales. Actualiza o retira registros web que ya no se usen, pero no borres MX o TXT de correo mientras modificas el DNS. Conserva inventario y rollback.
Congela o puentea las escrituras
Mientras exista tráfico dividido, deja el sitio antiguo en solo lectura o mantenimiento, o usa un proxy seguro hacia el nuevo servidor cuando sea viable.
No uses una redirección HTTP para webhooks de pago: puede perder método, cuerpo o firma. Conserva base de datos, archivos y registros antiguos e identifica entradas, usuarios, formularios y operaciones creadas en cada lado.
Evita sobrescribir finalmente la base nueva con una copia antigua.
Reconcilia los datos divergentes
Define la hora de corte y compara IDs o referencias estables. Fusiona mediante exportaciones o API conscientes de la aplicación y un procedimiento ensayado.
Los uploads y sus adjuntos de base de datos deben viajar juntos. Los correos o pagos externos no se revierten copiando WordPress.
Registra cada elemento reconciliado y bloquea nuevas escrituras durante la fusión final.
Protege callbacks externos
Proveedores de pagos, formularios, SMTP y API pueden resolver DNS de manera independiente y reintentar durante horas. Inventaría webhooks y comprueba qué servidor los recibe.
Actualiza directamente el endpoint cuando el proveedor lo permita. No dependas de 301 o 302 para POST firmados. Mantén logs y un handler o proxy seguro durante toda la ventana de reintentos.
Controla la exposición a buscadores
El servidor antiguo puede indexarse mediante un hostname de vista previa. Mantén canonical, noindex o controles de acceso coherentes sin bloquear producción.
No solicites retirar el dominio real porque un resolver esté obsoleto. Comprueba el rastreo al converger y redirige solo los hostnames retirados.
Revisa CDN y overrides locales
Cloudflare puede tener el DNS correcto y continuar enviando al origen antiguo. Inspecciona pools, reglas de origen y cabecera Host.
Elimina entradas hosts, VPN, DNS privado y variables antiguas después de probar. No purgues todo antes de capturar evidencias: las cabeceras ayudan a identificar la capa.
Completa y monitoriza el corte
Mantén el servidor antiguo online pero sin escrituras durante el TTL, la caché CDN y los reintentos externos. Vigila sus logs hasta que el tráfico desaparezca.
Prueba web pública, administración, correo, cron y callbacks en el nuevo servidor. La propagación DNS es previsible; lo peligroso son las escrituras dobles sin plan.