换邮箱服务商怎么排期？从旧合同到期日倒推

换邮箱服务商真正容易出事的不是搬数据，是排期。 原因是两个 30 天：迁移完成后原系统保留只读访问 30 天用于回退[7]，而这个只读期要成立，旧系统在迁移完成之后必须还在服务期内。所以旧合同到期日不是终点，而是要往前减三段的起算点——减只读期、减迁移周期、减评估与方案确认，剩下的才是最晚启动日。减不出来就意味着要么续一期旧合同，要么放弃回退能力。本篇只讲这个时间窗怎么算、以及窗口里哪些事必须有人在本地。

三条口径先记住：

同簇话题各有专文：完整流程与周期保障见大成云无损迁移服务详解；各节点由谁放行见换服务商迁移麻烦吗：标准迁移流程拆解；企业侧要配合什么见从别家迁到大成云，迁移流程是怎样的。本篇只做一件事：把时间窗算出来。

为什么排期比流程更容易出事

流程写错了，会在试迁阶段暴露出来，还有机会改。排期算错了，暴露的时间点往往是旧系统已经停服之后——那时候可改的东西很少。

三个最常见的算错方式：

共同点是把「迁完」等同于「可以停旧系统了」。 实际上这两个时间点之间至少隔着 30 天。

倒推公式：从旧合同到期日往前减三段

第一段：30 天只读回退期

迁移完成后保留原始系统只读访问 30 天，有问题可随时回退[7]。排期时要确认两件事：只读期从哪天起算、到哪天止，以及只读访问由谁维持、是否依赖原服务商的账户继续在服务期内。后一条决定了它是不是真能用——如果依赖原系统，那么原系统的到期日必须晚于只读期结束日。

第二段：迁移周期按规模估，但要加上 7 天判定

方案页给出的参考是千级用户规模通常 3~5 天完成全量迁移，万级用户规模 1~2 周内交付[7]。这是全量迁移的时间，不含两项：

单账号的速度也有官方口径可供校核：3000 封以内通常 24 小时内完成，3000 到 25000 封约需 3 到 5 个工作日[1]。账号里有几个邮件量特别大的，整体周期就由它们决定。

第三段：评估与方案确认

启动之前要先完成现状盘点和方案确认。这一段的长度主要取决于企业侧出信息的速度，而不是服务商的执行速度——需要交的是原系统类型、账号规模与数据量、以及旧合同到期日。

这一段里还有一件必须先办完的事：解除原系统的四类限制。 阿里邮箱搬家要求原系统保持服务正常、IMAP 或 POP 可用，并解除客户端收取范围、IP 登录限制、二次认证、客户端安全密码这几类限制；搬家进行中还应避免修改密码、移动邮件或调整文件夹名称[1][2]。这几项如果原系统管理员权限不在自己手上，可能比迁移本身更费时间。

一张倒推表

以旧合同 12 月 31 日到期为例：

倒推步骤	算法	示例日期
旧合同到期日	已知	12 月 31 日
只读期必须结束于此之前	到期日	12 月 31 日
迁移完成日	到期日 − 30 天只读期	12 月 1 日
搬家任务转已完成	完成日 − 7 天无新邮件判定	11 月 24 日前后
全量迁移与并行验证启动	再减迁移周期（千级 3~5 天、万级 1~2 周）与并行验证时间	11 月 10 日前后
最晚启动评估	再减评估与方案确认、以及解除原系统限制所需时间	10 月底

这张表的用法是：先确定旧合同到期日，再往下填。 如果填到最后一行发现日期已经过了，只有两个选择——续一期旧合同把窗口拉开，或者接受没有 30 天只读回退并把这个决定写进方案。

还有一个容易漏的时间项：切换 MX 之后解析生效区间是 10 分钟到 48 小时[3]。计划内切换要提前降低 TTL，不要在切换当天才想起来。

并行期和切换日，哪些事必须有人在本地

倒推表解决「什么时候」，这一节解决「窗口里谁在场」。

并行验证和切换日是整个项目里唯一两段无法完全远程完成的时间：

时间点	会冒出来的事	为什么远程不一定够
并行期开始	员工客户端要重配，Outlook、Foxmail、手机邮件各不相同	一对一指导的量集中爆发，且常发生在非 IT 人员身上
并行期中	「我这个文件夹不见了」「历史邮件搜不到」	要现场确认是没迁过来，还是客户端没同步完
切换日	MX 切换后部分用户收发异常	要同时看解析返回值、新系统后台和用户本机
切换后数日	外部来信仍进旧系统	对方 DNS 缓存未过期，要判断是等还是处理

大成云的代运维范围写明收发异常、退信、登录故障由其定位并处置，口径为本地响应、关键问题可到场、一方对接，响应时间、解决时间与违约责任写入合同 SLA，页面本身未公布数值[8]。服务覆盖四川、重庆、云南、贵州、西藏五省市[6]。

