试迁移是在正式切换前，用一批有代表性的真实数据走完导入、校验和业务验收，确认迁移规则可用、结果可核对、回退可执行。它回答的是“这套迁移方案在真实数据上是否成立”，范围、样本和验收口径需要事先定清楚。本文按范围界定、前置准备、执行、校验、验收并行、切换回退的顺序展开，并在核对环节说明如何用ONES承载差异跟踪与验收记录。
要点总览（TL;DR）
- 试迁移用受控的真实样本验证迁移规则、校验口径和回退方案，正式迁移在规则确认后处理全量数据并完成切换。
- 启动前应冻结字段映射表，准备好目标空间、账号权限、附件容量和业务验收口径，执行中只引用已确认的映射规则。
- 校验从数量、字段值、附件可打开性和层级关联四个层面取证，差异逐条登记责任人并跟踪到关闭。
- 业务验收按真实场景判断数据能否支撑日常使用，并行运行期间明确单一写入端并定期做双端一致性检查。
- 切换前设定冻结期和停止条件，回退覆盖数据与访问权限恢复，复盘结论作为再次试迁移的准入条件。
试迁移要验证什么：来源、目标与样本范围
试迁移的第一步是把方向写死：从哪个来源系统迁到哪个目标系统，迁移哪些数据对象，用哪批样本验证。方向一旦含糊，后续的字段映射、校验口径和回退方案都会失去基准。试迁移与正式迁移的区别在于数据量和目的：试迁移用受控样本验证规则与流程，正式迁移在规则确认后处理全量数据并完成切换。
纳入试迁移的数据对象应覆盖正式迁移的主要类型，常见包括工作项、需求、缺陷、附件、评论、状态流转记录以及它们之间的关联关系。对象清单建议逐项写明来源侧位置、目标侧落点和是否纳入本次试迁移，形成可核对的表格，而不是停留在口头约定。
样本选择遵循代表性原则，而非随机抽取：
- 覆盖主要工作项类型，每种类型至少若干条，包含自定义类型。
- 覆盖主要状态与优先级取值，特别是边界值和历史遗留的自定义值。
- 覆盖层级结构，包含有子项的父项、跨层级的关联关系。
- 覆盖附件大小区间，包含接近容量上限的大附件和多附件条目。
- 覆盖评论较多、参与人较多的条目，用于验证人员映射与评论归属。
同时要明确不纳入本次试迁移的对象及原因，例如已归档项目、临时测试数据、来源侧已标记废弃的字段。把这些排除项写进范围清单，可以避免验收阶段对“为什么这条没迁”反复解释。范围清单与样本选取说明是本节的核心交付物，后续的批次划分和校验抽样都以此为依据。
开始前需要准备哪些输入与依赖
试迁移启动前应具备的输入如果缺失，执行阶段就会变成边迁边补规则，校验结果也难以归因。建议用一张前置条件核对表逐项确认状态，每项写明负责人和确认时间。
| 前置项 | 确认内容 | 确认标志 |
|---|---|---|
| 字段映射表 | 来源字段与目标字段的对应关系、值转换规则、未映射字段的处理方式 | 映射表版本已冻结，业务与技术双方签字确认 |
| 账号与权限 | 迁移执行账号、目标空间的管理权限、业务验收人的访问权限 | 执行账号可写入目标空间，验收人可查看全部试迁移数据 |
| 目标空间 | 试迁移专用空间或隔离区域，避免与生产数据混淆 | 空间已创建，命名规则已约定 |
| 附件存储与容量 | 目标侧附件存储可用容量、单文件大小限制、存储路径规划 | 容量满足样本附件总量并留有冗余 |
| 迁移工具或导入方式 | 所选工具或导入方式在样本数据上的可用性、版本与运行环境 | 已在少量数据上完成连通性验证 |
| 业务验收人与口径 | 验收角色名单、验收项清单、通过标准 | 验收口径书面确认，验收人已知晓时间安排 |
字段映射表的确认状态尤其关键。试迁移只引用已确认的映射表，不在执行过程中临时设计映射规则；映射设计本身属于前一阶段的工作，试迁移负责观察规则落地后的实际效果。若执行中发现映射表存在缺口，应记录为待确认项，由映射负责人更新版本后再进入下一批次，而不是现场口头修改。
业务验收人和验收口径需要在启动前确定。验收人应来自实际使用目标系统的业务团队，验收项要具体到“某类工作项的状态与来源一致”“附件可正常打开”这类可判断的条目，避免使用“整体可用”这类无法核验的表述。
试迁移的执行步骤与字段映射落地
执行阶段按批次推进，每批完成后先校验再进入下一批，避免问题累积到最后一次性暴露。批次划分可按数据对象类型（先工作项、再附件与评论）或按项目范围（先一个代表性项目、再扩展）进行，具体顺序取决于依赖关系：附件和评论依赖工作项先存在，关联关系依赖两端对象都已导入。
典型执行顺序如下：
- 导入基础数据：人员、组织、字典类枚举值，确保后续对象有可引用的目标。
- 导入首批工作项，仅核心字段，验证字段映射的基本正确性。
- 补齐扩展字段与状态流转记录，观察枚举值转换结果。
- 导入附件与评论，验证关联关系是否正确挂接。
- 导入父子层级与跨对象关联，核对结构完整性。
- 每批结束后执行抽样校验，记录结果后再启动下一批。
同名字段含义不同是试迁移中最容易出问题的环节。例如来源系统的“优先级”是三级、目标系统是五级，或来源的“状态”包含目标系统没有的自定义值。处理方式是回到映射表查找已确认的转换规则，按规则执行并记录实际转换结果；映射表未覆盖的情况登记为差异，交由映射负责人补充规则，不在导入脚本中临时硬编码。
状态、优先级、人员等枚举值的对应关系应在批次记录中逐项列出实际转换结果，便于校验阶段比对。人员映射要特别关注离职人员、外部协作人员以及同名不同人的情况，这些在试迁移中暴露比在正式切换后暴露代价低得多。
附件与评论的关联方式需要在执行前确认：附件是随工作项一并导入还是单独导入后挂接，评论的作者归属如何映射，评论中的提及关系是否保留。导入过程中应开启日志记录，逐条记录成功、失败和跳过的数据及原因，异常记录要包含来源标识、失败环节和错误信息，作为后续差异跟踪的原始输入。
完整性与附件校验怎么做
校验的目标是用可复核的证据回答三个问题：数量对不对、内容对不对、关系对不对。建议在试迁移开始前就确定抽样比例和比对方法，避免校验阶段临时决定标准。
数量校验以来源侧统计为基准，逐类比对导入前后的记录数，差异必须能逐条解释。字段值校验采用抽样比对：按工作项类型、状态、优先级分层抽样，逐字段对照来源与目标的值，重点检查经过转换的枚举字段、日期字段和长文本字段。抽样结果记入校验记录，注明抽样方法和覆盖范围。
附件校验包含三个层面：
- 数量与大小：附件总数、总容量与来源侧统计一致，单文件大小与来源记录相符。
- 可打开性：抽样下载并打开附件，确认文件未损坏、编码正常。
- 挂接正确性：附件挂在对应的工作项下，多附件条目的顺序或标识可区分。
父子层级与关联关系的核对需要结构化进行：抽取若干有子项的父项，确认子项数量与层级深度一致；抽取跨对象关联（如需求与缺陷的关联、工作项与测试用例的关联），确认关联两端都存在且指向正确。层级错位和关联丢失在试迁移阶段发现，修复成本远低于切换之后。
差异记录表建议包含以下列，并明确每列的责任人：
| 字段 | 说明 | 责任人 |
|---|---|---|
| 差异编号 | 唯一标识，便于跟踪 | 校验执行人 |
| 来源标识 | 来源系统中的对象编号或路径 | 校验执行人 |
| 差异类型 | 数量、字段值、附件、关联关系等分类 | 校验执行人 |
| 差异描述 | 期望值与实际值的对照 | 校验执行人 |
| 原因判断 | 映射规则问题、工具问题、源数据问题 | 技术负责人 |
| 处理方式 | 修正映射、重新导入、接受差异并说明 | 技术负责人 |
| 关闭状态 | 待处理、处理中、已关闭、挂起 | 差异跟踪人 |
校验结果与差异清单是进入业务验收的前提。存在未关闭的高优先级差异时，应推迟验收或明确验收范围，而不是带着已知问题进入下一阶段。
业务验收与并行运行安排
技术校验通过只说明数据搬过去了，业务验收要回答的是“搬过去的数据能不能支撑日常使用”。验收角色通常包括业务负责人、一线使用者和系统管理员：业务负责人确认关键流程可用，一线使用者按真实场景操作，系统管理员确认权限与配置符合预期。
验收项应具体可判断，例如：按来源中的典型场景在目标系统中走一遍需求到缺陷的流转；检查自己负责的工作项列表与来源一致；打开常用附件确认内容完整；确认评论中的讨论上下文可读。验收结论分为通过、有条件通过和不通过三档，有条件通过需列明遗留项和处理期限。
验收不通过时的处理路径应事先约定：定位差异属于映射规则、工具执行还是源数据质量问题，由对应责任人修复后重新导入受影响批次，再重新验收。若问题涉及映射规则变更，需更新映射表版本并评估对已导入数据的影响范围，必要时整体重跑试迁移。
并行运行是试迁移与正式切换之间的过渡安排，目的是在真实业务节奏下观察目标系统是否稳定可用。并行运行的时长取决于业务复杂度与风险容忍度，常见做法是覆盖一个完整的业务周期（如一个迭代或一个月度结算周期）。并行期间的数据写入规则必须明确：通常约定来源系统为唯一写入端，目标系统只读用于验证；若确需双端写入，则要指定主数据端并约定冲突处理方式，否则双端数据会迅速分叉。
并行期间的一致性检查按固定频率执行，比对两端的关键指标：新增工作项数量、状态变更记录、附件增量。发现不一致时记录差异并判断原因，属于规则问题的回到映射表，属于操作问题的明确写入规范。
切换窗口、停止条件与回退方案
切换窗口的选择要兼顾业务低峰与人员可用。常见做法是选择业务活动较少的时段（如周末或版本间隙），并设置冻结期：冻结期内来源系统停止新增和修改，只允许查询，确保切换期间数据不再变化。冻结期的长度取决于切换操作所需时间和验证所需时间，需要在切换预案中写明起止时间与通知方式。
触发停止或回退的条件应在切换前明确列出，典型条件包括：
- 关键数据对象数量差异超过约定阈值且无法在窗口内解释。
- 核心业务场景在目标系统无法完成，影响次日正常工作。
- 附件大面积不可访问或存储异常。
- 权限配置错误导致业务人员无法访问应有数据。
回退方案要覆盖数据与访问权限两方面：数据侧明确回退到来源系统继续使用的操作步骤，以及在目标系统已产生的数据如何处理（保留隔离、标记作废或按规则合并）；权限侧明确恢复来源系统访问的时间点和责任人，确保业务人员不被卡在两个系统之间。回退决策需要指定唯一决策人，避免多头判断延误时机。
回退发生后应组织复盘，定位触发回退的根本原因，判断属于映射规则、工具执行、容量规划还是流程安排问题。再次试迁移的条件包括：根本原因已修复并有验证证据、映射表已更新并重新确认、回退中暴露的流程缺口已补入预案。复盘结论与再次试迁移的准入条件一并写入切换与回退预案，形成闭环。
用ONES承载试迁移期间的核对与验收
试迁移过程中会产生大量需要跟踪的事项：校验差异、待确认的映射缺口、验收遗留项、回退复盘行动项。这些事项如果散落在表格和聊天记录里，责任人和关闭状态很容易失真。把试迁移本身作为一个项目来管理，可以让核对与验收有统一的承载位置。
具体做法上，校验阶段发现的每条差异登记为工作项，填写来源标识、差异类型和期望值与实际值，指派给对应责任人，用状态流转跟踪从待处理到已关闭的全过程。差异工作项可以按批次或按差异类型分组，便于在每日核对会上快速过一遍未关闭项。业务验收的结论同样以工作项或验收记录的形式留存，有条件通过的遗留项直接转为待办并设定处理期限。
试迁移的范围清单、映射表确认记录、批次执行日志和验收结论适合放在文档中集中留存，与差异工作项相互引用。这样在切换评审时，评审人可以从范围文档追溯到具体差异的处理结果，而不需要重新收集材料。试迁移与正式切换的任务可以在同一处交接：试迁移的关闭条件、遗留项和切换前置检查项直接作为切换任务的输入，减少两阶段之间的信息丢失。
这套承载方式适用于试迁移涉及多批次、多责任人的场景；若试迁移范围很小、差异数量有限，用一张结构化的差异表配合定期核对也能满足要求。关键不在于工具本身，而在于每条差异都有唯一责任人、明确状态和可追溯的处理记录。
常见问题
试迁移的样本量应该多大？
样本量没有统一标准，判断依据是覆盖度而非绝对数量。样本需要覆盖主要工作项类型（含自定义类型）、主要状态与优先级取值（含边界值和历史自定义值）、有子项的父项与跨层级关联、接近容量上限的大附件，以及评论和参与人较多的条目。每类至少若干条，确保校验时能观察到映射规则的实际效果。样本过少会漏掉边界情况，样本过多则拉长校验周期，通常以能在数天内完成一轮完整校验为宜。
试迁移中发现映射表有缺口，应该停下来还是继续导入？
建议按批次停下来处理。试迁移只引用已冻结的映射表，现场口头修改会让后续批次的校验结果失去可比性。正确做法是把缺口登记为待确认项，由映射负责人更新映射表版本并确认，再决定是否重跑受影响批次。如果缺口只影响少量非关键字段，也可以记录差异后继续后续批次，但要在验收前明确该差异的处理结论。
并行运行期间两端都有人录入数据怎么办？
并行运行需要事先约定写入规则。常见做法是以来源系统为唯一写入端，目标系统只读用于验证，这样两端数据不会分叉。如果业务上确需双端写入，必须指定主数据端，并约定冲突时的处理方式，例如以主数据端为准、另一端的修改在切换时人工核对。无论采用哪种方式，都要按固定频率比对新增工作项数量、状态变更记录和附件增量，发现不一致时判断属于规则问题还是操作问题。
什么情况下应该放弃本次切换直接回退？
触发回退的典型条件包括：关键数据对象数量差异超过约定阈值且无法在切换窗口内解释；核心业务场景在目标系统无法完成，影响次日正常工作；附件大面积不可访问或存储异常；权限配置错误导致业务人员无法访问应有数据。回退决策应指定唯一决策人，避免多头判断延误时机。回退后需要复盘根本原因，修复并有验证证据、映射表更新确认、流程缺口补入预案之后，再安排下一次试迁移。
试迁移范围很小，还需要单独建项目来跟踪差异吗？
不一定。差异数量有限时，一张结构化差异表配合定期核对即可满足要求，表中包含差异编号、来源标识、差异类型、期望值与实际值、责任人、处理方式和关闭状态。当试迁移涉及多批次、多责任人，或者差异需要与验收记录、切换任务相互引用时，把试迁移作为项目来管理会更便于追溯。判断标准是每条差异能否找到唯一责任人和可查的处理记录。
