盘点的产出不是五个数字，是五个判断。 数字对不上只是现象，判断才是你敢不敢按原计划开工的依据。阿里邮箱官方帮助文档对搬家这件事的定性是：这是一个复杂的项目，对企业来说牵一发而动全身，需要谨慎对待，且将所有的问题确认完成后，才可以进行邮箱的正式切换 [2]。下面五项就是「所有的问题」具体指什么。

一、为什么盘点的产出是判断，不是清单

一份只有数字的清单没法用。你数出某个账号有 800 个文件夹、12 万封邮件，这两个数本身不告诉你任何事——它们要跟目标端的上限、跟官方给的时长量级、跟你选的搬家方案放在一起，才会变成一句可以拿去排计划的话。
前三项盘的是可以计数的东西，走的是同一个套路：记哪几个数 → 拿它跟什么比 → 比不上时怎么办，第三步的答案就是判断产出。后两项盘的不是数量而是状态——第四项盘配置的现状快照，第五项盘退路的可用性，所以它们的三步变成「记什么 → 缺了会怎样 → 补齐要做什么」。五项的共同点只有一个：末尾都要落到一句能说出口的判断。
这也决定了同一件事在迁移前和迁移中的性质完全不同：
迁移前没盘到的东西
迁移中的表现
迁移前修掉它的成本
客户端只允许收取最近 30 天
搬完了，邮件总数远少于预期，但系统不报错 [1]
在原邮箱后台改一次设置的事
某个账号开着二次认证或 IP 登录限制
该账号搬家状态停在「认证失败」
搬家前批量关闭即可 [1]
原邮箱服务到期日早于迁移窗口结束
到期后无法再搬家，历史邮件留在原系统 [2]
续一次费的事
文件夹名带 +、*、\、/ 这类符号
文件夹创建失败或结构错乱
改名的事 [1]
没记录原有的转发规则与签名
切换后审批通知、对外自动回复静默失效
截图留底的事
左列每一项在迁移前都是十分钟能解决的动作，在迁移中都是要停下来处理的事故。

二、第一项：账号与权限，原系统愿不愿意交出数据

企业邮箱用上一两年，账号体系就比开通时复杂得多：在职员工账号、离职员工的历史账号、部门公共邮箱、邮件群组、别名，以及各自的权限分配。只统计在用的个人账号，那些没人认领的账号在旧系统关闭后就彻底失联。
但这一项真正的难点不在「数清有几个」。账号盘点要盘的是每一个账号能不能被登进去——搬家走的是 IMAP 加账号密码，原系统上任何一道安全设置都会让它卡在认证环节。

2.1 要记录哪几个数

这三项从原邮箱管理后台导出即可。还有一个数要顺手问出来——原邮箱的服务到期日，它常常没人知道；但它的判断归第五项（回滚那一项），因为它决定的不是账号能不能搬，是出了事还有没有退路。

2.2 官方要求在搬家前解开的四把锁

阿里邮箱官方的搬家准备事项里，有四条是针对原邮箱侧的设置，需要在开搬之前处理掉 [1]：
要解开的设置
官方原文要求
不解开的后果
客户端收取邮件的范围限制
解除范围限制，例如把「收取 30 天」改为「收取全部」
只搬到最近一段时间的邮件
IP 登录限制
解除
搬家侧的连接被原系统按异常来源拦掉
二次认证（手机短信、微信、身份验证器等）
解除
账号状态停在「认证失败」
第三方客户端安全密码
解除
同上，用常规密码登不进去
官方还给了一句执行方式上的提示：根据原邮箱的功能情况，管理员可以选择批量关闭，或者调用原邮箱的 API 关闭 [1]。也就是说这四项不必逐个账号手工点，但要提前确认原系统支不支持批量。
第一条值得单独强调。它是这五项盘点里唯一一个会让你误以为迁移成功的坑：其余问题都会以失败或报错的形式暴露出来，而收取范围限制只会让搬过来的邮件安静地少掉一截。所以邮件量这个数必须在解除限制之后再统计一遍。
配套的还有两条搬家进行中的禁令：不要删除或移动原系统的邮件，不要更改文件夹命名 [1]。数据的删除与整理动作要提前做完，搬家期间尽量不改动 [1]。这两条直接决定了「盘点—清理—开搬」这个顺序不能倒。

