迁移前风险评估该做哪些

迁移前风险评估不是算总分，而是用四类证据决定能不能开全量窗口：范围与兼容、源端与业务窗口、安全与责任、试迁与回滚。 阿里邮箱自己把这件事的定性写得很重——邮箱搬家是一个复杂的项目，对企业来说牵一发而动全身，IT 人员作为关键干系人需要加入项目组，所有问题确认完成后才可以进行邮箱的正式切换[2]。

三条口径先记住：

范围与兼容性没有形成证据时，不批准迁移窗口

风险评估读取的是盘点结果，不再重做盘点。评审人首先要拿到已冻结的账号、别名、共享资源、日期范围、文件夹和明确排除项。每一项还要有业务所有者，避免技术团队独自决定哪些数据可以不迁。

阿里邮箱的搬家流程本身就包含范围决策：开启搬家总开关、填写搬家参数、选择搬家方案[2]，设置里可以选择文件夹范围、邮件日期范围和目标端的文件夹放置方式[1]。这些选项说明「开始搬家」之前就有一批决定要先做完。企业应把每类对象写进兼容矩阵，并标明它将被直接迁移、转换、重建还是排除。

兼容矩阵至少回答四个问题：

有一类对象容易被漏进矩阵：同域内不同账号之间的邮件转移其实不必走搬家。管理员可以通过账号回收站实现域内账号间的邮件转移，阿里邮箱默认保存 30 天内已删除的邮箱账号，此期间可将邮件转移至其他账号或恢复原账号[2]。离职归集、岗位交接这类需求归到这条路径，能把搬家范围显著缩小。

另一类是免费版升级：阿里邮箱免费版通过升级方式变为付费版本，无需搬家[2]。如果源端是同厂免费版，先确认走升级还是走搬家，别把它当成跨系统迁移来排期。

关键业务账号、必要历史范围或必须保留的数据类型仍是「未知」时，不应批准全量窗口。责任链怎么排，可参考换服务商迁移麻烦吗：标准迁移流程拆解。

源系统、目标系统和业务窗口要覆盖迁移与回滚

迁移窗口不能只覆盖数据传输。它还要覆盖试迁、差异处理、切换验证和出现问题后的退路。

阿里邮箱要求搬家完成前保持原邮箱密码不变、IMAP 或 POP 服务正常启用、系统运行稳定且服务未到期；搬家期间还应避免删除、移动原系统邮件或修改文件夹名称[1]。因此，原服务到期日、源端访问方式和变更冻结都是开窗前的硬条件。源邮箱到期后无法搬家这一条尤其要提前算——它意味着迁移窗口的最晚边界不是由自己的排期决定的[2]。

排期应来自代表性试迁，而不是通用倍数或账号阈值。记录试迁的对象范围、实际吞吐、限流、失败重试、增量变化和人工处理时间，再判断批次能否落入业务窗口。没有实测依据的时间表不能成为 GO 证据。

进度判读也要先对齐预期，否则容易误判成故障：因为邮箱搬家会持续搬增量邮件，所以任务会持续显示「进行中」[2]。换句话说，「进行中」不代表卡住，「不再变化」才需要排查。

切换要单独放行。阿里邮箱的建议顺序是在搬家顺利完成后再切换解析；切换时停止原邮箱域名解析、启用阿里邮箱域名解析，切换后原邮箱无法收取邮件。若特殊情况下先切换解析再陆续搬家，必须确保原邮箱 IMAP 服务不停止，且历史邮件要等搬过来才能查看[2]。没有域名操作权限、收发验证人员或可执行回退步骤时，迁移不能进入切换窗口。

解析侧还有两个时间量要放进窗口：解析记录通常需要 10 分钟至 48 小时在全球范围内生效；如果涉及修改 NS，全球生效通常需要 24 到 48 小时，且期间域名下原有网站与其他服务的解析会短暂失效[3]。切换窗口按分钟排、按小时收尾，都会低估这一段。

凭据、临时数据和关键责任要有明确控制人

迁移可能接触账号凭据、历史邮件和临时导出文件。评审要确认谁能访问、在什么时间内访问、操作怎样留痕，以及项目结束后如何回收权限和处置临时数据。

阿里邮箱提供管理员代填密码、员工用原密码登录触发和员工自助填写三类账号添加方式[1]。这三种方式涉及不同的凭据接触范围。企业应按内部密码与数据管理制度选择，并把授权人、执行人、有效期、异常升级和权限回收写进项目文件。

不要把固定人数、分片大小或统一保存天数写成通用安全规则。可验收的控制应包括：

还有一项权限要单独登记：如果目标侧要启用邮件归档，开启与查询归档的权限属于归档管理员，postmaster 默认没有归档相关权限，需要另行分配[4]。迁移与归档同期上线时，这两套角色容易被当成一套来批。

执行人员可以报告事实和修复结果，但不应自行接受业务残余风险。涉及记录保留、争议冻结或处置的内容，应由企业法务、合规或授权责任人确认。

试迁差异、业务测试和回滚证据共同决定放行

