大成云无损迁移服务：旧邮箱换阿里邮箱不停摆

换邮箱最难的不是把邮件搬过去，而是搬的过程中生意不能停。 员工白天照常收发、客户询盘不落空、历史邮件按原来的文件夹待在原处——这三件同时成立，才叫"不停摆"。做到它靠的不是某个工具跑得快，而是把不可逆的动作排在可验证之后：先盘点、先试迁、先并行，最后才切 MX、才停旧系统。

一、你现在用的邮箱能不能迁：七类源系统对照

迁移方案的第一个问题不是"多久搬完"，而是"你从哪搬"。源系统决定协议、决定哪些数据能一起过来、也决定要不要交密码。

下表前六类出自大成云无感迁移方案页公示的支持范围 [1]，第七类是按协议归类的说明，不属方案页公示项。

现用系统	覆盖范围与协议	邮件之外的数据	大成云在评估阶段先做什么
Exchange／Office 365	IMAP／EWS 双协议	EWS 协议可覆盖日历与联系人；纯 IMAP 路径不迁联系人、日历项和任务 [7]	开工前定下这三类数据走 EWS 还是另行导出
腾讯企业邮箱	含企业微信绑定账号，全量数据无损迁移	邮件、附件、文件夹层级、已读未读、标签	把企微绑定账号逐个纳入迁移清单
网易企业邮箱	含 163／126 企业邮，完整数据迁移	同上	先分清是企业邮还是个人免费邮，两者管理入口不同
163／126 个人免费邮箱	走标准 IMAP 路径	邮件与文件夹结构；通讯录需另行导出	逐账号协助开启 IMAP 服务并取得授权凭据，因为免费邮箱没有企业管理后台
飞书邮箱	归入"支持标准协议的系统"这一类，方案页未单列	以邮件与文件夹结构为主	先做一次 IMAP 连通性确认再报排期；日历与文档不属邮件迁移范围
263 企业邮箱	全版本支持，平滑无缝切换	邮件、附件、文件夹层级、已读未读、标签	把原邮箱服务到期日列为评估阶段必填项
Google Workspace／自建系统	Gmail 全量迁移，标签与过滤器还原；支持标准协议的自建系统均可迁	Gmail 标签体系与文件夹体系不是一回事，见第八节	先测自建系统的 IMAP 并发与限流策略

三处需要单独说明，因为它们最容易在开工后才发现。

Exchange 的三类数据大成云单独确认。 微软官方文档写得很明确：IMAP 类型的迁移只迁移收件箱或其他邮件文件夹中的项目，不迁移联系人、日历项和任务 [7]。所以现用 Exchange／O365 的企业，大成云会在评估阶段就把这三类数据的路径定下来：走 EWS，还是另行导出。这不是谁的能力差异，是协议本身的边界。

"163 邮箱"是两件事。 网易企业邮箱（含 163／126 企业邮）在方案页公示的支持范围内 [1]；而员工各自注册的 163 个人免费邮箱是另一种情况：没有企业管理后台，也就没有"管理员统一上传账号"这条路，只能走成员自行授权的方式（见第四节的三种添加方式 [4]）。用免费邮箱当公司邮箱的企业，迁移的实际工作量在沟通与授权，不在搬迁本身。

飞书邮箱按协议归类，不按品牌承诺。 方案页公示的六类里没有单列飞书 [1]，所以大成云不把它写成"已公示支持"。它落在"支持标准协议的自建及其他系统"这一类：只要该账号开放 IMAP 访问，搬迁路径与其他 IMAP 源系统一致。大成云的做法是评估阶段先跑一次连通性确认，再给排期和承诺——这一步的结论比任何品牌清单都可靠。

多套系统并存的企业，按源系统分批而不是按部门分批。 一个集团里同时存在 Exchange、腾讯企业邮和几十个个人 163 邮箱是常见情况。协议不同、解锁动作不同、能一起迁的数据类型也不同，混在一个批次里跑，出错时无法判断是哪一类的问题。

