本页目录
为什么可以做到"不停机"一、完整时间表：从准备到收尾二、切换当天：按顺序做完这几件就稳了三、三样东西会不会跟着走四、最常卡住的四个地方五、万一出问题：兜底与回切大概要花多久价格按账号数算，与迁移进度无关常见问题把账号数和邮件量告诉顾问，先出一版迁移排期为什么可以做到"不停机"
原理其实很朴素：先把新邮箱搭好、把历史邮件搬过去，最后才动域名解析（DNS）这一个开关。
在切换之前，所有人的收发邮件一切照旧，业务完全不受影响；真正"敏感"的只有解析切换后的那几个小时——而这段时间里，新旧两套邮箱都还活着，邮件不会凭空消失。
所以"会不会停机"这个问题，答案取决于两件事：历史数据是不是提前搬完了、解析切换是不是放在业务低峰。这两件做对，用户基本无感。
一、完整时间表：从准备到收尾
下面这张表按"相对日期"列，T 就是切换解析的那一天，照着排即可；表中"谁来做"一栏，是我们与阿里云官方工具的常见分工，具体以双方确认的实施清单为准。
| 时间 | 要做的事 | 产出的东西 | 谁来做 |
|---|---|---|---|
| T-7 ～ T-5 | 盘点账号清单与数据量（邮件数、通讯录、日历） | 账号对照表 | 我方协助梳理 |
| T-5 ～ T-3 | 开通新邮箱、绑定域名、配置 SPF/DKIM/DMARC | 解析记录清单 | 我方协助 + 阿里云官方工具 |
| T-3 ～ T-1 | 历史邮件批量迁移（可分批，期间旧邮箱照常收发） | 迁移进度与结果清单 | 官方迁移工具为主 |
| T-1 | 全员通知、客户端预留新配置、确认低峰切换窗口 | 上线通知与操作指引 | 客户方 + 我方 |
| T（切换日） | 切换 MX 解析，观察收发与退信（见下一节逐项动作） | 切换记录 | 我方协助 |
| T+1 | 全量抽检收发、检查发信信誉与退信情况 | 抽检记录 | 我方协助 |
| T+3 | 通讯录与日历二次同步、旧邮箱设置来信转发 | 同步清单 | 客户方操作 + 我方协助 |
| T+7 | 旧邮箱降级保留、只保留来信自动转发，进入观察期 | 保留期确认单 | 我方协助 |
| T+14 | 观察期结束、旧邮箱按约定退订或留档，迁移收尾 | 迁移结项清单 | 双方确认 |
二、切换当天：按顺序做完这几件就稳了
切换日只需要关注"解析生效"这一件事，其余都是围绕它做确认。建议按顺序执行：
确认前置条件
历史邮件已迁完、新邮箱能正常登录收发、SPF/DKIM/DMARC 记录已就位。任一项没完成，不要动解析。
选择切换窗口
优先放在下班后或周末，避开对外的业务高峰；避开月底月初的财务邮件高峰期。
切换 MX 解析
按服务商给出的记录值替换原 MX 记录，做到"一次改完、不改第二遍"，避免解析反复。
立即验证收信
用外部邮箱（如个人邮箱、客户域名邮箱）向新邮箱发一封测试信，确认能收到。
验证发信
从新邮箱向外发信，确认收发正常且不进入对方垃圾箱；检查退信与发信信誉。
全员客户端确认
按通知指引完成客户端配置，重点确认手机端能正常收发。
保留旧邮箱转发
在旧邮箱设置来信自动转发到新邮箱，作为漏收的兜底，至少保留一段时间。
三、三样东西会不会跟着走
迁移前把这三点讲清楚，能避免绝大多数纠纷：
| 项目 | 能否迁移 | 怎么做 | 注意事项 |
|---|---|---|---|
| 历史邮件 | 能，且是迁移主体 | 按账号批量导入到新邮箱对应文件夹 | 迁移量大时耗时长，可分批；迁移期间旧邮箱继续可用 |
| 通讯录 | 能 | 通过官方工具或标准格式（CSV / vCard）导入 | 个人通讯录与组织通讯录分开处理，避免覆盖 |
| 日历 / 日程 | 多数可以 | 按标准格式导出再导入；共享日历需重建权限 | 共享日历、会议室资源的权限关系通常需要重新配置 |
| 旧邮箱设置（规则 / 签名 / 自动回复） | 需要手工重建 | 导出旧规则清单，在新后台逐条重建 | 过滤规则、自动转发等无法批量直迁，需单独核对 |
四、最常卡住的四个地方
从实际迁移看，卡点高度集中，提前准备即可消化：
- 卡点一：迁移前没有留"数量底账"
- ['迁移最怕被问"到底有没有丢"，而唯一能回答这个问题的，是迁移前后的账号数与邮件总数对照表。这件事必须在动手前就做好。']
- 卡点二：客户端缓存导致的"看起来坏了"
- ['切换后不少人反馈"收不到信"，实际是客户端仍在连旧服务器。处理办法很简单：先让用户退出并重建账号配置，再排查真实问题。']
- 卡点三：SPF / DKIM / DMARC 没配好就切
- ['解析切换和新邮箱的发信信誉配置是两件事。信誉记录没配好就切，容易出现"信发出去了但进了对方垃圾箱"。这一步建议在切换前完成并验证。']
- 卡点四：旧邮箱退得太早
- ['急于把旧邮箱停掉，会让"漏收"变成永久丢失。正确做法是让旧邮箱带转发保留一段时间，观察期结束再退。']
五、万一出问题：兜底与回切
这是多数服务商不写、但客户最关心的一段。我们把它讲明白：
- 原邮箱不做破坏性操作。 迁移期间不对旧邮箱做清空或退订，旧邮件始终保留在原处，随时可对照。
- 解析可回切。 如果切换后确认新环境不可用，把 MX 记录改回原值即可恢复收信，这也是我们建议"低峰切换 + 保留旧邮箱"的原因。
- 结果可核对。 迁移完成后提供迁移结果清单（账号数、邮件数、抽检记录），而不是一句"迁完了"。
- 分批复核。 体量大的单位建议按部门分批迁移，每批验收通过再推进下一批。
一句实话：
我们不会承诺"零丢失"这种无法自证的话。更可靠的做法是——把核对方法、回切路径和兜底安排提前写在方案里，让每一步都看得见。
大概要花多久
时间长短取决于两件事：账号数和历史邮件总量。经验上：几十人的团队通常在一周内可以完成主体迁移，上百人、历史邮件量大的单位一般需要两到四周，其中大部分时间花在历史数据的搬运与抽检上。真正需要"盯着"的只有切换日那几小时。
如果你能提供账号数和大致邮件量，我们可以先给一版排期。
价格按账号数算，与迁移进度无关
邮箱本身按账号数计价，与迁移批次、迁移次数无关。以标准版为例：5-10 人档 120 元/账号/年（5 账号即 600 元/年）、50-99 人档 105 元/账号/年、100-199 人档 95 元/账号/年、1000 人以上档 60 元/账号/年；AI 尊享版同规模分别为 180、165、155、120 元/账号/年。具体金额可以直接用价格页的计算器按人数算。
常见问题
Q: 迁移期间会漏收邮件吗？
按正确顺序做不会。历史邮件在切换前搬完，切换前收发一切照旧；切换后新旧邮箱都保留，并在旧邮箱设置来信自动转发作为兜底。真正需要关注的是切换后那几小时的解析生效时间，建议放在业务低峰。
Q: 迁移大概要停多久？
正常做法不需要停机。需要"盯"的只有解析切换后的几小时，且即便这段时间出现异常，也可以把解析改回原值恢复。历史上多数客户的员工端体验是"换了个登录方式"，而不是"断了一段时间"。
Q: 以前的邮件、通讯录、日历能一起搬过去吗？
历史邮件和通讯录可以迁移；日历多数也可以，但共享日历与会议室资源的权限关系通常需要重建。另外，旧邮箱里的过滤规则、自动转发、签名等设置一般无法直迁，需要在新后台逐条重建。
Q: 原来的 @公司域名 邮箱地址能保留吗？
能。邮箱地址由域名决定，域名不变、地址就不变，所以切换对客户和往来伙伴是无感的。真正变化的是"邮件由哪一台服务器接收"，这一步通过修改 MX 解析完成。
Q: 万一迁移出问题，能不能换回去？
可以。只要迁移期间不对旧邮箱做清空或退订，把 MX 解析改回原值就能恢复原来的收信路径。这也是我们坚持"低峰切换 + 旧邮箱带转发保留观察期"的原因——留一条退路，比承诺万无一失更实在。
把账号数和邮件量告诉顾问，先出一版迁移排期
我们提供迁移方案设计、历史邮件搬运、解析切换与抽检复核的全程协助。
联系顾问免费咨询 →15分钟出方案 · 无需绑定 · 同品质更优惠