大成云迁移服务详解：周期、保障、验收标准

这篇讲三件事：周期怎么估、业务连续靠什么安排、验收看哪几个字段。 大成云的迁移按六步执行——现状评估、预迁移测试、全量迁移、增量同步、并行验证、正式切换，方案页写明每一步都有明确的交付物和质量门禁[6]。周期的官方参考是千级用户规模通常 3~5 天完成全量迁移、万级 1~2 周内交付[6]；业务连续靠的是 MX 记录放在最后一步切；验收看《数据迁移报告》里的迁移数量、成功率与异常处理记录[6]。

三条口径先记住：

相邻话题各有专文：最晚哪天必须启动见换邮箱服务商怎么排期：从旧合同到期日倒推；企业侧要配合什么见从别家迁到大成云，迁移流程是怎样的；各节点由谁签字放行见换服务商迁移麻烦吗：标准迁移流程拆解。本篇不讲排期倒推，只讲这项服务交付什么。

一、周期：两套参考数字，算的不是同一件事

方案页和原厂文档各给了一套周期参考，用途不同，不要混用。

参考来源	数字	算的是什么
大成云项目周期	千级用户规模通常 3~5 天完成全量迁移，万级用户规模 1~2 周内交付[6]	整个项目的全量迁移阶段要多久
阿里邮箱单账号速度	邮件少于 3000 封通常 24 小时内完成；3000 到 25000 封约需 3 到 5 个工作日[1]	一个账号搬完要多久

两套数字都只覆盖「搬」这一段，不含前后。 前面有现状评估与预迁移测试，后面有并行验证和正式切换，另外搬家任务要等原系统 7 天内没有新邮件才会转为已完成，而已完成后不再收取新邮件、需要重新收取必须重启搬家[1]。

一个可参考的实际案例：客户案例页里一家 2000+ 账号的重庆制造企业选择私有化部署、覆盖全国 12 个分支机构，页面标注 2 周完成全量迁移[7]。账号数在千级，周期却落在万级那一档——因为部署形态和分支机构数量也会影响工期。

排期时先确认两件事：

现状评估要统计哪些数，见迁移前必做的 5 项数据盘点。

二、保障：五个风险点分别对应哪一步

业务不中断靠的不是某一项技术，是把六步的顺序排对——核心是 MX 记录放在最后一步切。切换前员工一直用旧邮箱，新邮件仍进旧系统，所以不存在「两边都要看」的阶段。

风险点	方案页写明的安排	企业要做的
全量迁移前流程跑不通	预迁移测试抽取 5~10 个样例账号，跑通完整流程，验证数据完整性[6]	样例里放进邮件量最大、文件夹层级最多的账号
搬迁期间影响日常收发	全量迁移在非工作时间批量执行，自动重试失败邮件，实时进度监控[6]	员工照常用旧邮箱；不要修改密码、移动邮件或改文件夹名[1]
迁移期间的新邮件漏掉	增量同步捕获迁移期间新邮件，再做二次增量拉取[6]	确认增量同步的截止时点
切换当天出问题	并行验证期间用户试运行新系统、新旧并行、收集反馈调优，之后才切 MX[6]	定好切换日并提前通知员工：切换后原邮箱收不到新邮件[2]
切换后发现遗漏	迁移完成后原始系统保留只读访问 30 天，可回退；页面另标注切换后持续跟进 30 天[6]	只读期内完成抽查；只读期起止日与旧邮箱续费安排在评估时定下

最后一行的两个 30 天是两条线，起止日要分别确认：一个是原系统的只读可访问期，一个是服务方的跟进期，它们不一定同起同止。

迁移前还有一组前置条件容易被漏：原系统要保持服务正常、IMAP 或 POP 可用，并解除客户端收取范围、IP 登录限制、二次认证、客户端安全密码这几类限制[1][2]。这些操作需要原系统的管理员权限，权限不在自己手上时要提前安排。

哪几个节点做了就不能回头，见找人做邮箱迁移，靠谱的流程应该长什么样。

三、验收：《数据迁移报告》要核三个字段

正式切换这一步的交付物是验收报告，即逐项列出迁移数量、成功率与异常处理记录的《数据迁移报告》[6]。拿到之后按三项核对。

第一是范围。 方案页写明完整保留的内容包括邮件正文、附件、文件夹层级结构、已读未读标记、标签分类[6]。报告计数以迁移方案约定的范围为准，所以范围要在评估阶段就写进方案——写到账号、日期区间、文件夹三个粒度，而不是只写「历史邮件」。

第二是数量与成功率。 方案页公布的口径是实测数据丢失率低于 0.01%[6]。核对时有两件事要先约定：

这两项不约定，报告里的「成功率」就无法核对。注意方案页同时标注了一条「自己操作」的对比丢失率，但页面未公布该数字的统计口径与测算方法，不宜作为比较依据。

第三是异常项。 每一条异常都要有结果，三者之一：补迁完成、确认排除、或写明原因与影响范围。没有结果的异常项不能算验收通过。

逐封比对和差异清单怎么做，见邮箱迁移后怎么校验；绝对化的「一封不丢」说法和「丢失率低于 0.01%」为什么要分开看，见邮箱迁移到底靠什么保证数据不丢。