2.3 原系统是哪一家，官方另有专篇

各家邮箱的 IMAP 开关位置、安全策略、账号命名规则都不一样。阿里邮箱官方按原服务商分别出了搬家注意事项，覆盖飞书、腾讯、网易、Coremail、263、Gmail、Exchange、Office 365 八种情况 [5]。
盘点这一步的动作很简单：先确认原系统是哪一家，再去对应那一篇把它列的准备项抄进自己的清单。这比按通用清单盘一遍更省事，也更不容易漏——各家要解的锁不完全相同。

2.4 搬家方案决定清单要不要多一列

阿里邮箱提供三种添加搬家账号的方式，它们对账号信息的要求不同 [1]：
方案
适用场景
对盘点清单的要求
管理员上传账密，直接启动搬家
已掌握全部账号在原系统的密码，且希望成员不感知迁移
清单要多一列原系统密码；账号可以不一致，但需要精确的对应关系
管理员上传账号，成员用原密码登录触发
已知账号但未取得密码
不需要密码列，但需要保持账号一致性
管理员划定范围，成员自行填写账密
未收集账号密码，分散式搬家
不需要密码列，但要一份准确的人员名单与通知路径
先定方案再盘清单，能省掉一轮返工——如果最后走的是第二种，收集密码这件事从一开始就不必做。
本项的判断产出：每一个账号都能被登进去（四把锁已解）、原系统是哪一家已确认并抄了对应的官方准备项、搬家方案已定。三项齐了，才有资格进入下一项去数邮件。

三、第二项：文件夹结构与邮件量，分几批、搬多久

这一项要盘的是三组数字：每个账号的文件夹数量与最深层级、邮件总量、归档箱与已删除邮件的情况。它们决定分批策略、迁移时长，以及用户在新系统里看到的目录还是不是原来那个样子。

3.1 要记录哪几个数

回收站那个取舍没有标准答案：不清空会拖慢搬家，清空了可能引发用户投诉。但它必须在开搬前和业务部门达成一致，不能搬到一半再问。

3.2 拿这些数和什么比

跟目标端的上限比。阿里邮箱普通账号的相关参数如下 [3]：
项目
官方参数
单账号最多可创建文件夹数（不含系统文件夹）
800 个
自定义文件夹子级数
10 级
每个邮件夹可存邮件数
100 万封
单账号可存储总邮件数
200 万封
标签个数
255 个
这五项里有四项的量级远超一般企业的实际情况，它们的作用是给盘点出的数字一个参照系，不必真去担心超限。真正值得对着盘的只有加粗那一项：子级数 10 级。 邮件数和文件夹总数很难撞到上限，但「客户／华东区／2024 年度／已结项／合同扫描件」这样一路建下去的层级，在中文办公环境里五六级很常见，个别账号突破十级并不稀奇。
所以第一步的动作是：把每个账号的最深层级深度单独列一列，超过十级的挑出来在迁移前做结构精简，而不是原样搬过去再说。这一步没有工具能替代——工具只能按目标端规则做一种近似，它不知道哪两层该合并。
另外一条官方要求落在命名上：建议原系统的文件夹名称不要包含特殊符号，例如 +、*、\、/ 等 [1]。中文办公环境里，全角括号、空格、下划线乃至表情符号做文件夹名都很常见，盘点时要连带把这些名字筛出来，在搬家前统一改掉——注意改名必须在搬家开始之前做完，因为搬家进行中官方明确要求不要更改文件夹命名 [1]。

3.3 邮件量对应的官方时长量级

