试迁移是在正式切换前，用一小批真实数据走完“导出—清洗—导入—核对—回退”全流程的演练。它要回答的核心问题是：现有数据能否按预期进入目标系统，核对结果是否可接受，出问题时能否撤回。下面按范围界定、准备输入、分批执行、核验证据、回退与停止条件五个环节展开，并说明每一步的交付物。
要点总览（TL;DR）
- 试迁移用一小批真实数据走完导出、清洗、导入、核对、回退全流程，目的是在正式切换前确认数据能否按预期进入目标系统、结果是否可接受、出问题能否撤回。
- 开始前先写范围说明：固定源与目标系统及版本、纳入的对象类型、样本选取规则（按项目、时间窗或业务关键度）和不覆盖项，再由迁移执行人与业务核对人共同确认。
- 执行时按对象类型与数据量切分批次并固定编号，逐批记录导出数、导入成功数、失败数与处理人；失败条目单独隔离，重试沿用原批次编号加后缀。
- 核验以证据为准：按对象类型做数量比对、关键字段抽样比对、附件与关联关系完整性检查、权限可见范围抽查，通过标准在演练前写入核验表。
- 试迁移阶段完成一次回退演练，确认目标环境可恢复、源系统未被改动；关键字段大面积错位、附件缺失、权限越界或回退失败时暂停，修正后复测再讨论全量切换。
试迁移要验证什么：来源、目标与样本范围
试迁移的第一步是把“迁移什么、迁到哪里、验证到什么程度”写成一份范围说明。没有这份说明，后续的批次划分和验收口径都会失去依据。范围说明需要固定四个要素：源系统与目标系统及各自版本、纳入演练的对象类型、样本规模与选取规则、本次不覆盖的内容。
源与目标要写到具体版本。同一产品不同版本在字段类型、附件存储方式、权限模型上可能存在差异，版本信息决定了后续核对时以哪一方的行为为准。如果迁移同时涉及项目数据与知识库页面，应分别列出两条迁移链路，各自界定对象范围。
对象类型建议逐项列清，常见包括：工作项及其状态与历史记录、需求与缺陷、附件、评论、字段值、关联关系、权限与可见范围。每一类对象都要说明本次是否纳入演练。纳入的对象类型越多，核验工作量越大，首次试迁移可以优先覆盖业务关键度高、结构复杂的对象。
样本选取通常有三种规则，可组合使用：
- 按项目选取：挑一个结构完整、使用活跃的代表性项目，能覆盖多数字段和流程分支。
- 按时间窗选取：截取近三个月或某个迭代周期内的数据，规模可控且贴近当前业务。
- 按业务关键度选取：优先纳入核心产品线或对外交付相关的工作项，验证关键链路。
样本规模没有统一标准，取决于对象复杂度和核对人力。原则是样本足以暴露字段映射、附件关联、权限继承方面的问题，同时核对工作能在一到两个工作日内完成。范围说明中还应写明不覆盖项，例如历史归档项目、已停用账号的个人数据、依赖定制插件的特殊字段。把这些边界提前写清，可以避免验收时对“为什么这类数据没迁”产生争议。
本环节的交付物是一份试迁移范围说明，包含源/目标及版本、对象清单、样本规则、不覆盖项四部分，由迁移执行人与业务核对人共同确认。
开始前需要准备哪些输入与依赖
试迁移中途卡住的常见原因，是权限、环境或责任人没有提前到位。启动前应把下列输入逐项确认，形成准备清单。
| 准备项 | 具体要求 | 责任角色 |
|---|---|---|
| 源系统导出权限 | 能导出样本范围内的全部对象类型，含附件与评论 | 系统管理员 |
| 目标系统导入权限 | 具备创建项目、导入工作项、上传附件、配置权限的权限 | 系统管理员 |
| 测试或预发环境 | 与生产环境隔离，导入数据不进入正式业务视图 | 系统管理员 |
| 字段清单与映射草案 | 源端字段清单已导出，映射草案已形成初稿 | 迁移执行人 |
| 核对人员 | 熟悉原业务数据的业务核对人已排期 | 业务核对人 |
| 时间窗 | 明确演练起止时间，以及源系统冻结写入的时段 | 迁移执行人 |
字段清单与映射草案是试迁移的关键输入。映射方案本身如何设计属于另一项工作，本文不展开，但试迁移开始前至少要有一份可执行的初稿，否则导入阶段无法判断字段错位是映射问题还是执行问题。
角色分工要落到交付物上：迁移执行人负责导出、清洗、导入与批次记录；业务核对人负责按核验表比对业务含义是否正确；系统管理员负责环境、权限与回退操作。三个角色在演练期间应保持可联系状态，异常出现时能当场判断是重试还是暂停。
时间窗安排上，建议在演练期间对源系统采取只读或限制写入的措施，避免样本数据在导出后继续变化，导致核对时源端与目标端不一致。如果业务无法完全冻结，应记录冻结时段内发生的变更，并在核对时排除这部分差异。
本环节的交付物是试迁移准备清单与角色分工表，逐项标注完成状态和责任人，全部就绪后再进入执行。
试迁移的执行步骤：分批导入与过程记录
执行阶段的核心是把样本切成可控的批次，逐批走完导出、清洗、导入，并为每一批留下可追溯的记录。一次性导入全部样本，一旦中途失败，很难定位问题出在哪类对象、哪个环节。
批次切分建议按对象类型与数据量结合进行。例如第一批导入工作项主体与状态，第二批导入评论与历史记录，第三批导入附件，第四批导入关联关系与权限。每批固定编号，如 B01、B02，编号在后续所有记录中保持一致。批次顺序遵循依赖关系：被引用的对象先导入，引用方后导入，避免关联关系指向不存在的对象。
每批的执行动作按固定顺序进行：
- 从源系统导出该批次数据，记录导出时间与对象数量。
- 按映射草案清洗数据，处理格式转换、空值、超长字段等已知问题，清洗规则记入批次记录。
- 导入目标系统，保存导入日志。
- 对该批次做初步计数核对，确认导入数量与导出数量一致或差异可解释。
- 更新批次记录表，标记本批状态为通过、部分失败或失败。
批次记录表建议包含以下字段，便于事后追溯和复测：
| 字段 | 说明 |
|---|---|
| 批次编号 | 如 B01，全程唯一 |
| 对象类型 | 本批涉及的工作项、附件、评论等 |
| 导出数量 / 导入成功数 / 失败数 | 三个数字并列，差异需说明原因 |
| 失败原因 | 字段超长、附件格式不支持、权限冲突等具体描述 |
| 处理方式 | 重试、隔离待处理、调整映射后重导 |
| 处理人 | 实际执行处理的人员 |
| 时间 | 导出、导入、处理完成的时间点 |
失败条目应单独隔离，不与下一批混合。隔离条目先分析原因：属于数据本身问题的，记录后单独处理；属于映射或工具问题的，暂停后续批次，修正后再重试。重试时沿用原批次编号加后缀，如 B01-R1，保持记录连续。
过程中要对源系统保持只读保护，目标系统的导入操作应限定在测试或预发环境内，并确保该环境的数据可以整体清除。这样即使某批导入出现严重错位，也能回到干净状态重新开始，不影响正式业务数据。
在批次记录与核对结果的承载上，可以把每个批次作为一个工作项，用状态字段标记“待执行、执行中、部分失败、通过”，把核对结论和异常说明记录在对应工作项下。ONES 支持围绕项目、工作项、状态、字段、附件和历史记录进行迁移，最大程度保持研发过程连续（F1）；把试迁移本身的批次与核对过程也放进工作项管理，能让执行人和核对人看到同一份进度，减少口头同步。具体字段与状态配置需结合团队实际流程确认。
核验与证据：怎么判断试迁移通过
试迁移是否通过，应以逐项核对的结果为准，避免凭导入成功的提示或整体观感下结论。核验分四个层面，每个层面都要留下证据。
数量核对。按对象类型分别比对源端与目标端的计数：工作项总数、各状态分布数量、附件数量、评论数量、关联关系数量。计数不一致时，要能定位到具体批次和具体条目，而不是只记录一个总数差异。
字段核对。对关键字段做抽样比对，抽样比例可按对象类型设定，例如核心工作项全量比对，普通工作项抽取一定比例。比对内容包括字段值是否一致、枚举值是否落到正确选项、日期与人员字段是否正确对应。抽样结果记录在核验表中，标注样本编号与比对结论。
完整性检查。重点看附件能否打开、评论是否挂在正确的工作项下、父子关系与关联关系是否保留、历史记录中的状态变更是否可读。附件和关联关系是试迁移中最容易出现缺失的部分，应逐批抽查而非只看总数。
权限抽查。选取若干不同角色的账号，检查其在目标系统中能看到的工作项范围是否与源系统一致，特别关注跨项目可见性、受限项目的访问控制。权限越界属于严重问题，发现即应记录并触发暂停判断。
通过标准建议在演练前就写进核验表，例如：数量差异为零或全部可解释；关键字段抽样一致率达到约定阈值；附件与关联关系无缺失；权限抽查无越界。任一层面不达标，该批次判定为不通过，修正后复测。证据留存形式包括核验表、关键页面截图、导入日志导出文件，按批次归档，作为是否进入全量切换的判断依据。
ONES 的迁移方案把数据完整、业务连续和系统稳定作为目标，并建议在正式迁移前确认数据范围、功能匹配和系统适配（F3、F5）。试迁移的核验表正是把这些目标落到可检查条目上的方式；具体验收阈值仍需按项目实际情况确定。
回退与停止条件：什么情况下不进入全量切换
试迁移阶段必须完成一次回退演练，确认出问题时能撤回，而不只是假设可以撤回。回退演练的范围可以选一个已完成导入的批次，执行清除或还原操作，然后确认两件事：目标系统回到导入前的状态，源系统数据未被改动。
回退后要逐项确认状态：目标环境中该批次的数据是否已清除干净，是否残留孤立附件或关联记录；源系统的数据完整性是否不受影响；相关账号的权限配置是否恢复原状。回退记录与批次记录一并归档，写明回退范围、执行人、耗时和确认结果。
以下情况可作为触发停止、暂不进入全量切换的典型条件：
- 关键字段出现大面积错位，抽样一致率明显低于约定标准，且原因未定位。
- 附件缺失或无法打开的比例超出可接受范围。
- 权限抽查发现越界访问，即目标系统中出现了源系统中本不可见的对象。
- 回退演练未能将目标环境恢复到预期状态。
- 失败条目集中在某一类对象，且重试后仍无法解决。
停止后的处置路径是：先定位问题属于数据、映射还是执行环节，修正后重新选取样本复测，复测通过再讨论全量切换的时间安排。复测应覆盖此前失败的批次和受影响的关联对象，不能只重跑失败条目本身。对于依赖定制插件的特殊场景，迁移前需要逐项评估，避免直接假设所有插件都能一一对应（F4），这类评估结论也应纳入是否继续的判断。
本环节的交付物是回退演练记录与停止/继续判断条件清单，由迁移执行人与业务核对人共同签字确认，作为进入全量切换的前置条件。
常见问题
试迁移的样本要选多少才够？
样本规模没有统一标准，取决于对象复杂度和可投入的核对人力。判断依据是样本能否暴露字段映射、附件关联和权限继承方面的问题，同时核对工作能在一到两个工作日内完成。首次试迁移可以优先覆盖业务关键度高、结构复杂的对象，例如一个结构完整、使用活跃的代表性项目，再叠加近一个迭代周期的数据。样本过小可能漏掉边界情况，过大则核对周期拉长、问题定位变慢。
试迁移期间业务还在源系统里改数据，核对对不上怎么办？
建议在演练期间对源系统采取只读或限制写入的措施，让导出后的样本保持不变。如果业务无法完全冻结，应记录冻结时段内发生的变更对象和变更内容，核对时把这部分差异单独列出并说明原因，不计入迁移缺陷。更稳妥的做法是把试迁移安排在业务低峰期，缩短冻结窗口，减少对日常工作的影响。
某一批导入部分失败，应该整批重来还是只补失败条目？
先分析失败原因再决定。属于单条数据本身问题的，例如字段超长、附件格式不支持，可以隔离后单独处理，不必整批重来；属于映射规则或导入工具问题的，应暂停后续批次，修正后整批重导，避免同一问题在后续批次重复出现。重试时沿用原批次编号加后缀，保持记录连续，便于复测时对照。
试迁移通过后，全量切换前还需要做什么？
试迁移通过说明样本范围内的数据可以按预期迁移，全量切换前还需要把试迁移中形成的清洗规则、批次顺序和核验方法固化为正式迁移方案，确认全量数据量与时间窗匹配，并安排好切换期间的源系统写入控制和回退预案。试迁移中隔离待处理的失败条目要在全量前处理完毕或明确处置方式。依赖定制插件的特殊场景需逐项评估，避免假设所有插件都能一一对应（F4）。
试迁移的核对结果用什么形式留存？
按批次归档三类材料：核验表（记录数量比对、字段抽样结果、完整性与权限抽查结论）、关键页面截图、导入日志导出文件。这些材料是判断是否进入全量切换的依据，也是复测时对照的基准。如果团队使用 ONES 承载迁移过程，可以把每个批次作为一个工作项，用状态字段标记执行进度，把核对结论和异常说明记录在对应工作项下，让执行人和核对人看到同一份进度（F1）。