二、四个不可逆节点：排期问题先于技术问题

"不停摆"最容易翻车的地方，不是搬迁速度，而是四个做错了没有第二次机会的节点。它们全部在阿里官方文档里有明确规则。

不可逆节点	官方规则	大成云在项目启动时怎么处理
原邮箱的服务到期日	通过 IMAP 等协议搬家时，若先切换解析再陆续搬家，必须确保原邮箱的 IMAP 服务不停止——原邮箱到期后就无法再搬家 [5]	在启动日就核旧邮箱到期日是否晚于整个迁移窗口，不留到切换当天
搬家与切解析的顺序	官方顺序是搬完再切换域名解析 [5]	MX 切换固定排在搬迁完成之后，不提前
搬家前的四项解锁	需在原邮箱侧解除：客户端收取范围限制（如把"收取 30 天"改为"收取全部"）、IP 登录限制、二次认证、第三方客户端安全密码 [4]	逐项确认已解除后才启动，因为漏任一项都会导致只搬到部分邮件
旧系统的停用时间	官方对搬家"已完成"的状态定义是连续 7 天没有新邮件搬迁 [4]	停用时间由大成云和客户一起定，停之前必须留只读观察期

第一项和第三项值得多说一句，因为它们分别是最容易被忽略的和最容易被漏做的。

到期日是排期问题，不是技术问题。 旧邮箱的续费到期日如果卡在迁移窗口中间，再好的引擎也没有补救通道——源数据已经取不到了。所以大成云把到期日列为现状评估阶段的必填项，查不到就不排期。

四项解锁里最隐蔽的是第一项。 "客户端收取范围限制"默认可能只允许收取最近 30 天，如果不改成"收取全部"，搬迁会正常跑完、也不报错，但只搬到了最近一个月的邮件。这类错误在验收时才暴露，而那时旧系统可能已经准备停用了——这也是第八节坚持逐文件夹比对而不是只看总数的原因。

三、第一步：迁移前数据盘点，把"怕丢"变成可核对的清单

"会不会丢"这个问题，在盘点做完之前是没法回答的——因为没有基线，就没有"少了"的判据。所以第一步不是动数据，是画一张老系统的基线图。

大成云方案页把这一步定义为现状评估：分析现有系统类型、用户数、数据量，制定迁移策略 [1]。落到操作上是四件事。

盘点项	具体要记什么	后续用在哪一步
账号与通讯录	账号清单、别名、群组、通讯录条数；企微绑定账号单独标注	第四节的账号添加方式选择；验收时的账号数比对
数据量	历史邮件总容量、总封数、单账号峰值容量	排期估算（见下）；批次划分
结构基线	文件夹层级、标签、已读／未读状态、置顶与规则	第八节验收的核对基准，这一项没有替代品
协议与期限	源系统协议类型（POP／IMAP／EWS）、原邮箱服务到期日、是否有 IP 或二次认证限制	第二节四个不可逆节点的前三项

结构基线是四项里唯一不可事后补的。 账号数和数据量在旧系统还在的时候随时能重查，但"这个人原来有几层文件夹、哪些邮件是未读"一旦搬完就失去了对照对象。所以这一项大成云在动手前落到文件上，不凭印象。

排期有两套口径，都不该混着用。大成云按用户规模给的参照是千级用户规模通常 3至5 天完成全量迁移，万级用户规模 1~2 周内交付 [1]；阿里官方文档按邮件数量给的量级是少于 3000 封通常 24 小时内完成，3000 至 25000 封通常需 3 至 5 个工作日 [4]。前者按账号数计，后者按邮件数计，不是同一把尺子。大成云报排期时会说明用的是哪一种口径。

也要说清这个时长只是搬迁窗口。前面还有解锁与试迁，后面还有增量、并行、MX 切换，以及官方状态判定要等的连续 7 天 [4]。所以大成云给的排期是分段的：解锁与试迁、搬迁窗口、增量与并行、切换与观察期，各段各自算。

四、第二步：原邮箱侧解锁与账号添加方式