邮件量这个数最直接的用途是估工期。阿里邮箱官方给出的子账号搬家速度参照是 [1]：
单账号邮件量
正常情况下的搬家耗时
少于 3,000 封
24 小时内完成
3,000 至 25,000 封
3 至 5 个工作日完成
两点使用提醒。一是这是单账号的量级，不是整个项目的工期；整体窗口还要叠加分批安排和并行观察期。二是它标注的是「正常情况下」，原系统的响应速度、网络状况、批次并发都会影响实际耗时，所以规划时要留余量，不要把这两个数字当承诺写进方案。
搬家任务的启动时间也可以在盘点阶段一并定下来：官方支持「立即启动」（邮件数据在 2 小时内开始传输）和「指定时间启动」两种 [1]。数据量大的账号排到夜间启动，是一个零成本的安排。

3.4 文件夹落地位置有两种模式，迁移前就要选

「迁移后文件夹结构会不会乱」这个问题，有一部分答案其实是个可选项而不是命运。阿里邮箱的搬家设置里，文件夹落地位置有两种模式 [1]：
模式
官方行为
适合什么情况
单独存放（统一存储模式）
在目标邮箱创建一个专用文件夹，以原邮箱地址命名，历史邮件全部放在它下面的各个子文件夹里
想把历史邮件和新邮件彻底隔开；也便于迁移后核对——旧的都在一棵树下
合并进系统文件夹（文件夹映射模式）
自动匹配系统文件夹（如发件箱映射到已发送），并保留自定义文件夹结构
想让用户在新系统里看到跟原来一样的目录
这个选择要在盘点阶段就有结论，因为它改变的是核对基准。选了「单独存放」，迁移后就不该按原路径逐层对照，而要在那棵以邮箱地址命名的树下对照；选了「合并进系统文件夹」，则要重点核对自建的归档目录有没有被并进系统默认文件夹。
本项的判断产出：分几批、每批放在哪个时段、文件夹落地用哪种模式、迁移后按哪套基准核对。这四项定下来，方案里的时间表才算有依据，而不是拍出来的。

四、第三项：超大附件与特殊数据，哪些要走批次之外

超大附件、编码异常的邮件、嵌套过深的子文件夹，这三类数据消耗的时间远超普通邮件，而且搬完之后可能出现附件打不开、正文乱码的情况。它们的正确处理方式不是「多留点时间」，而是从正式批次里拿出来单独处理。

4.1 筛附件要按收信侧的上限筛

这里有一个方向容易搞反：搬家是往新邮箱收邮件，所以真正卡住你的是目标端的收信上限，不是发信上限。阿里邮箱普通账号的相关参数 [3]：
项目
官方参数
收信普通附件大小限制
100 M
收取邮件正文大小限制
10 M
收取邮件附件个数限制
500 个
发信普通附件大小限制
默认 50 MB，域管可在 1–60 MB 之间配置
发信单个超大附件大小限制
4 G
大附件中转站大小
标准版、集团版 10 G；AI 尊享版 32 G
官方在附件参数下附了一条很实用的注释：base64 编码的邮件会膨胀 1.5 倍以上，邮件正文大小也会影响附件大小 [3]。
这条注释带来一个盘点上的取舍。官方没有说明 100 M 这个收信上限是按编码前还是编码后计量的，所以稳妥的做法是假设按编码后计量——按 1.5 倍反推，编码前约 66 MB 的附件就可能触到上限。这是本文唯一一处基于官方数据做的推算，不是官方口径；实际阈值应向服务商确认，但盘点时按更严的那一侧筛不会出错，比事后逐封排查省事得多。
要区分的另一件事：大附件中转站的容量是中转站的总容量，不是单个文件的上限 [3]。这两个数经常被混着说。

4.2 编码与命名：把名字也当数据盘

编码异常的邮件在原系统里通常显示正常，问题出在协议转换之后。这类邮件没办法靠管理后台批量识别，只能按「经历过几次编码转换」这个线索去挑：曾从更早的旧系统导入过一轮的邮件、跨语言环境往来的邮件、附件名不是纯英文数字的邮件，都属于转换次数更多、因而更值得优先抽查的那一类。挑出一批单独导出验证，确认在新邮箱里能正常打开，再并入正式批次。
文件夹与附件的名字同样要盘。官方点名的特殊符号是 +、*、\、/ 等 [1]，落到附件文件名上，同类风险还包括冒号、问号和引号——它们在部分操作系统上不是合法文件名字符，下载时会被替换或截断。

