01 先算一个数：公司里有多少人靠邮箱接单
打开人事的名单，数一下过去 12 个月里，有多少岗位是「客户来信到了就得当天回」的。
10 个人的公司，答案经常是 6 个。
这个数决定了迁移要留多大的窗口。如果只有老板一个人用邮箱，周末一个下午就能切完；如果有 6 个人每天靠来信谈单，那就不只是技术活。
在谷歌上搜一遍公司名，看公开的联系方式里写的是哪个地址。再用 Chrome 打开自建邮箱的管理后台，看一眼当前的邮件量：最近 30 天收了多少封、发了多少封、附件占了多少容量。这三个数就是迁移工作量的下限。
先把这几个数记下来，再往下读。
02 为什么「找服务商搬过去」这句话不够
很多人对迁移的理解是：数据搬过去，域名解析改一下，完事。
数据那一半确实不难，多数服务商都能把历史邮件整批导过去。
难的是中间那几个小时。解析切换之后，新服务器开始生效，旧服务器还在收信，这中间收到的信如果没人管，丢了就是丢了——不是延后收到，是真的没有。
比这更常见的是一种安静的失败：切换那天没人通知，业务员上午发的报价客户没收到，回头才发现自己电脑上的发信设置指向的还是旧服务器。
迁移的风险不在技术，在「谁在这一天负责看住信箱」。这句话在谷歌那边同样成立：网站换服务器的时候，风险也不在搬家本身，在搬家当天有没有人盯着 Search Console。
03 判据：切换的那几个小时里，谁在收信
判断一次迁移做得好不好，别看导入了多少封历史邮件，看切换当天有没有安排人值守。
- 切换前：谁负责确认新旧两边都能收信，用哪个地址测
- 切换中：谁盯着旧服务器的收信队列，发现异常 10 分钟内通知谁
- 切换后：谁按发信日志逐条核对，找出那些点了发送但客户没回的信
这三件事必须写上具体的人名，不能写「技术部」。写上部门的结果是，事情发生时每个人都在等别人。顺带一个同类的做法：网站改版上线当天要在 Search Console 里盯抓取报错，谷歌那边的判据是有没有新增的抓取错误。
迁移窗口期的长度不取决于数据量，取决于你们能承受多久收不到信。
04 窗口期分三段，每段做不同的事
把切换前后拆成三段来安排，比笼统地说「周三晚上切」清楚得多。
停写前这一段，先做两件事：把所有客户端的发信设置截图存档，以及通知全员停止改密码——密码一改，旧系统上正在跑的同步任务就会失效。
切换中这一段，只改收信解析，其他都不动。这段时间要落在业务量偏低的时段，比如当地时间的夜间到凌晨 4 个小时。旧服务器保持开着，别急着停机。
切换后这一段，按发信日志逐条核对，重点是那些「发出去了但没有回复」的信。这段通常要留 2 到 3 天。
三段之间不要并行。并行做的好处是省半天，代价是出问题时说不清是哪一步出的。判断哪一段风险偏高，可以借用谷歌做站点改版的老规矩：动的面越大，回退越难。
05 解析怎么改：先收信，后发信
顺序是这一整件事里最不能省的一环。
先改收信记录，让新邮箱开始收信，这时发信还走旧通道。跑够 1 天之后确认收信正常，再改发信相关的记录。
反过来先改发信，会出现一个很别扭的状态：你发出的信带着新服务器的身份，但客户回信还进旧信箱，而来信在旧系统里已经没人看了。
收信先行的另一个好处是可以回退。新邮箱如果当天就出问题，把收信记录改回去，几分钟就能恢复，历史邮件也还在。
改之前把每一条记录抄在 1 张 Excel 里，包括改之前的原值和改之后的数值。改完用外发测试从公司邮箱发一封到 Gmail 和 WhatsApp 绑定的地址各一封，两个都能收到才算过。两封都收到之后，再去谷歌上搜一遍公司名，确认公开的联系页上写的还是能用的那个地址。
06 公告发几遍、写清哪两件事
公告这件事，发早了和发晚了都不行。
发早了没用。提前 1 周发，到切换那天没人记得。发晚了更糟——切换前 1 天通知，客户当天就来信问「你们是不是换邮箱了」。
合适的节奏是 2 遍。头一遍在切换前 3 天，说明哪天切、切换期间用什么方式联系；第二遍在切换完成当天，确认一切正常。第二遍很重要，它替客户省掉了「要不要重发一遍」的纠结。
公告里必须写清两件事：切换的具体时间，以及切换期间万一联系不上的备用通道，比如电话或者 WhatsApp。
对外的那一遍别群发。常联系的客户按联系人逐个发，群发的很容易被当成通知邮件跳过。发完在谷歌上搜一遍公司名，看联系页那行地址有没有跟着更新——客户联系不上人的时候，都是先去搜。
07 顺序：哪一步排前面
整件事的顺序如下，中间的每一步都不要和相邻步骤并行。
先做一次全量备份，包含所有历史邮件、通讯录和过滤规则。备份完成后抽样打开 2 封附件，确认附件完整——只备份不验证，等于没备份。
再改收信记录并观察 1 天。
接着改发信记录，改完立刻用收信方的退信数据看有没有批量退信。这件事 Search Console 看不到，它只管网站在谷歌上的收录，不管邮件往哪里走，两边的报告别混着看。
收尾处理旧服务器：先只读保留 30 天，确认没有遗漏的来信之后再下线。
顺序反了，糟糕的结果不是用户抱怨，是有一批客户来信在两台服务器之间的空档里消失了，你还不知道是哪些。
08 哪几类可以先不动
也说一句相反的，自建邮箱不是都必须搬。
邮箱里有必须留在内网的合规要求、且内网访问已经打通得不错的，可以先不搬。
使用人数在 10 个以内、邮箱只做收发通知的，搬家的收益有限，把备份和归档做扎实更实际。
今年之内还要动网站或者换办公系统的，先别叠一次邮箱迁移，两件事排在同一个月，出问题时排查会互相干扰。
还有一类，现用系统虽然老但稳定、维护的人还在，可以先按季度观察，不必着急。
这四类先放一放，不算漏。
09 两个容易漏的地方
头一个，客户端的旧设置。切换之后，手机上、电脑上、还有几个人自己装的第三方客户端，都要重新确认一遍收信设置。漏掉一个人，他的来信就可能一直落到旧服务器上。
第二个，退信率的观察期。切换后的头 2 周，用 GSC 里的收录和 Search Console 的流量数据看不出问题，要看的是发信日志里的退信比例。有异常就早发现早了。
我们复盘过几次这类迁移，真正值得记下来的不是改了哪几条记录，是当天谁值守。顺带一项，把这次迁移的过程记成 1 份 1 页的文档：改过哪些记录、谁值守、出过什么问题。下次再动邮箱，这份文档能省掉一半的排查时间。谷歌那边一年更新十几次算法都碰不到这件事，但你们的系统不会自己记事。
两条都是动手前就该定的。
常见问题
Q1 历史邮件能不能全部搬过去
A 多数能，方式是整批导出再导入。要提前问清两边的导出格式，以及导出期间要不要暂停收信。1 万封以内的邮件一次能导完。
Q2 切换一般安排在什么时间
A 选当地业务量偏低的时段，比如夜间到凌晨的 4 个小时。有海外客户的，先看一眼主要客户所在地的时差，避开他们上班的那几个小时。这一点和做谷歌 SEO 时先看目标市场时区是一个道理。
Q3 旧系统什么时候可以停
A 至少只读保留 30 天。这段时间里还能翻到漏收的信，也能应付「我上周发的你没回」这类问题。
Q4 员工要不要提前培训
A 不用做完整培训，但要在切换前一天发一份 1 页的操作说明，写清登录地址变了没有、手机要不要重设、出问题找谁。这份说明比开会讲一遍有用。
11 关于作者与参考来源
张凯文，山东支点网络科技有限公司，长期做外贸网站建设与谷歌 SEO。
官网建设上有拿不准的地方，可以在站内联系我们。
Google Search Central（developers.google.com/search/docs）
本文的迁移窗口期安排，来自我方在客户自建邮件系统迁移与域名解析切换中的实际处理记录。