看起来你正处理一个高优先级的Azure Front Door迁移项目——要把分散在AFD Premium和FD Classic的自定义域名迁到全新AFD，还要兼顾后端网络隔离，同时必须做到近乎零停机，而且当前环境用的是微软托管SSL+TXT域名验证对吧？我之前帮几个 enterprise 级高流量客户做过完全一样的迁移，分享下实操步骤和避坑点：

一、预迁移准备：提前完成配置同步与SSL预验证 #

• 先在新AFD里1:1复刻旧实例的核心配置：包括路由规则、WAF策略、缓存规则、自定义域名的重定向/转发设置等。可以用Azure CLI快速导出旧配置再适配新AFD参数，比如用az afd profile show导出旧AFD Premium的配置，再用az afd profile create+az afd route create批量创建新规则，避免手动配置出错。
• 把所有待迁移的自定义域名添加到新AFD，选择微软托管SSL并触发TXT验证。这里一定要提前30分钟到1小时做这一步：因为TXT验证记录可以和旧实例的验证记录共存，不会影响当前服务，等新AFD的SSL证书完全颁发生效后，再进入流量切换环节，这是零停机的关键前提。

二、零停机流量切换实操步骤 #

• 先做小流量验证：在域名解析服务商处添加一条测试域名记录（比如staging.yourdomain.com）指向新AFD的前端端点，用浏览器、curl或负载测试工具验证路由、缓存、SSL握手、后端连通性都和旧环境一致，确认新AFD配置完全没问题。
• 调整DNS TTL：提前1-2天把主域名的DNS记录TTL改成300秒（5分钟），这样后续切换DNS后，全球DNS缓存会快速更新，减少旧端点的流量残留时间。
• 正式切换DNS：如果原域名是CNAME指向旧AFD/FD Classic端点，直接把CNAME值替换为新AFD的端点域名；如果是A记录，就替换为新AFD的前端IP地址。切换后持续监控新AFD的流量指标和旧实例的流量衰减情况，直到旧实例流量完全归零。

三、核心避坑细节 #

• SSL验证冲突问题：新AFD的TXT验证记录和旧实例的记录可以同时存在，不需要删除旧记录，直到新环境稳定运行24小时后再清理，避免中间出现SSL证书失效的情况。
• 后端网络隔离适配：因为新后端和旧后端是网络隔离的，必须提前把新AFD的前端IP段加入新后端的防火墙/NSG白名单。可以用az afd frontdoor list-endpoints获取新AFD的所有前端IP，然后批量添加到白名单。另外，建议用curl模拟新AFD的请求头（带上X-Azure-FDID头）测试后端连通性，确保不会出现503错误。
• 高流量场景渐进式切换：如果是超大流量客户，不要一次性切100%流量，先切10%流量到新AFD，监控1-2小时无异常后，逐步提升到50%、80%，最后到100%。这样即使出现问题，也能快速把DNS切回旧实例，影响范围极小。

四、回滚方案兜底 #

只要旧AFD/FD Classic的域名配置、SSL绑定和DNS记录不删除，随时可以把主域名的DNS改回旧端点，几分钟内就能恢复全部服务。建议等新环境稳定运行24小时以上，再彻底清理旧实例的相关资源。