4.3 官方给了两个现成的排除口

「单独处理」不需要额外工具，阿里邮箱的搬家设置里就有两个现成的开关 [1]：
这两个开关的存在，意味着第三项的判断产出可以非常具体——不是「注意超大附件」这种提醒，而是一份排除清单加一组日期区间。
本项的判断产出：一份要排除在首批之外的文件夹清单、一组单独搬运的日期区间、一份需要人工验证的抽样邮件名单。这三样是可以直接填进搬家设置界面的东西，不是提醒。

五、第四项：全局配置、签名与转发规则，切换那一刻能不能不中断

这一项盘的是现状快照。DNS 记录、签名模板、自动转发规则、邮件组配置，这些东西不会随邮件一起搬过去，切换之后要在新系统里重新建立一遍。而重建的前提是你手上有一份原样的记录。

5.1 DNS 现状快照要记到什么粒度

不是「记下 MX 指向哪里」，而是把现有每一条相关记录的完整字段抄下来：记录类型、主机记录、记录值、优先级、当前的 TTL 值。四类记录都要覆盖——MX 决定邮件往哪走，SPF、DKIM、DMARC 决定新系统的发信信誉 [4]。
盘点这一步要顺带确认两件官方明确点出的事 [4]：
TTL 该怎么调、切换窗口怎么排，属于切换阶段的动作，本文不展开。盘点阶段只需要把当前值记下来。

5.2 签名与转发规则要对照目标端的条数上限

这一类配置最容易被当成「小事」跳过，但它们失效的时候是静默的——审批通知不再转发、对外自动回复消失，通常要等客户催问才发现。
盘点内容和对应的目标端上限 [3]：
要盘的配置
阿里邮箱普通账号上限
每个账号的邮件签名模板
签名设置 10 个
自动转发的目标邮箱
20 个
收信规则（自动分类、自动转发、自动回复）
200 条
收信规则中的自动转发邮箱
200 个
黑白名单条目
500 个
上限本身不是重点，重点是这张表提示了要盘哪几类。尤其是收信规则——员工在原系统里积累多年的自动分类规则，几乎不会有人主动上报，得管理员去后台逐账号导出。

5.3 一个容易漏的切换后待办：解除原邮箱域名绑定

这一条不属于迁移前的动作，但必须在迁移前写进待办清单，否则切换后大概率想不起来。
官方的要求是：为避免出现同域认证问题，完成域名解析切换后，要在原邮箱系统替换域名或解除绑定 [1]。不做这一步的症状很具体——新邮箱给原服务商的同域地址发信会失败，而这个症状看起来完全不像是「忘了解绑」引起的，排查起来很费时间。官方同时建议这一步的具体操作方式联系原邮箱客服确认 [1]。
同一份官方提醒里还有一条：搬家完成后要重新配置第三方客户端 [1]。员工电脑上的客户端参数不会自动更新，这也是切换后待办里必须有的一行。
本项的判断产出：一份可以照着重建的配置快照（含四类 DNS 记录的完整字段、所有发信来源清单、逐账号的签名与收信规则导出），加一份切换后待办（解除原域名绑定、重配客户端）。判断标准是把快照交给一个没参与盘点的人，他能不能照着建出来。

六、第五项：备份与回滚，出了事能不能退回去

备份是底线，没有备份不要动手。但这一项要盘的不只是「备份做了没有」——回滚的物质基础不是备份文件，是原邮箱还活着。 备份解决的是「丢了能不能找回来」，原邮箱解决的是「能不能退回去继续用」，这是两件事。

6.1 回滚的物质基础是原邮箱还活着