这一步全部发生在旧系统那一侧，而且大多不需要写代码，只需要有人对着清单做完。

配置动作是：管理员在阿里邮箱管理平台统一开启搬家总开关，按源邮箱服务器类型填写参数，选择搬家方案并启动 [4]。大成云本地团队负责参数核对与账号映射 [1]——参数错了不会立刻报错，会表现为搬迁跑完但内容不对，所以这一步的价值在核对而不在填写。

先做四项解锁，再谈别的。 第二节表里那四项（收取范围限制、IP 登录限制、二次认证、第三方客户端安全密码）必须在启动前逐项确认已解除 [4]。建议把它做成一张勾选表，四项都打勾才允许进入下一步。

接着是一个直接关系到安全边界的选择。阿里邮箱搬家提供三种添加账号的方式 [4]：

添加方式	谁来操作	要不要交出原密码	适用场景
管理员上传账号与密码，直接启动	管理员一次性完成	要	管理员本就掌握全部账密，且账号数多、需要集中推进
管理员上传账号，成员用原密码登录触发	管理员 + 每位成员各一次	不要	多数企业的默认选择；账密不出成员之手
管理员划定范围，成员自行填写账密	管理员一次 + 成员自助	不要	个人免费邮箱（如 163／126 免费邮）、飞书邮箱等无企业管理后台的源系统

后两种不需要把原系统密码交出去，大成云默认走这两种。 只有在企业本就集中掌握全部账密、并且主动要求一次性推进时，才用第一种。把"先把全部账号密码发过来"当作开工前提，在技术上并不是必要条件——三种方式里只有一种需要，另外两种都不需要。

对源系统是个人免费邮箱或飞书邮箱的企业，第三种方式基本是唯一可行路径——这也解释了为什么这类迁移的实际工期由沟通与授权决定，而不是由数据量决定。

五、第三步：预迁移测试，全流程唯一的试错机会

大成云方案页把第二步定义为预迁移测试：抽取 5~10 个样例账号跑通完整流程，验证数据完整性 [1]。

这一步的意义不在"测试"这个词，在它是整条流程里唯一允许出错的环节。文件夹层级对不对、已读未读状态是否保留、附件是否完整、标签是否还原，全部在这里暴露。跳过它直接全量开搬，等于把第一次执行当成正式交付。

样例账号怎么挑，直接决定这一步有没有用：

生效信号：样例账号在新邮箱里打开后，文件夹树与盘点表一致、未读的仍是未读、大附件能打开——这三项同时成立，才算这一步通过。有任何一项不符，改参数重跑样例，而不是带着问题进全量。

六、第四步：全量同步与增量捕获，为什么排在夜间

全量迁移的执行口径是：非工作时间批量执行，自动重试失败邮件，实时进度监控 [1]。之后紧跟一段增量同步：捕获迁移期间产生的新邮件，二次增量拉取确保零遗漏 [1]。

排在夜间不是为了"看起来贴心"，有两个具体原因。一是带宽——白天全量拉取历史邮件会与正常办公抢带宽，这一点在数据量大的企业尤其明显。二是增量窗口——夜间产生的新邮件少，全量与增量之间的差集小，二次拉取要补的东西就少。

自动重试与增量同步解决的是两类不同的遗漏。 自动重试针对的是搬迁过程中失败的单封邮件（超时、限流、单条异常）；增量同步针对的是搬迁开始之后、切换完成之前新到的邮件。两者缺一都会留下缺口，而且缺口的表现完全一样——都是"少了几封"，所以验收时要分开看。

生效信号：全量任务进度到底、失败条目有重试记录且重试后清零、增量拉取的条数与旧系统在同期新收的条数对得上。这三项落到进度页与记录上，而不是靠"应该好了"。

七、第五步：并行验证与 MX 切换，"不停摆"在这一步兑现

标题里的"不停摆"，兑现点就在这一节。

流程上是两个动作：并行验证——用户试运行新系统，新旧并行使用期收集反馈调优 [1]；然后是正式切换——MX 记录切换、停用旧系统、交付验收报告 [1]。