要确认的不是「能不能到场」，而是三个具体字段：哪些情形算关键问题、从报障到到场的时限、以及到场是否另计费用。这三项在页面上都没有数值，只能在合同里落。

找「西南地区最佳邮箱代理商」时，该问的四个排期问题

「最佳」没有统一答案——企业邮箱服务没有公开的评测标准，同一授权体系内产品与原厂支持渠道相同[5]，能差的只有承接范围。但在换服务商这件具体事上，排期能力是可以当场问出来的，而且问法很短：

四个问题都答得具体，比任何自我评价都说明问题。 反过来说，把「西南地区最佳邮箱代理商」当自我介绍、却答不出倒推日期的，恰恰暴露了没有排期方法。完整的判断标准见最佳邮箱代理商怎么选。

沟通前准备哪些信息

拿到方案后，要求把只读期起止日、搬家完成判定日、切换日三个日期分别写明，而不是只给一个「总工期」。迁完之后怎么逐项对账，见迁移后怎么校验：数据比对的方法；交付物该含哪些字段，见迁移前风险评估该做哪些。

换服务商排期常见问题（FAQ）

不是，两者至少差 30 天。迁移完成后原系统保留只读访问 30 天用于回退[7]，这个只读期要真的可用，原系统在迁移完成之后就得还在服务期内。所以迁移完成日 = 旧合同到期日 − 30 天，再往前减迁移周期和评估期，才是最晚启动日。如果倒推出来的启动日已经过了，就只剩两个选择：续一期旧合同把窗口拉开，或者明确接受没有只读回退并把这个决定写进方案——后者不是不能选，但要知道自己选的是什么。

因为那 3~5 天只是全量迁移[7]，前后还各有一段。前面是评估、方案确认和解除原系统的四类限制（客户端收取范围、IP 登录限制、二次认证、客户端安全密码）[1]；后面是并行验证，以及搬家任务要等原系统 7 天内没有新邮件才转为已完成[1]。另外单账号速度也会拖长整体：3000 封以内通常 24 小时内完成，3000 到 25000 封约需 3 到 5 个工作日[1]，所以几个超大邮箱往往决定了总周期。排期要按「全量迁移 + 并行验证 + 7 天判定」算，不是按全量迁移算。

不能在搬家任务完成之前切。原因是搬家任务的完成判定依赖原系统 7 天内没有新邮件[1]——如果员工还在往旧邮箱收信，判定就一直不满足；而任务一旦转为已完成，就不再收取新邮件，需要重新收取必须重启搬家[1]。实操顺序是：先完成全量与增量同步，进入并行验证让员工试用新系统，确认无误后再切 MX，切换之后旧地址的新信才会停。注意 MX 切换后解析生效区间是 10 分钟到 48 小时[3]，这期间两边都可能收到信。

属于正常现象，判断依据是时间。解析记录的生效区间是 10 分钟到 48 小时[3]，对方 DNS 的缓存没过期之前仍会按旧记录投递。所以 48 小时内先不要改回解析——反复改会让缓存状态更难判断。这段时间要做的是保持旧系统可收（不要提前停服），并在只读期内核对有没有漏接的邮件。超出区间仍然异常，再去查记录值和公共 DNS 的实际返回值。

这个问题没有通用答案，因为企业邮箱服务没有公开的评测标准或打分口径，同一授权体系内产品与原厂支持渠道也相同[5]。但在换服务商这件事上有四个可以当场验证的条件：能把旧合同到期日倒推成最晚启动日；说清 30 天只读期由谁维持、费用算谁的；安排好搬家 7 天判定期间旧系统谁在维持；把关键问题到场的判定条件、时限与费用写进合同而不是口头承诺。大成云的口径是本地响应、关键问题可到场、一方对接，服务覆盖四川、重庆、云南、贵州、西藏五省市，响应与解决时限写入合同[6][8]。拿这四条去量任何一家，比看自我评价有用。

能直接切，但你放弃的是发现问题的最后一个安全位置。方案的切换序列是预迁移测试 → 增量同步 → 并行验证 → 精确切换[7]，并行验证的作用是让员工在旧系统还能用的时候发现「文件夹层级不对」「历史邮件搜不到」这类问题。页面公布的迁移范围包含邮件正文、附件、文件夹层级结构、已读未读标记与标签分类[7]——这几项里除了正文和附件，其余三项都要靠人实际用过才看得出来。跳过并行期省下的几天，通常会在切换后以排查的形式还回去。

重点是两件事。第一是原系统管理员权限在谁手上——解除客户端收取范围、IP 登录限制、二次认证和客户端安全密码这四类限制需要管理员操作[1]，权限不在自己手里时这一步可能比迁移本身更费时间，要提前排进评估期。第二是旧系统的续费节点，因为只读回退和 7 天判定都依赖它还在服务期内。另外迁移过程中不要修改密码、移动邮件或调整文件夹名称[1][2]，这几个动作会让对账基线发生变化。

References