阿里邮箱官方对搬家全程的要求是保持原邮箱：登录密码不变更、IMAP／POP 服务正常启用、系统运行状态稳定且服务未到期 [1]。另一篇官方文档把后果说得更直接：如果先切换域名解析再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，原邮箱到期后就无法搬家，历史邮件要等搬过来才能查看 [2]。同一篇也给出了推荐顺序——通常在邮件搬家顺利完成后，再进行解析切换 [2]。
所以这一项盘点里最该先查、也最容易被跳过的一个数是原邮箱的服务到期日。它必须晚于整个迁移窗口的结束，而且要留出观察期的余量。这一项要在项目启动那天确认，不是切换当天。
顺带记一条容错窗口：阿里邮箱的账号回收站默认保存 30 天内已删除的邮箱账号，此期间可将邮件转移至其他账号或恢复原账号 [2]。它管的是阿里邮箱域内被删掉的账号，与「原邮箱要保留多久」是两件事，不能互相替代——盘点时两个窗口都要单独记。

6.2 增量同步与「已完成」状态决定观察窗口

搬家不是一次性动作。官方说明搬家会持续同步搬家期间原邮箱新收到的邮件，所以进度长时间显示「进行中」是正常的，不是卡住了 [1] [2]。
而它什么时候算完，官方给了一个明确的判据：若 7 天内没有收到新邮件，搬家状态会变成「已完成」；已完成状态不再收取新邮件，如需重新接收需要重启搬家 [1]。
这条对盘点阶段的意义是：观察窗口不能短于这个机制的节奏。如果并行期只留三天就把原邮箱停掉，增量同步还在跑的那部分邮件就断在半路；反过来，如果某个账号已经变成「已完成」而原邮箱那边又来了新邮件，那批邮件不会自动过来，需要手工重启搬家。这两个方向的风险都要在计划里写清楚由谁盯。

6.3 回滚预案要盘的三件事

一份能用的回滚预案至少包含三样，都要在迁移前落到纸面：
  1. 备份文件的存放位置，以及一次实测——找一台没有配置过原邮箱账号的机器把备份打开一遍。很多备份是到了要用的时候才发现依赖原账号才能读取。
  1. 恢复演练跑通过没有。没演练过的备份只是一个文件，不是一条退路。
  1. 验收标准是什么，且必须具体：邮件总数比对、文件夹层级比对、附件完整性比对，每一项都对得上才算通过。前两项的比对基准来自第二项盘出的邮件总量与目录树截图，第三项的基准来自第三项筛出的大附件清单——所以验收标准要在盘点阶段定，不能等搬完了再商量：那时候基准已经没有了。
本项的判断产出：原邮箱的服务到期日晚于窗口结束、观察期长度已按增量同步机制定好并指定了盯的人、备份已实测可读且演练过、三项验收标准已写进方案。这四项是五项里唯一只在出事之后才被用到的，所以验收时它也最容易被一句「应该没问题」带过去。

七、一张可以直接用的迁移盘点表