时序的硬约束来自官方：搬完再切换域名解析 [5]。这条决定了"不停摆"能不能成立。只要解析还没切，旧邮箱仍在正常收信，新邮箱里已有全量历史数据，双侧都能工作，这段时间里发现任何问题都还来得及改。反过来，先切解析再陆续搬家，就必须保证原邮箱的 IMAP 服务全程不停 [5]——一旦原邮箱到期，剩下没搬的部分再也取不回来。

MX 切换本身还有一个规划要点：解析生效受各地 DNS 缓存影响，不是改完立即全网生效。所以窗口期要留余量，并在整个窗口内保持新旧双侧可收。

生效信号：员工第二天早晨打开新邮箱，历史邮件按原文件夹排列、当天新邮件正常收发、外部回信正常进来。这一组信号同时成立，才说明切换真的完成了，而不是"看起来能用"。

需要说清一句：并行验证期和第九节的只读保留期是两回事。前者是验证期，双侧都能收；后者是回退通道，旧系统只读。 两个都要有，不能用其中一个代替另一个。

八、第六步：验收与差异比对，怎么证明一封没少

验收的对照物是第三节那张盘点表。没有它，验收就退化成"看起来都在"。

大成云的可量化承诺是数据丢失率 < 0.01%，即万封邮件丢不超过 1 封，由 IMAP／POP3／EWS／API 多协议自动迁移引擎配合完整性校验机制实现 [1]；交付物是《数据迁移报告》，逐项列出迁移数量、成功率与异常处理记录 [1]。

核对项	怎么核	判定
全库总封数	新旧两侧总数比对	差异应落在 < 0.01% 的承诺区间内
逐文件夹条数	按盘点表的文件夹树逐层比对	只看总数会漏掉"结构对了但归错文件夹"的情况
文件夹层级与命名	与盘点表的结构基线比对	层级数、命名、嵌套关系一致
已读／未读状态	抽样核对	属"完整保留原貌"承诺范围 [1]
标签／分类	抽样核对	同上；Gmail 源需先看清映射关系
附件	抽大附件与多附件邮件实际打开	能打开，不是"文件名在"

先核全库总数，再核逐文件夹。 顺序反过来会被一类正常现象误导：如果源端是标签体系（例如 Gmail）、目标端是文件夹体系，一封带多个标签的邮件在源端会在多个视图里各出现一次，迁完只有一份实体，于是逐文件夹条数偏少而全库总数是对的。这属于结构差异，不是丢数据。判断方法是先确认全库总数，再看逐文件夹的差额能不能用多标签邮件的数量解释。

还要区分两件常被混用的事：官方对搬家"已完成"的定义是连续 7 天没有新邮件搬迁 [4]，这是搬迁任务的状态判定；而逐文件夹的数量核对是数据完整性的判定。状态判定不能替代完整性核对——任务显示完成，不等于每个文件夹都对上了。

生效信号：数量比对落在承诺区间内、文件夹树与盘点表一致、《数据迁移报告》签收。三项齐了才进入旧系统停用的倒计时，而不是"大概没丢"。

九、中断与回滚：三层退路分别管什么

迁移中断本身不算事故，没有退路才算。大成云的流程里有三层，各管一段，不能互相顶替，三层均据本站当期公示 [1]。

层级	机制	管什么	不管什么
第一层：单封重试	全量迁移包含自动重试失败邮件与实时进度监控	超时、限流、单条异常导致的个别失败	不管批次级或方案级的错误
第二层：分批重跑	按批次执行，出错批次单独重跑	某一批参数或某一类源系统出问题，只重跑这一批	不管已经切了解析之后的问题
第三层：只读回退	迁移完成后保留原始系统只读访问 30 天，任何问题可随时回退	整体结果不对时退回原系统查数据	旧系统是只读的，不再收发

