邮件迁移不像换一台服务器，它涉及域名解析、历史邮件、客户端配置和全员使用习惯。做得好，用户几乎无感；做得糙，投诉会持续两周。
一、先把现状摸清
- 账号数量与活跃度，是否存在长期未使用账号
- 邮箱容量与历史邮件总量，据此估算迁移时间
- 现有客户端类型与配置方式
- 是否有共享邮箱、邮件组、别名、自动转发规则
- 是否与业务系统集成（如系统发信、工单通知）
最后一项最容易被漏掉。业务系统的发信配置不改，切换后通知邮件会全部失败。
二、数据同步与切换解耦
正确做法是"先同步数据，再切换解析"：
- 用工具把历史邮件同步到新系统，期间老系统继续服务
- 反复做增量同步，直到差异收敛到分钟级
- 确认数据完整后，再切换域名解析
三、灰度验证
| 阶段 | 范围 | 验证点 |
|---|---|---|
| 小范围 | IT 部门 3–5 人 | 收发、附件、客户端、移动端 |
| 扩大 | 一个业务部门 | 邮件组、共享邮箱、日历 |
| 全量 | 全体员工 | 性能、反垃圾效果、发信成功率 |
留意发信信誉
新系统的 IP 若未做发信配置与信誉预热，邮件可能被对方退回或判为垃圾。切换前先做小批量外发测试。
四、切换与过渡期
- 切换安排在非工作时段，提前发布通知
- 保留老系统只读访问一段时间，便于查询历史邮件
- 过渡期内设置专人值守，集中处理客户端配置问题
- 明确过渡期结束时间与数据归档方案
五、迁移后的收尾清单
更新账号台账、更新业务系统发信配置、更新客户端配置说明、回收老系统权限、完成一次安全基线检查（SPF、DKIM、DMARC 配置到位）。迁移的完成标准不是"邮件能收了"，而是"该改的地方都改了"。
#邮件系统#系统迁移#切换方案#运维事业部