五项加一条贯穿约束，动手前逐行过一遍。最后一列是这一行真正要交付的东西。
盘点项
要记录的具体内容
官方依据
常见坑
应对措施
本项输出的判断
一、账号与权限
账号总数并分类计数；每个账号的别名、群组、管理权限；每个账号在原系统的四项安全设置状态
[1] [5]
只统计在用账号，漏掉公共邮箱与别名；账号带二次认证或 IP 限制导致「认证失败」
后台导出完整清单；按官方要求批量解除四把锁；按原服务商查对应的官方专篇
原系统愿不愿意交出数据
二、文件夹结构与邮件量
每账号文件夹数与最深层级；解除收取限制后的邮件总量与分项条数；回收站取舍；完整目录树截图
[1] [3]
在「收取 30 天」未解除时统计邮件量，数字偏少且不报错
先解限制再统计；对照目标端上限；开搬前改掉带特殊符号的文件夹名
分几批、搬多久、结构怎么落地
三、超大附件与特殊数据
按收信侧上限并下调一档筛出的大附件清单；高风险编码邮件抽样名单；过深嵌套目录
[1] [3]
按发信上限筛附件；忽略 base64 编码膨胀
用「排除指定文件夹」与「指定日期范围」把它们放到批次之外
哪些数据走批次之外
四、全局配置、签名与转发规则
四类 DNS 记录的完整字段与当前 TTL；域名下所有发信来源；逐账号的签名、收信规则、自动转发、黑白名单
[3] [4]
只记 MX 忘了 SPF 的其他发信来源；收信规则无人上报
留一份可照着重建的快照；把解除原域名绑定与重配客户端写进切换后待办
切换那一刻能不能不中断
五、备份与回滚
原邮箱服务到期日；观察期长度与责任人；备份存放位置与实测结果；三项验收标准
[1] [2]
只备份不演练；原邮箱到期或提前停掉，退路消失
备份换机器实测并演练；观察期按增量同步机制定；验收标准写进方案
出了事能不能退回去
贯穿约束
原邮箱在搬完前：密码不变更、IMAP／POP 正常启用、状态稳定且服务未到期；搬家期间不删除移动邮件、不改文件夹名
[1] [2]
边搬边改数据或改名；到期后才发现搬不了
项目启动日就确认到期日；清理与改名全部提前做完
这五项判断能不能成立的前提

八、什么情况建议引入专业团队

三类场景下，自行盘点与执行的难度会明显上升：
不管最终由谁执行，有一个动作是自己能做且值得坚持的：把盘点清单作为迁移交付物的一部分，要求执行方逐项签字确认。 第七节那张表可以直接当作签收依据——它的最后一列写的是判断，签字确认的是判断成立，而不是「清单已填」。

九、常见问题（FAQ）

Q: 企业邮箱搬家大概要多久？
阿里邮箱官方给出的是单账号量级的参照：单账号邮件量少于 3,000 封时，正常情况下 24 小时内可以搬完；3,000 至 25,000 封时，正常情况下 3 至 5 个工作日完成 [1]。这是单账号的耗时，不是整个项目的工期——项目窗口还要叠加分批安排和搬完之后的并行观察期。另外它标注的是「正常情况下」，原系统响应速度、网络状况与批次并发都会影响实际耗时，规划时要留余量。
Q: 为什么搬家进度一直显示「进行中」，是卡住了吗？
不是。官方说明搬家会持续同步搬家期间原邮箱新收到的邮件，所以进度长时间显示「进行中」属于正常状态 [1] [2]。它变成「已完成」的判据是：7 天内没有收到新邮件；「已完成」之后不再收取新邮件，如果那个账号后来又收到邮件并且需要搬过来，要手工重启搬家 [1]。
Q: 原邮箱设了「只收取最近 30 天」，不改会怎样？
只能搬到最近这段时间的邮件，而且系统不会报错。阿里邮箱官方的搬家准备事项里明确要求解除客户端收取邮件的范围限制，例如把「收取 30 天」改为「收取全部」 [1]。这是所有迁移前准备动作里最该优先处理的一条，因为其余问题都会以失败或报错的形式暴露出来，而收取范围限制只会让搬过来的邮件安静地少掉一截。相应地，邮件总量这个数必须在解除限制之后重新统计一遍，否则盘点出的基准数本身就是错的。
Q: 原系统是腾讯、网易或飞书邮箱，迁移前要做什么特殊准备？
阿里邮箱官方按原服务商分别出了搬家注意事项，覆盖飞书、腾讯、网易、Coremail、263、Gmail、Exchange、Office 365 八种情况 [5]。各家的 IMAP 开关位置、安全策略与账号命名规则不同，要解的设置也不完全一样。正确做法是先确认原系统是哪一家，再去对应那一篇把它列出的准备项抄进自己的盘点清单，而不是套用一份通用清单。
Q: 迁移前要不要先清空回收站？
没有标准答案，但必须在开搬之前决定。不清空会增加搬运量、拖慢进度；清空之后如果有员工需要找回某封已删邮件，就没有来源了。做决定时可以对照目标端的容量参照：阿里邮箱普通账号单账号可存储总邮件数为 200 万封，每个邮件夹可存 100 万封 [3]。绝大多数企业远达不到这个量级，所以这个取舍通常不是容量问题，而是业务部门愿不愿意承担找不回来的风险，要提前沟通确认。
Q: 可以先切换域名解析，再慢慢搬邮件吗？
可以但有前提。阿里邮箱官方推荐的顺序是在邮件搬家顺利完成后再切换解析；如果确实需要先切解析再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，因为原邮箱到期后就无法搬家，且历史邮件要等搬过来之后才能查看 [2]。所以选这条路的话，原邮箱的服务到期日和 IMAP 服务状态就成了整个项目的硬约束，要在项目启动时就确认，而不是切换当天才查。
Q: 迁移前该按多大的附件来筛超大附件？
要按目标端的收信上限来筛，不是发信上限——搬家是往新邮箱收邮件。阿里邮箱普通账号的收信普通附件大小限制为 100 M，收取邮件正文大小限制 10 M，收取邮件附件个数限制 500 个；发信侧则是普通附件默认 50 MB（域管可在 1–60 MB 之间配置）、单个超大附件 4 G [3]。官方还提示 base64 编码的邮件会膨胀 1.5 倍以上，邮件正文大小也会影响附件大小 [3]，所以筛选阈值要比上限值再往下调一档，不能直接拿上限当刀切。
Q: 盘点清单里要不要包含员工在原邮箱的密码？
取决于选哪种搬家方案。阿里邮箱提供三种添加搬家账号的方式：管理员上传账密直接启动搬家（需要密码，账号可以不一致但需精确对应关系）、管理员上传账号后由成员用原密码登录触发（不需要密码，但需保持账号一致性）、管理员划定范围后成员自行填写账密（不需要密码，需要准确的人员名单） [1]。先定方案再盘清单能省掉一轮返工——如果最终走后两种，收集密码这件事从一开始就不必做。