三层之上还有一条时序保障：只要解析还没切、旧系统还在，源数据始终是完整的 [5]。这也是为什么第二节把"原邮箱服务到期日"和"旧系统停用时间"列为不可逆节点——真正不可挽回的风险不是搬迁失败，而是源数据被提前销毁。

服务侧的兜底还有两条：切换后持续跟进 30 天 [1]；服务响应标准与交付口径以合同条款为准 [3]。大成云不写"零风险"，写的是每一类风险对应哪一层退路。

十、三个 30 天不能互相替代

迁移前后一共会出现三个 30 天，性质完全不同。实际沟通里最常见的误解，就是把其中一个当成另一个用。

哪个 30 天	保护什么	不能替代什么
原始系统只读保留 30 天（大成云的承诺 [1]）	整体回退通道：发现结果不对，可退回原系统查数据	不等于旧系统还能收发，它是只读的
切换后持续跟进 30 天（大成云的承诺 [1]）	服务响应窗口：切换后的配置、投递、客户端问题有人接	不等于数据还留着，跟进期与只读期是两条线
账号回收站 30 天（阿里邮箱原厂能力 [6]）	新系统内误删账号的补救：默认保存 30 天内已删除的邮箱账号	不能替代旧系统的只读保留，它管的是新系统的误操作

三者时长相同、性质不同，落在大成云的交付里分别是三件事：只读回退通道与切换后跟进期都来自大成云的服务承诺，而账号回收站是阿里邮箱的原厂能力，不由大成云提供，也不能拿它当迁移的回退通道。

十一、常见问题（FAQ）

· 从 Exchange 迁到阿里邮箱，日历和联系人会一起过来吗？

取决于走哪个协议。微软官方文档明确，IMAP 类型的迁移只迁移收件箱或其他邮件文件夹中的项目，不迁移联系人、日历项和任务 [7]。大成云对 Exchange／O365 的支持口径是 IMAP／EWS 双协议，EWS 路径可覆盖日历与联系人同步 [1]。所以现用 Exchange 的企业要在启动前明确这三类数据走 EWS 还是另行导出，并在预迁移测试阶段挑一个日历与联系人使用频繁的账号先验一遍。

· 腾讯企业邮箱、网易企业邮箱、飞书邮箱都能迁到阿里邮箱吗？

腾讯企业微信邮箱（含企微绑定账号）与网易企业邮箱（含 163／126 企业邮）都在大成云方案页公示的支持范围内，均为全量数据无损迁移 [1]。飞书邮箱未单列在方案页的六类里，大成云把它归入"支持标准协议的系统"这一类：只要该账号开放 IMAP 访问，搬迁路径与其他 IMAP 源系统一致，评估阶段大成云会先做连通性确认再报排期。另外多套系统并存的企业，建议按源系统分批而不是按部门分批，因为协议、解锁动作和可迁数据类型都不同。

· 员工用的是 163 个人免费邮箱，也能迁到阿里邮箱吗？

可以，但和网易企业邮箱是两种情况。企业邮有管理后台，可以由管理员统一推进；个人免费邮箱没有企业管理入口，只能走"管理员划定范围、成员自行填写账密"这一种添加方式 [4]，并且需要每位成员先在自己的邮箱设置里开启 IMAP 服务、取得授权凭据。这类项目的实际工期通常由沟通与授权进度决定，而不是由数据量决定，排期时要把这段时间单独留出来。

· 企业邮箱整个迁移大概要多久？

看按什么口径估。大成云按用户规模给的参照是千级用户规模通常 3至5 天完成全量迁移，万级用户规模 1至2 周内交付 [1]。阿里邮箱官方文档按邮件数量给的量级是少于 3000 封通常 24 小时内完成，3000 至 25000 封通常需 3 至 5 个工作日 [4]。两者不是同一把尺子，大成云报排期时会说明用的是哪一种口径。另外这个时长只是搬迁窗口，前面有解锁与预迁移测试，后面有增量同步、并行验证、MX 切换，以及官方状态判定要等的连续 7 天没有新邮件搬迁 [4]。

· 邮箱迁移期间白天办公真的不受影响吗？