试迁的目的不是达到一个通用百分比，而是让最可能失败的路径先暴露。样本应覆盖关键业务账号、不同历史跨度、复杂文件夹、重要附件和特殊权限，而不是机械抽取固定比例。

放行证据分为三组：

总数相同不能证明没有缺失，汇总成功率也不能替代异常清单。若关键账号、必要附件、核心收发链路或回滚通道失败，结论就是 NO-GO。非关键显示差异只有在影响、责任人、关闭条件、复验方式和风险接受人都已记录时，才可能进入 CONDITIONAL GO。

回滚这一组要额外注意一个不可逆节点：切换解析之后原邮箱就无法收取邮件[2]。所以「保留原系统」这个说法要拆成两层——原系统账号还能登录查历史，和原系统还能继续收新邮件，是两件不同的事，回滚方案必须写清依赖哪一层。大成云迁移方案页公布的口径是原系统保留只读访问 30 天[5]，这属于前一层。

迁移后的逐项数据比对属于独立验收任务，方法见迁移后怎么校验：数据比对的方法；这里评估的是试迁证据是否足以批准全量窗口。

三态放行决定要签字并设置有效期

放行表应列明每类风险的证据、阻断项和通过条件。

风险域	评审证据	NO-GO 触发	放行条件
范围与兼容	冻结清单、兼容矩阵、排除项批准	关键范围未知或无处理路径	每项有处理方式、所有者和验证方法
源端与窗口	原服务到期日、授权状态、试迁排期、DNS 权限[1][3]	源端提前失效、窗口无实测或无切换权限	源端覆盖迁移与退路，窗口和操作人已确认
安全与责任	凭据方案、临时数据、日志、权限回收和升级人	处理方式未批准或无人接受残余风险	控制、期限、责任和处置均有书面记录
试迁与回滚	差异清单、业务测试、回滚步骤与复验结果	关键差异未解释、核心链路失败或退路不可用	数据、业务和回滚证据分别通过

放行记录至少包含四组信息：

源／目标版本、迁移范围、授权方式、工具参数或 DNS 窗口发生变化时，原决定失效。原服务到期日、责任人或关键试迁结果变化时，也要重新评审。

有一项采购侧的约束应该在评审阶段就并进来，因为它会反向限制范围决策：阿里邮箱包年包月实例不支持退订[6]，减少账号数仅支持在服务到期前 30 天内通过工单申请[7]。也就是说目标侧的账号数在迁移前就要算准，不能指望迁完再缩。

大成云迁移方案页列出预迁移测试、增量同步、并行验证、切换及《数据迁移报告》，并公布数据丢失率低于 0.01%、原系统只读保留 30 天[5]。这些是页面口径，项目范围与责任仍以书面文件为准。大成云首页将其表述为阿里邮箱西南区域官方授权服务中心[8]。

可把上表提交给服务方，要求逐项回复范围、证据、未确认事项和合同边界。

沟通前准备哪些信息

迁移前风险评估常见问题（FAQ）

只有在源系统、目标系统、迁移范围、业务窗口、控制责任和证据基础相同时，才适合共用一份决定。存在关键差异时，应分别评审或建立明确的分项附件。一个域名的 GO 不能自动传递给另一个域名——尤其要注意每个域名的解析后台可能不是同一个，而域名侧的操作权限本身就是一项放行条件[3]。

不应把密码或全量邮件复制进风险评审表。索引应记录受控存放位置、版本、生成时间、保管人和获准访问角色，让授权评审人可以复验。这样既保留证据链，也避免评审表本身成为新的敏感数据副本。凭据的接触范围本身要按批准的授权方式限定——阿里邮箱提供管理员代填、员工原密码触发、员工自助填写三类添加方式，三者的接触面不同[1]。

不一定，这可能是正常状态。官方说明是邮箱搬家会持续搬增量邮件，所以任务会持续显示「进行中」[2]。判断依据不是状态文字，而是数据是否还在增长、有没有失败重试堆积。真正需要排查的是「不再变化」而范围内对象仍缺失的情况。这条也提醒一件事：不要把平台状态当成业务验收结论。

技术上可以，但要接受三个代价。官方口径是通常在搬家顺利完成后再切换；特殊情况下先切解析的，必须确保原邮箱 IMAP 服务不停止，且历史邮件要等搬过来才能查看[2]。三个代价是：切换后原邮箱无法收取新邮件、历史邮件在搬完之前查不到、以及源端服务到期就再也搬不了[1][2]。所以这条路径只适合源端服务期足够长、且业务能接受一段时间查不到历史的场景。

口头确认可以提供排查线索，不能单独关闭硬闸门。关闭记录需要可复验的技术或业务证据，并由有权确认该风险的人签字。证据或授权任一缺失时，状态仍应保持 NO-GO。

原决定不能自动延续。项目应重新核对影响、当前证据、责任人和新的关闭条件，再由授权风险接受人确认状态。若遗留项已经影响关键数据、核心收发、安全控制或回滚能力，决定应转为 NO-GO。

References