结语

这五项盘点里，四项都可以靠导出、截图、抄记录完成，只有第一项需要真的去动原系统的设置。而恰恰是它决定其余四项的数字是不是可信的——收取范围限制没解开，邮件总量就是错的；错的邮件总量会让分批策略、时长估算、验收基准一起错。所以顺序上它必须排在最前面。
盘点做完的标志也不是清单填满了，而是那五句话能不能说出口：原系统愿意交出数据、分几批搬多久已定、哪些数据走批次之外已列、切换那一刻的配置有快照、出了事能退回去。说不出其中任何一句，就不到开工的时候。
对缺少专职运维的企业，这类迁移前盘点与后续的执行落地也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含迁移前的数据盘点、迁移实施与相关的校验支持 [6]。无论由谁执行，第七节那张表都应逐行确认并写入验收标准。
本文内容依据阿里邮箱官方帮助文档整理，具体迁移方案请以实际环境与所选服务商（大成云）的专业建议为准。

引用来源（References）

  1. 邮箱搬家 —— 阿里邮箱官方帮助文档（管理员篇·邮箱工具） —— 阿里邮箱官方文档（页面标注更新时间 2026-07-07）。
  1. 邮箱搬家 —— 阿里邮箱官方帮助文档（解决方案篇）
  1. 普通账号常见参数 —— 阿里邮箱官方帮助文档
  1. 阿里邮箱域名解析指南 —— 阿里云帮助中心（中文）
  1. 阿里邮箱官方「原服务商搬家注意事项」专篇索引 —— 均为阿里邮箱官方帮助文档，由来源 [1] 的「原邮箱注意事项」一节列出：原飞书邮箱用户搬家注意事项、原腾讯邮箱搬家注意事项、原网易邮箱用户搬家注意事项、原 Coremail 邮箱用户搬家注意事项、原 263 邮箱用户搬家注意事项、原 Gmail 邮箱用户搬家注意事项、原 Exchange 邮箱用户搬家注意事项、原 O365 邮箱用户搬家注意事项
  1. 成都大成云信息技术有限公司官网