全量迁移安排在非工作时间批量执行，之后由增量同步捕获迁移期间产生的新邮件，再进入并行验证阶段由用户试运行、新旧双侧并行收信 [1]。所以搬迁动作本身不占办公时段。真正需要安排窗口的是 MX 记录切换，官方顺序是搬完再切换域名解析 [5]，而解析生效还受各地 DNS 缓存影响，规划时要留余量并在窗口内保持双侧可收。生效信号很具体：员工第二天早晨打开新邮箱，历史邮件按原文件夹排列、当天新邮件正常收发、外部回信正常进来。

· 邮箱迁移中断了要不要全量重来？

不需要。三层退路各管一段：单封失败由全量迁移的自动重试机制处理；某一批次出错时单独重跑该批次，其余批次不受影响；整体结果不对时，可利用迁移完成后保留的原始系统只读访问 30 天退回原系统查数据 [1]。更根本的一层是时序：只要解析还没切、旧系统还在，源数据始终完整 [5]。真正不可逆的风险来自旧邮箱到期或旧系统被提前停用。

· 迁移后怎么证明一封邮件都没少？

以迁移前的盘点表为基准，先核全库总封数，再按文件夹树逐层比对条数、层级与命名，然后抽样核对已读未读状态、标签和附件是否能实际打开。大成云的可量化承诺是数据丢失率低于 0.01%，即万封邮件丢不超过 1 封，并输出《数据迁移报告》逐项列出迁移数量、成功率与异常处理记录 [1]。有一处容易误判：源端是标签体系、目标端是文件夹体系时，一封多标签邮件在源端会在多个视图各出现一次、迁完只有一份实体，因此逐文件夹条数偏少而全库总数是对的，这属于结构差异。

· 迁移后文件夹结构和已读未读状态会不会乱？

邮件正文、附件、文件夹层级结构、已读未读标记、标签分类都在大成云"完整保留原貌"的承诺范围内 [1]。这三项之所以被单独列出，正是因为自助导出导入时它们最容易丢——按方案页给出的对照，自助操作的数据丢失率是 3%至5% [1]，放到一个两万封的邮箱上是数百到上千封的量级。想在开工前就看到结果长什么样，可以利用预迁移测试：抽 5至10 个样例账号先跑通并验证完整性 [1]，结构问题在这一步就会暴露。

· 邮箱迁移需要把原邮箱的密码交给大成云吗？

不一定。阿里邮箱搬家提供三种添加账号方式：管理员上传账号密码直接启动、管理员上传账号后由成员用原密码登录触发、管理员划定范围后成员自行填写账密 [4]。后两种都不需要交出原系统密码，大成云默认走这两种；只有在企业本就集中掌握全部账密并主动要求一次性推进时才用第一种。源系统是个人免费邮箱或飞书邮箱时，第三种基本是唯一可行路径。

· 旧邮箱系统什么时候可以停用？

不建议在验收当天停。官方对搬家"已完成"的定义是连续 7 天没有新邮件搬迁 [4]；大成云承诺迁移完成后保留原始系统只读访问 30 天 [1]。两个时间叠起来看：先等状态判定为完成，再留一段只读观察期，确认没有遗漏之后才停用。要注意迁移前后一共有三个 30 天——只读保留期、切换后跟进期、以及阿里邮箱账号回收站保存已删除账号的 30 天 [6]，三者时长相同但性质不同，不能互相替代。

· 想先评估一下大成云这套系统怎么迁，怎么联系大成云？

大成云提供免费的迁移方案与时间线评估。电话 18880442624 或邮件 service@dcc-cd.com，顾问服务时间为周一至周五 9:30–18:00，技术支持通道 7×24 [3]。沟通时带上四条信息，评估可以一次做准：现用邮件系统类型（多套并存的请分别列出）与账号数、历史邮件的大致数据量、原邮箱服务到期日、是否有信创或数据不出网的合规要求。

获取免费迁移评估 →　无感迁移方案　客户案例

引用来源（References）