研发数据迁移盘点清单以“一行一个待迁移对象集合”为记录单位，把对象类型、来源位置、数据量、负责人、敏感级别、迁移优先级、依赖关系、目标位置和盘点状态放在同一张表里。对象类型多时靠分类维度归集，项目并行时靠项目归属拆行，多套用户目录并存时靠目录来源与映射状态区分。本文给出一张可直接复制的空白表、逐字段口径、必填规则、分类维度、一条填写示例和维护方法；清单落地时也可借助项目与工作项管理工具承载记录与状态流转。
要点总览（TL;DR）
- 盘点清单以“一行一个待迁移对象集合”为记录单位，同一对象类型在不同项目或空间下拆行，便于并行盘点与分别确认。
- 核心字段覆盖对象类型、来源位置、数据量、业务负责人、系统管理员、敏感级别、迁移优先级、依赖关系、用户目录来源、账号映射状态、目标位置与盘点状态。
- 分类按对象类型、敏感级别、迁移优先级、依赖关系四条主线展开，项目/空间归属与用户目录来源作为辅助线解决并行项目与多目录归集。
- 必填字段缺失时该行不进入“已确认”状态、不纳入首批排期；涉及账号数据的记录，用户目录来源与账号映射状态按必填处理。
- 清单在盘点期间按状态推进并保留变更记录，多人并行维护时可搬进项目与工作项管理工具承载记录与流转。
可复制空白盘点清单模板
下表为空白模板，复制到表格工具后即可逐行填写。记录约定：一行对应一个待迁移对象集合，同一对象类型在不同项目或空间下应拆成多行，便于各项目并行盘点、分别确认；同一行内不混放两种对象类型。
| 记录编号 | 对象类型 | 来源系统 | 来源位置 | 项目/空间归属 | 数据量（条数） | 附件量（个/容量） | 业务负责人 | 系统管理员 | 敏感级别 | 迁移优先级 | 依赖关系 | 用户目录来源 | 账号映射状态 | 目标位置 | 盘点状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表头中的“来源系统”用于区分 Jira 类、Confluence 类或其他来源；“来源位置”写到项目键、空间名或目录路径一级；“目标位置”写到目标项目、目标空间或目标组织节点。记录编号建议采用“来源系统缩写-项目缩写-序号”的格式，便于跨项目汇总时定位。
字段说明：每个字段填什么、怎么填
字段口径统一是清单可汇总的前提。同一份清单由多个项目组分别填写时，先约定取值规则再开始盘点，比事后清洗更省力。下表逐字段说明含义与填写方式。
| 字段名 | 含义 | 取值口径 | 填写方式 |
|---|---|---|---|
| 记录编号 | 清单内唯一标识 | 来源系统缩写-项目缩写-三位序号 | 新增行时顺延编号，不复用已作废编号 |
| 对象类型 | 待迁移对象的类别 | 先按来源系统分大类，再按对象细分：项目、工作项（需求/缺陷/任务）、状态与字段配置、工作流配置、附件、评论与历史记录、空间、页面、用户与用户组、权限结构 | 选一个最细粒度类型填写，不写“其他数据”这类笼统值 |
| 来源系统 | 数据当前所在系统 | 按实际系统名称填写 | 同一系统内不同实例需在来源位置中注明 |
| 来源位置 | 对象在源系统中的定位 | 项目键、空间名、目录路径或配置节点 | 写到可直接检索到该对象集合的层级 |
| 项目/空间归属 | 对象所属的业务项目或知识空间 | 按源系统原有归属填写 | 跨项目共享的对象单独成行并注明共享范围 |
| 数据量（条数） | 对象记录数量 | 统计时点统一，例如“导出前一日快照” | 填写整数，并在表头或备注注明统计时点 |
| 附件量（个/容量） | 附件数量与总体积 | 同时记录个数与容量，容量单位统一为 GB | 无附件填 0，不空置 |
| 业务负责人 | 对内容准确性负责的人 | 熟悉该批数据业务含义的成员 | 填写姓名与所属团队，便于并行项目对接 |
| 系统管理员 | 对导出与迁移执行负责的人 | 具备源系统管理权限的成员 | 与业务负责人分开填写，避免职责混同 |
| 敏感级别 | 数据敏感程度 | 公开、内部、敏感、严格受限四级 | 按分级标准判定后填写，判定依据写入备注 |
| 迁移优先级 | 迁移先后顺序 | P1 首批、P2 次批、P3 收尾 | 依据业务连续性影响、依赖层级、数据体量综合判定 |
| 依赖关系 | 与其他对象的先后约束 | 记录“本对象依赖谁”与“谁依赖本对象”两个方向 | 写记录编号，跨项目依赖注明来源项目 |
| 用户目录来源 | 账号所属目录 | 按实际目录名称填写，如主目录、并购方目录、外包目录 | 每条记录标注，涉及多目录时分行 |
| 账号映射状态 | 源账号在目标侧的对应情况 | 已映射、待映射、无对应账号、需合并 | 由系统管理员核对后更新 |
| 目标位置 | 迁移后的落点 | 目标项目、目标空间或目标组织节点 | 盘点阶段可先填拟定值，确认后转正式值 |
| 盘点状态 | 该行盘点进度 | 待盘点、盘点中、已确认、已冻结 | 按推进规则更新，不跳级 |
数据量字段建议同时保留条数与附件容量两个口径。只记条数容易低估附件体量，导致迁移窗口估算偏短；只记容量则无法判断记录级映射的工作量。负责人分两列填写，是因为内容确认与导出执行通常由不同角色完成，合并成一列会在并行项目里出现互相等待。
必填与选填：哪些字段不能空
必填字段决定一行记录能否进入迁移排期，选填字段用于补充判断。下表给出取舍与空缺处理规则。
| 字段 | 必填/选填 | 理由或适用情形 |
|---|---|---|
| 记录编号 | 必填 | 汇总、去重与依赖引用都依赖唯一编号 |
| 对象类型 | 必填 | 分类维度的基础，缺失则无法归集 |
| 来源系统、来源位置 | 必填 | 定位对象集合，缺失则无法执行导出 |
| 项目/空间归属 | 必填 | 并行项目拆分盘点的依据 |
| 数据量（条数） | 必填 | 排期与窗口估算的输入 |
| 业务负责人 | 必填 | 内容确认的责任人，缺失则无法验收 |
| 敏感级别 | 必填 | 决定访问控制与迁移方式 |
| 迁移优先级 | 必填 | 分批排期的直接依据 |
| 用户目录来源 | 涉及账号数据时必填 | 多套目录并存时用于区分账号来源 |
| 账号映射状态 | 涉及账号数据时必填 | 映射未完成会阻断权限结构迁移 |
| 附件量 | 选填 | 无附件对象填 0；有附件时建议填写 |
| 系统管理员 | 选填 | 盘点初期可空缺，进入导出准备前补齐 |
| 依赖关系 | 选填 | 无依赖填“无”；有依赖必须写编号 |
| 目标位置 | 选填 | 盘点阶段可填拟定值 |
| 备注 | 选填 | 记录判定依据、例外说明 |
必填字段缺失时，该行不得进入“已确认”状态，也不纳入首批排期，由业务负责人补齐后再提交。多套用户目录并存时，凡涉及用户、用户组与权限结构的记录，用户目录来源与账号映射状态按必填处理；同一账号在多个目录重复出现时，分行记录并在备注注明合并意向，避免汇总时重复计数。
分类维度：对象类型、敏感级别、优先级与依赖关系
清单按四条主线分类，两条辅助线归集。主线决定“迁什么、先迁什么”，辅助线解决并行项目与多目录下的归属问题。
四条主线
- 对象类型：先按来源系统分大类，再细分为项目、工作项（需求、缺陷、任务）、状态与字段配置、工作流配置、附件、评论与历史记录、空间、页面、用户与用户组、权限结构。细分到可直接导出的一级，避免大类下混装。
- 敏感级别：采用公开、内部、敏感、严格受限四级。判定依据包括数据是否含个人信息、是否涉及未公开的经营信息、原系统权限范围大小。标注方式为在敏感级别列填级别，备注列写判定依据，便于复核时口径一致。
- 迁移优先级：P1 首批覆盖业务连续性影响大的对象，例如在用项目的活跃工作项与核心页面；P2 次批覆盖历史数据与低频空间；P3 收尾覆盖归档类数据。判定时同时看依赖层级，被多个对象依赖的配置类数据应提前。
- 依赖关系：分对象间依赖与跨项目依赖。对象间依赖如工作项依赖字段配置、页面依赖附件；跨项目依赖如共享的用户组被多个项目引用。记录时写双向关系，跨项目依赖注明来源项目编号。
两条辅助线
项目/空间归属用于把并行项目的盘点结果分开汇总，每个项目组只对自己名下的行负责确认。用户目录来源用于多套目录并存时的归集：同一人员在不同目录有账号时，按目录分行，账号映射状态列标注“需合并”，汇总时以人员为粒度去重，不以账号为粒度计数。
维度组合形成分批视图
把主线与辅助线组合，可以得到可执行的分批视图。例如“对象类型=工作项 + 敏感级别=内部 + 优先级=P1 + 项目归属=A 项目”构成 A 项目首批工作项迁移范围；“对象类型=用户与用户组 + 用户目录来源=外包目录 + 账号映射状态=待映射”构成账号映射专项清单。建议每次排期只组合两到三个维度，维度过多会导致每批范围过窄、协调成本上升。
填写示例：一条完整记录
以下为一条已填写的记录，字段与 S1 模板一一对应，用于示范字段与分类维度如何配合。示例为演示情景，不代表真实项目数据。
| 字段 | 填写值 |
|---|---|
| 记录编号 | JIRA-PROJA-007 |
| 对象类型 | 工作项-需求 |
| 来源系统 | Jira |
| 来源位置 | 项目键 PROJA，问题类型“需求” |
| 项目/空间归属 | A 项目 |
| 数据量（条数） | 1,240 条（统计时点：导出前一日快照） |
| 附件量（个/容量） | 386 个 / 2.4 GB |
| 业务负责人 | 张某某（A 项目产品组） |
| 系统管理员 | 李某某（研发效能组） |
| 敏感级别 | 内部 |
| 迁移优先级 | P1 |
| 依赖关系 | 依赖 JIRA-PROJA-003（字段配置）；被 JIRA-PROJA-011（评论与历史记录）依赖 |
| 用户目录来源 | 主目录 |
| 账号映射状态 | 已映射 |
| 目标位置 | 目标项目 A-研发 |
| 盘点状态 | 已确认 |
| 备注 | 含少量客户反馈原文，按内部级管控；附件以设计稿为主 |
敏感级别判为“内部”，依据是数据含客户反馈原文但未涉及个人信息与未公开经营信息，权限范围限于项目成员。优先级判为 P1，依据是该批需求仍在迭代中使用，业务连续性影响大，且被评论与历史记录依赖，提前迁移可减少后续批次的等待。依赖关系写成双向，便于排期时同时看到前置与后置对象。账号映射状态填“已映射”，说明该批工作项的创建人与经办人已在目标侧找到对应账号；若存在外包目录账号，应另起一行记录并标注“待映射”。
调整与维护：清单随盘点推进如何更新
清单在盘点期间是活文档，需要固定的更新规则，否则并行项目各自修改会造成口径漂移。以下规则可按团队实际情况取舍。
- 新增对象类型的追加规则：盘点中发现模板未覆盖的对象类型，先在对象类型列新增细分值并在备注说明来源，再由清单维护人统一并入类型清单，避免各项目自造名称。新增行沿用编号规则顺延。
- 优先级与敏感级别的变更记录方式：变更时保留原值，在备注写明变更原因与变更人，例如“P2 调为 P1：该批页面被三个项目引用”。批量调整由维护人统一执行，个人不直接改他人负责的行。
- 盘点状态推进规则：按待盘点、盘点中、已确认、已冻结顺序推进。进入已确认需必填字段齐全且业务负责人签字确认；进入已冻结表示该行数据量与范围锁定，后续变更需重新打开。
- 多项目并行的汇总与去重：每周按项目归属汇总一次，以记录编号去重；共享对象与多目录账号按人员或对象粒度合并计数，合并结果单独成表，不覆盖项目明细。
- 清单归档与交接：每批迁移完成后，将该批记录状态置为已冻结并归档，归档件包含清单快照与变更记录；负责人变动时，交接双方在备注列签署交接说明，系统管理员同步更新。
当清单需要多人并行维护、按状态流转并保留变更痕迹时，可以把表格搬进项目与工作项管理工具承载：每行记录对应一个工作项，盘点状态对应工作项状态，负责人与依赖关系用字段和关联关系表达，变更记录留在操作历史中。ONES 的项目与工作项管理可用于承载这类记录与状态流转；涉及 Jira 或 Confluence 数据迁移时，官方资料说明迁移范围覆盖项目、工作项、状态、字段、流程、附件与历史记录，以及空间、页面、附件和权限结构，并包含用户、用户组与系统配置，盘点清单可据此核对对象类型是否齐全。多套用户目录并存时的账号映射与合并规则，需在正式迁移前与实施方确认。
常见问题
盘点清单里的数据量应该按条数还是按容量统计？
建议两个口径都保留：条数用于判断记录级映射与字段对应的工作量，附件容量用于估算迁移窗口与存储占用。只记条数容易低估附件体量，只记容量则无法判断逐条处理的工作量。统计时点要统一，例如约定为“导出前一日快照”，并在表头或备注注明，避免各项目在不同时间点取数导致汇总失真。
多套用户目录并存时，账号记录怎么在清单里归集和去重？
凡涉及用户、用户组与权限结构的记录，按目录分行填写，用户目录来源列标注实际目录名称，账号映射状态列填写已映射、待映射、无对应账号或需合并。同一人员在不同目录有账号时，分行记录并在备注注明合并意向；汇总时以人员为粒度去重，不以账号为粒度计数，合并结果单独成表，不覆盖各项目的明细行。
迁移优先级和依赖关系应该先填哪个？
先填依赖关系，再定优先级。被多个对象依赖的配置类数据（如字段配置、权限结构）如果排在后面，后续批次会持续等待，因此依赖层级是优先级判定的输入之一。实际操作中可先按业务连续性影响给出初判优先级，再对照依赖关系调整：前置对象上调，纯归档类数据下调。调整时保留原值并在备注写明原因与变更人。
盘点进行到一半发现模板缺了某类对象，怎么追加？
先在对象类型列新增细分值，并在备注说明该类型的来源与范围，再由清单维护人统一并入类型清单，避免各项目自造名称造成汇总困难。新增行沿用编号规则顺延，不复用已作废编号。如果新增类型涉及账号或权限，用户目录来源与账号映射状态同步按必填处理。
清单需要多人同时维护时，用表格还是放进管理系统？
取决于并行项目数量与变更频率。项目少、盘点周期短时，共享表格加维护人统一合并即可；项目多、需要按状态流转并保留变更痕迹时，可把每行记录对应为一个工作项，盘点状态对应工作项状态，负责人与依赖关系用字段和关联关系表达，变更记录留在操作历史中。ONES 的项目与工作项管理可用于承载这类记录与状态流转。涉及 Jira 或 Confluence 数据迁移时，官方资料说明迁移范围覆盖项目、工作项、状态、字段、流程、附件与历史记录，以及空间、页面、附件和权限结构，并包含用户、用户组与系统配置，可据此核对对象类型是否齐全；多套用户目录并存时的账号映射与合并规则，需在正式迁移前与实施方确认。
