研发迁移数据盘点可以按“定范围—拉清单—清脏数据—建映射—留证据”五步推进，每一步都产出可交接的表格或记录。盘点边界要覆盖源系统、目标系统和纳入迁移的数据对象，并在盘点期间处理新增数据、设置冻结写入时点。本文按阶段说明操作方法与核验要求，适合研发效能、项目管理或迁移负责人对照执行。
要点总览（TL;DR）
- 盘点按“定范围—拉清单—清脏数据—建映射—留证据”五步推进，每步产出可交接的表格或记录。
- 范围界定要写清源系统与目标系统版本、纳入的数据对象和排除项，流程配置与切换后核验不纳入数据盘点。
- 字段映射以取值样例和业务含义确认，同名字段不按名称直接对应；用户身份按账号、姓名、邮箱、组织四个维度建立映射。
- 盘点期间源系统仍在写入，需设基准时间点、约定增量合并规则并提前通知冻结写入时点。
- 核验分数量核对、抽样核对和映射完整性检查三层，盘点结论经业务负责人确认后才进入迁移实施。
盘点范围怎么定：源系统、目标系统与数据对象
范围界定是盘点的第一步，也是后续所有统计和映射的基准。先把迁移方向写清楚：从哪个源系统迁到哪个目标系统，各自是什么版本。版本信息影响导出方式和字段结构，例如源系统版本较旧时，部分字段可能没有独立存储，需要通过接口或数据库查询补充。
纳入盘点的数据对象建议按实体逐类列出，常见的包括：
- 工作项：需求、任务、缺陷、子任务及其状态、优先级、经办人
- 测试用例与测试执行记录
- 文档与知识页面
- 附件、图片与评论
- 用户账号、用户组与组织架构
- 项目或空间的基本信息与成员关系
同时要明确本次不纳入盘点的内容。流程配置、插件行为、自动化规则属于配置迁移范畴，切换后的结果核验属于验收阶段，两者都不在数据盘点的统计口径内。把它们写进排除项，可以避免盘点表被无关条目撑大，也避免后续对“盘了什么”产生分歧。
边界按项目或空间划定。一个研发组织往往有多个项目空间，其中部分已归档或长期停用。建议以“本次确定迁移的项目清单”为边界，逐个项目登记空间标识、负责人和当前状态。范围界定表可以按下面的结构填写：
| 项目/空间 | 源系统及版本 | 目标系统及版本 | 纳入对象 | 排除项 | 边界说明 |
|---|---|---|---|---|---|
| 示例项目A | 源系统X，版本待登记 | 目标系统Y | 工作项、附件、评论、用户 | 流程配置、插件行为 | 仅统计2022年至今的数据 |
盘点前要准备哪些输入和依赖
盘点开始前，需要把权限、资料和人员三件事落实到位，否则导出会反复中断。权限方面，源系统至少需要只读或导出权限，能够访问全部纳入范围的项目空间；如果采用接口拉取，需要相应的接口调用权限；如果采用数据库只读查询，需要数据库账号和查询窗口的审批。目标系统方面，需要拿到字段结构资料，包括字段名称、类型、必填约束和枚举值定义，这是后续建映射表的依据。
人员分工建议按业务线和数据类别两条线安排。每条业务线指定一名对接人，负责确认本项目哪些数据需要迁移、哪些可以清理；数据负责人负责导出、统计和映射表的维护。涉及用户身份映射时，还需要人力资源或 IT 提供账号与组织信息。
导出方式有三种常见选择：系统自带导出、接口拉取、数据库只读查询。系统导出操作简单，适合工作项和文档；接口拉取适合需要定期重复统计的场景；数据库只读查询能拿到更细的字段和关联关系，但需要 DBA 配合。选择哪种方式，取决于源系统的开放能力和数据量。
盘点模板和命名规范要提前统一。建议文件名包含“系统_实体_导出日期_版本号”，例如“源系统X_工作项_20250110_v1”。同一实体多次导出时，用版本号区分，避免覆盖。时间窗口也要提前约定：盘点从哪天开始、预计持续多久、期间源系统是否允许继续写入。这些安排直接决定增量数据的处理方式。
按实体拉清单：数量、体积与归属统计
清单按实体类型分别导出，不要混在一张表里。每类实体记录四个基础字段：总数、时间跨度、所属项目、导出时间点。时间跨度用于判断数据的历史深度，所属项目用于后续按项目分批迁移，导出时间点是统计口径的锚点，所有汇总表都要注明。
附件需要单独统计。记录附件总数、总体积、按大小区间分布的情况，以及是否存在超大附件。评论条数和历史版本数同样要统计，它们直接影响迁移后的数据完整性和迁移耗时。对于文档类实体，还要记录页面层级深度和图片数量。
统计过程中同步标记三类对象：长期无更新的、无负责人的、已归档的。标记依据要写清楚，例如“超过18个月无状态变更”或“经办人账号已停用”。这些标记是下一步清理的输入，也是与业务方确认保留范围的依据。
统计汇总表建议包含以下列：实体类型、所属项目、数量、时间跨度、附件数量、附件体积、评论数、标记类型、导出时间。同一实体在不同项目下的数据分行记录，便于按项目核对。
脏数据怎么清理：重复、废弃与无效数据
清理的目标是控制迁移体量，同时保证业务上仍然有效的数据不丢失。识别重复工作项，可以看标题、描述和创建时间的相似度，以及是否指向同一需求；测试用例的重复判断可以结合用例步骤和关联需求；废弃项目的判断依据包括长期无活跃成员、无近期工作项更新、业务方明确表示不再使用。
清理决策不能由数据负责人单方面做出。每一条拟清理的记录，都要有对应的业务确认人。建议采用“提出—确认—执行—回写”的流程：数据负责人列出拟清理清单并说明依据，业务对接人逐条确认保留或清理，确认后执行标记或删除，最后把结果回写到盘点表。
清理前必须留痕。对拟删除的数据先做备份导出，或在系统中打上“待清理”标记并保留一段时间。标记方式比直接删除更稳妥，出现误判时可以恢复。清理前后的数量要形成对照，记录每个项目清理了多少条、占原数量的比例。
清理结果回写盘点表后，盘点表中的总数应更新为“清理后数量”，并保留“清理前数量”列，方便后续核验时解释差异。
实体、字段与用户身份怎么映射
映射表分三部分：实体映射、字段映射和用户身份映射。实体映射说明源系统的哪类对象对应目标系统的哪类对象，例如源系统的“问题”对应目标系统的“工作项”，源系统的“页面”对应目标系统的“文档”。一对多或多对一的情况要单独注明。
字段映射是最容易出问题的部分。每个源字段要记录：字段名称、数据类型、是否必填、目标字段名称、目标字段类型、枚举值对应关系、状态值对应关系。同名字段含义不同时，不能按名称直接对应。判断方法是对比两边的取值样例和业务含义，例如源系统的“优先级”取值为“紧急/高/中/低”，目标系统的“优先级”取值为“P0/P1/P2/P3”，需要确认两套取值的业务定义是否一致，再决定对应关系。确认过程要留下样例记录。
用户身份映射按账号、姓名、邮箱、所属组织四个维度建立。离职账号要单独列出，确认其历史工作项如何归属；重名账号要通过邮箱或工号区分，不能只靠姓名匹配。用户组和组织架构的对应关系也要登记，因为它影响迁移后的权限结构。
无法映射的字段进入挂起清单，记录字段名称、无法映射的原因、待确认人和预计确认时间。挂起清单是盘点结论的一部分，不能因为字段暂时无法对应就跳过不记。
历史附件与链接怎么保留
附件登记表按“所属对象、文件名、大小、存储位置”记录。存储位置要写清楚是源系统内嵌存储、对象存储还是外部链接引用，这决定迁移时是随数据一起搬运还是需要单独处理。附件体积直接影响迁移批次划分，超大附件建议单独列出，评估是否需要分批或压缩。
评论和历史记录的保留范围要提前确定。是保留全部评论，还是只保留最近若干条；历史版本是保留全部还是只保留关键节点。范围确定后写入盘点表，作为迁移范围的组成部分。
工作项之间的关联链接、文档之间的引用链接需要逐条登记。外部链接和已失效链接单独标注，迁移后这类链接通常无法自动修复，需要在盘点阶段就记录清楚，供后续人工处理。链接登记表可以和附件登记表合并，用“类型”列区分附件、内部链接和外部链接。
增量数据怎么处理：盘点期间的写入
盘点是持续一段时间的过程，源系统在此期间通常仍在产生新数据。因此要先确定一个基准时间点，基准时间点之前的数据按快照统计，之后的数据作为增量单独记录。基准时间点要写进盘点表，所有统计数字都注明“截至某时间”。
增量记录方式有两种：一是定期重新导出并对比差异，二是通过源系统的变更日志或更新时间字段筛选新增和修改记录。前者操作简单但工作量随盘点周期增加，后者更精确但依赖源系统提供变更查询能力。选择哪种方式，取决于盘点周期长短和源系统的能力。
增量数据的合并规则要提前约定：新增对象直接纳入，修改对象以最新版本为准，删除对象在盘点表中标记而不是直接移除。冻结写入的时间点要在盘点结束前确定，并提前通知所有相关团队，冻结期间源系统停止写入，以便做最终快照和核验。
核验与证据：盘点结果怎么证明可用
核验分三层。第一层是数量核对：每个实体的源清单总数与汇总表数字一致，清理前后的差额有对应记录。第二层是抽样核对：按项目或实体抽取一定比例的样本，逐条比对字段值、附件数量和评论条数，样本要覆盖不同项目、不同时间段的记录。第三层是映射表完整性检查：每个源字段都有对应的目标字段或挂起记录，每个用户账号都有映射结果或明确的处理说明。
证据留存包括导出文件、统计表、映射表、清理决策记录和业务确认记录。导出文件保留原始格式，不要只留截图；统计表和映射表保留版本号，便于追溯修改过程。所有证据按项目或按实体归档，命名与盘点模板的规范保持一致。
盘点清单、映射表和核验记录需要在团队之间交接和复核。这类结构化表格可以放在协作平台中承载，例如 ONES 的工作项和文档管理能力，把盘点任务拆成工作项分配给对接人，把范围表、映射表和核验记录沉淀为文档，评审和确认过程留痕。这样盘点结论在进入迁移实施阶段时，接手的人能直接看到依据和确认状态。
盘点的回退与停止条件
以下情况应暂停盘点，不要带着不确定的结论进入迁移：源数据无法完整导出，或权限不足以覆盖纳入范围的项目；关键字段的映射无法确认，且业务方无法给出取值口径；清理过程中出现误删，或清理口径与业务确认不一致。
回退方式要事先写明。误删的数据从备份恢复，并在盘点表中记录恢复范围和影响；口径不一致时，回退到上一版盘点表，重新确认后再更新。挂起的字段映射不阻塞整体盘点，但对应对象要标记为“待确认”，不能默认按名称对应后直接进入迁移。
盘点结论需要业务负责人确认后才能进入下一阶段。确认人按项目或按业务线指定，确认内容包括：纳入范围、清理结果、映射表、增量处理规则和核验记录。确认记录与盘点证据一起归档，作为迁移实施的输入。
常见问题
盘点期间业务团队还在源系统里正常提需求、改状态，盘点表怎么跟上？
先确定一个基准时间点，基准时间点之前的数据按快照统计，之后产生的数据作为增量单独记录，所有统计数字都注明“截至某时间”。增量记录可以定期重新导出并对比差异，也可以通过源系统的更新时间字段或变更日志筛选新增和修改记录，具体选哪种取决于盘点周期长短和源系统的查询能力。
合并规则提前约定：新增对象直接纳入，修改对象以最新版本为准，删除对象在盘点表中标记而不是直接移除。盘点结束前确定冻结写入时点并提前通知各团队，冻结期间停止写入，用于做最终快照和核验。
源系统和目标系统都有“优先级”字段，但取值不一样，能直接按名称对应吗？
不建议按名称直接对应。两个系统里同名字段的业务定义可能不同，例如一边是“紧急/高/中/低”，另一边是“P0/P1/P2/P3”，需要先对比两边的取值样例，确认每档取值对应的业务含义是否一致，再决定映射关系。
确认过程要留下样例记录，写进字段映射表。如果业务方对取值口径无法达成一致，该字段进入挂起清单，记录无法映射的原因、待确认人和预计确认时间，对应对象标记为“待确认”，不默认按名称对应后直接进入迁移。
离职员工的账号和重名账号在用户映射里怎么处理？
用户身份映射按账号、姓名、邮箱、所属组织四个维度建立。离职账号单独列出，确认其历史工作项如何归属，例如转给原团队的负责人或保留为历史经办人；重名账号通过邮箱或工号区分，不能只靠姓名匹配。
用户组和组织架构的对应关系也要登记，因为它影响迁移后的权限结构。每个账号都要有映射结果或明确的处理说明，这是映射表完整性检查的一部分。
盘点阶段清理掉的数据，迁移后发现还需要，能恢复吗？
能否恢复取决于清理时的留痕方式。对拟删除的数据先做备份导出，或在系统中打上“待清理”标记并保留一段时间，标记方式比直接删除更稳妥，出现误判时可以恢复。清理决策采用“提出—确认—执行—回写”的流程，每条拟清理记录都有对应的业务确认人，确认记录与盘点证据一起归档。
如果确实发生误删，从备份恢复并在盘点表中记录恢复范围和影响；清理口径与业务确认不一致时，回退到上一版盘点表，重新确认后再更新。
盘点结果要交给谁确认，确认哪些内容才算完成？
确认人按项目或按业务线指定，通常是该业务线的负责人。确认内容包括：纳入范围、清理结果、映射表、增量处理规则和核验记录。确认记录与导出文件、统计表、映射表、清理决策记录一起归档，作为迁移实施的输入。
以下情况应暂停盘点、不进入下一阶段：源数据无法完整导出或权限不足以覆盖纳入范围的项目；关键字段映射无法确认且业务方给不出取值口径；清理出现误删或口径与业务确认不一致。挂起的字段映射不阻塞整体盘点，但对应对象要标记为“待确认”。
