当测试邮件到达管理员的收件箱时，邮件平台迁移尚未完成。应用程序仍然必须创建正确的通知，通过预期的路线提交通知，处理故障并到达所需的收件人。围绕这些结果制定过渡计划，以便重要的消息不会在应用程序和邮件团队之间消失。
清点每个通知依赖项
记录应用程序作业、触发器、计划、受众、关键性、所有者、端点、身份验证方法、发件人身份、重试队列和退回处理目标。包括网络访问、证书、凭据引用和DNS依赖项，而无需复制机密。区分邮件生成和邮件传输；停止的调度程序无法通过更改来修复 SPF.
提供者方法不同。 Microsoft 将经过身份验证的客户端提交、 SMTP中继和直接发送视为不同的选择，具有不同的先决条件和收件人范围。 Microsoft 应用程序邮件指南。根据应用的实际能力和目的地要求选择当前支持的路由。不要假设邮箱许可证或MX更新会迁移其提交配置。
设计共存，无重复工作
对于每个依赖项，命名新旧路由、谁可以切换它以及如何恢复它。决定共存期间哪个调度程序具有权威性。保留旧路由进行回滚并不意味着两个调度程序应该发出相同的通知。使用应用程序级事件标识符来协调应用程序支持的尝试，同时认识到标识符本身并不能保证SMTP重复数据删除。
保持并行权限的范围狭窄且有时间限制。新路由需要经过身份验证和一致的身份，而不仅仅是任何提供商签名。 RFC 9989。保留必要的签名密钥并 选择器 根据退休计划仍在传输的消息的可用性。
调查重复尝试和不完整的痕迹
假设一个接收事件在共存期间有两次提交尝试，而不同的接收通知没有对应的应用触发记录。首先需要调度程序和重试调查；两次尝试并不能证明两条已传递的消息。第二个需要跟踪重建或显式日志记录间隙，而不是发明的应用程序事件。在选择纠正措施之前，将路线、时间戳和收件人证据关联起来。
这些是假设的观察结果，不是提供的账本或执行的支票。保留旧路由以进行授权恢复，而不允许两个调度程序生成相同的事件。在宣布接受之前，收集应用程序生成、预期提交、实际接收者观察和支持的故障处理测试作为单独的证据。看起来完整的表格无法证明未经测试的应用程序。
测试整个路径
使用批准的收件人和代表模板。正常触发应用程序，保留其事件 ID 和作业日志，检查提交或中继证据，并捕获目标接收到的消息。检查预期内容和最终接收者身份验证结果。记录测试时间和路线，以便共存不会掩盖哪个系统提供了测试。
在测试环境支持的情况下，练习瞬时提交失败、重试行为和允许的无效收件人情况。确认谁接收并处理退回邮件。分别检查内部和外部目的地。已接受的SMTP事务仍可能发生传送失败；成功的接收者测试并不能验证应用程序的故障处理。
在旧服务退役前导出证据
通过定义的保留决策保留授权的配置基线、依赖关系图、队列状态、测试结果和相关操作日志。检查旧平台访问结束后证据是否仍然可读。仅导出需要的内容，并将凭据保留在包之外。
设定明确的退出标准：执行关键的预定作业、控制重复风险、审查接收者证据、确认退回处理以及测试旧路线回滚或由负责任的所有者有意识地放弃。如果每月作业尚未运行，请记录该差距，而不是称迁移完成。在旧的授权和端点的依赖关系关闭后，通过批准的变更控制来淘汰旧的授权和端点。