四、适用场景：方案页列了四类

方案页把以下四类列为选择该服务的典型情况[6]：

场景	页面描述	排期上的要点
旧系统到期续费	现有腾讯、网易、263 邮箱合约即将到期，借机升级到阿里邮箱	到期日是硬约束，要把 30 天只读期算进去
集团统一替换	集团把各分支机构分散的邮件系统统一收归为阿里邮箱，集中管控	几套源系统的类型、用户数、数据量要分别统计
降本增效转型	从 Exchange 授权费用切换到 SaaS 模式	原授权到期日与新订阅起始日的衔接
合规性迁移	因数据出境监管或信创要求，从海外邮件服务商迁回国内平台	版本要一次定对：国产化版与标准版、AI 尊享版之间不提供直接升级[3]

支持的源系统有六类：腾讯企业微信邮箱（含企微绑定账号）、网易企业邮箱（含 163/126 企业邮）、263 企业邮箱、Exchange/O365（IMAP/EWS 双协议）、Google Workspace、以及支持标准协议的自建邮件系统[6]。

第四类要特别注意版本不可逆这条规则。 因信创要求迁回国内的单位，如果先开了标准版再发现要国产化版，就得重新购买并再迁一次邮件，而包年包月实例不支持退订[4]。

五、启动前准备四项信息

大成云提供免费的迁移方案与时间线评估[6]。评估前备好四项，方案才能给到可执行的粒度：

拿到方案后先核对五样东西再进报价：时间线、样例账号名单、切换日、报告的计数口径、以及两个 30 天的起止日。大成云自述为阿里云官方授权的西南区域服务中心，属授权服务商而非原厂，开通、迁移、配置与售后在本地完成[8]；服务覆盖四川、重庆、云南、贵州、西藏五省市[9]，代运维口径为本地响应、关键问题可到场，响应时间、解决时间与违约责任写入合同、页面未公布数值[10]。

迁移服务常见问题（FAQ）

要。原厂文档要求开始搬家前先在「通讯录-成员管理」里为要搬家的用户分配阿里邮箱账号[1]。经大成云时，开通按域名与资质准备、账号架构规划、开通与配置、验收与交付四步完成[11]，迁移排在开通之后。已有旧邮箱的企业，开通时先不要动 MX 记录，留到迁移的正式切换这一步再改[6]。

可以。搬家功能支持选全部文件夹并排除不需要的，也支持只搬指定文件夹；邮件可以全搬，也可以只搬指定日期范围内的[1]。范围缩小，迁移量和周期随之变化。经大成云时搬哪些、不搬哪些在现状评估制定迁移策略时定下[6]，《数据迁移报告》按这个范围计数——所以范围要写到账号、日期区间、文件夹三个粒度，否则报告的分母说不清。

可以，方案页把「集团统一替换」列为适用场景[6]。客户案例里一家重庆制造企业的统一邮件系统覆盖全国 12 个分支机构，私有化开通与全量迁移由大成云完成，页面标注 2 周完成全量迁移[7]。几套源系统要分别统计类型、用户数和数据量，排期把每一套都算进去——多源项目的周期通常不是按总账号数估，而是按最慢的那一套估。

三件不要做：修改原邮箱登录密码、删除或移动原系统里的邮件、修改文件夹名称[1]。改密码的后果最直接——该账号的迁移会失败，要在阿里邮箱的「邮箱搬家」里手动更新原密码才能恢复[1]。后两件会让对账基线在迁移过程中变化，导致报告里的数量核不平。收发邮件照常，旧邮箱到正式切换时才停用。

三件。员工侧：改用阿里邮箱收发，用第三方客户端的按原厂方法重新配置[1]——这里有个容易误判的点，新购邮箱默认带一条已开启的「三方客户端访问策略」黑名单策略，需要用客户端的账号要先加为例外或关闭该策略，5 分钟后生效，且该策略同样约束 postmaster[5]。管理员侧：在原邮箱系统解除域名绑定，不解除可能出现同域认证问题、新邮箱无法给原服务商邮箱发信[1]。项目侧：在只读期内完成抽查，并确认两个 30 天的起止日。

当作方案口径来用，不要当作无条件结论。它是方案页公布的服务口径[6]，要落到可核对，必须在方案里同时定义四件事：统计范围（哪些账号、哪个日期区间、哪些文件夹）、计数单位与分母（按封还是按账号）、排除项（源系统本身已损坏或无法读取的邮件怎么算）、判定方法（谁来比对、用什么比对、差多少算异常）。这四项不写，报告上的成功率就只是一个数字。相关讨论见邮箱迁移到底靠什么保证数据不丢。

至少 30 天之后，而且要满足两个条件。时间上，迁移完成后原始系统保留只读访问 30 天用于回退[6]，这期间旧系统要在服务期内。流程上，搬家任务要等原系统 7 天内没有新邮件才转为已完成[1]——也就是说员工必须已经全部切到新邮箱。停用旧系统前建议先完成两件事：只读期内的抽查，以及在原系统解除域名绑定[1]。停用的审批应由企业单独批准，不随验收报告自动生效。

References