研发迁移数据盘点的产出是一份可核对的清单，而非笼统的“数据量估算”：先锁定来源系统与目标系统的版本和边界，再按业务对象逐类登记数量、字段、附件、关联关系和历史版本，标注保留、转换、归档或丢弃的处理方式，最后用抽样比对和数量对账形成盘点证据。本文聚焦数据内容与映射准备，流程状态机、插件与自动化行为归工作流与扩展能力迁移，切换后的结果核验归迁移验证与切换管理。
要点总览（TL;DR）
- 盘点范围先写清来源系统与目标系统的名称、版本、部署形态，再按工作项、需求、缺陷、测试用例、文档、附件、评论、用户与组织、字段配置逐类列出纳入与排除项，流程状态机与插件行为归工作流与扩展能力迁移。
- 盘点前备齐四类输入：只读或导出权限、字段字典与自定义字段说明、各类别数据责任人、目标侧可接收字段的初步确认，并约定数据冻结窗口，让盘点数字对应明确时间点。
- 盘点底表按对象类别分行，登记记录总数与状态/项目/时间分布、字段名与类型、必填与取值范围、空值比例、附件体积、关联关系、历史与评论处理方式，处理建议固定为保留、转换、归档、丢弃。
- 核验走总量对账与抽样比对两条线，差异按缺失、重复、截断、编码异常逐条登记，导出文件、统计截图与核对记录统一归档，盘点结论签署并做版本管理。
- 盘点底表以对象类别和字段为键直接转为映射表来源行，处理建议决定映射动作；权限不足、字段字典缺失或数量差异无法解释时应暂停盘点，核心类别完成核验后再进入映射与试迁移。
盘点范围怎么定：来源、目标与数据对象清单
范围界定的第一步是把“来源系统”和“目标系统”写成可核对的条目：系统名称、版本号、部署形态（SaaS 或私有化）、租户或实例地址。版本信息尤其关键，同一产品不同大版本的数据结构、字段类型和导出方式可能不同，盘点表里应记录来源版本和目标版本，作为后续映射规则的适用前提。具体产品的兼容版本范围需在实施前向原厂或实施方确认，盘点阶段先如实登记，不预设结论。
第二步是按业务对象类别列清单。研发数据通常可归为以下几类，每类单独成行，避免混在一起统计：
- 工作项（任务、子任务、史诗等）及其状态历史
- 需求与产品 backlog 条目
- 缺陷与问题单
- 测试用例、测试计划与执行记录
- 文档与知识页面
- 附件、图片与富文本内容
- 评论与操作记录
- 用户、用户组与组织架构
- 字段配置：自定义字段、选项集、必填规则
与纳入项同等重要的是排除项。流程状态机、插件与自动化行为、权限模型细节通常不属于数据盘点的登记对象，它们由工作流与扩展能力迁移单独处理。把排除项写进范围说明，可以避免盘点底表被流程配置撑大，也避免后续把“流程没迁”误判为“数据丢了”。
盘点边界还要与迁移批次对齐。如果迁移分多批进行，范围说明应标注每类对象属于哪一批、批次之间的依赖关系（例如用户与组织先于工作项迁移）。下表可作为范围说明的填写结构：
| 来源系统/版本/部署形态 | 目标系统/版本/部署形态 | 对象类别 | 纳入/排除 | 理由 | 所属批次 |
|---|---|---|---|---|---|
| 示例：来源 A，v8.x，私有化 | 示例：目标 B，当前版本，私有化 | 工作项及状态历史 | 纳入 | 核心研发过程数据 | 批次 2 |
| 示例：来源 A，v8.x，私有化 | 示例：目标 B，当前版本，私有化 | 自动化规则与插件配置 | 排除 | 归扩展能力迁移 | — |
盘点前需要哪些输入与依赖
盘点能否按计划推进，取决于四类前置条件是否到位：访问权限、字段资料、责任人和时间基线。缺任何一项，盘点都容易在中途停摆或产出不可信的数字。
账号与导出权限。盘点通常只需要只读权限，但部分系统把“导出”作为独立权限控制。申请时应写明用途（数据盘点与迁移评估）、所需范围（全部项目或指定项目）、使用期限，并走所在组织的权限审批流程。若来源系统不提供批量导出，需要提前确认可用的报表或 API 查询方式，避免盘点开始后才发现只能逐页翻看。
字段字典与自定义字段说明。字段字典是盘点底表中“字段登记”一列的来源。获取方式一般有三种：系统管理后台的字段配置页、管理员导出的配置清单、业务侧整理的历史说明文档。自定义字段尤其需要业务说明，因为字段名往往无法反映真实含义和取值范围。
业务侧确认人。每类对象应有明确的数据责任人，负责确认数量口径、字段含义和处理建议。建议按对象类别而非按项目分配责任人，例如需求类由产品负责人确认，缺陷类由测试负责人确认，文档类由知识库管理员确认。
目标系统侧的可接收字段与取值范围。盘点阶段不需要完成映射，但需要初步确认目标系统是否存在对应字段类型、选项集长度是否够用、必填约束是否会阻断导入。这一步能提前暴露“来源有、目标无”的字段，减少后续映射返工。
盘点时间点与数据冻结窗口。盘点数字必须对应一个明确的时间点，否则总量对账永远对不上。建议在盘点开始前与业务方约定冻结窗口：窗口内暂停大规模批量操作和字段变更，盘点以冻结时刻的导出数据为准。窗口长度按数据量和业务节奏确定，并在范围说明中记录。
把上述内容整理成输入清单与责任人对照表，逐项标注“已获取/待获取/负责人/截止时间”，盘点启动前完成一次检查。
逐类对象盘点与字段登记方法
逐类盘点的目标是形成一张可映射的底表。每类对象按同一套口径采集，才能横向比较和汇总。
数量统计。记录每类对象的记录总数，并同时给出按状态、按项目、按创建时间的分布。只记总数不够：一个总数相同的两类数据，分布可能完全不同，直接影响迁移批次划分和试迁移样本选择。统计口径要写清楚，例如“是否包含已删除但可恢复的记录”“是否包含归档项目”。
字段登记。每个字段登记五项信息：字段名、数据类型、是否必填、取值范围（选项集或数值区间）、空值比例。空值比例是判断字段是否值得迁移的重要依据，也能提示历史数据质量问题。对于多选、级联、富文本等复杂类型，额外注明存储形式。
附件与富文本。统计附件数量、总体积、单文件最大体积和文件类型分布；富文本内容需注明是否内嵌图片、是否引用外部链接。体积数据决定迁移窗口和传输方式的选择。
关联关系。记录对象之间的父子关系、关联链接、引用关系，例如需求与工作项的关联、缺陷与测试用例的关联、文档之间的页面引用。关联关系是迁移中最容易丢失的部分，应在底表中单独成列，注明关联类型和关联数量。
历史版本与评论。判定规则建议按业务价值划分：状态变更历史、评论通常纳入；文档的历史版本按保留策略决定，若目标侧只保留当前版本，需在底表中标注“归档”而非“丢弃”，以便追溯。
盘点底表可按以下列结构设计，每类对象占若干行（对象类别 + 字段维度）：
| 对象类别 | 记录总数 | 状态/项目/时间分布 | 字段名 | 类型 | 必填 | 取值范围 | 空值比例 | 附件/富文本体积 | 关联关系 | 历史与评论处理 | 处理建议 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 缺陷 | 12,400 | 按状态：关闭 78%、处理中 15%、待处理 7% | 严重程度 | 单选 | 是 | 5 个选项 | 0.3% | — | 关联测试用例 3,100 条 | 状态历史纳入，评论纳入 | 保留并映射 |
| 文档 | 860 | 按空间：6 个空间 | 正文 | 富文本 | 是 | — | 0% | 附件 4.2 GB，内嵌图片 1,900 张 | 页面引用 2,300 处 | 历史版本归档，保留最近 3 版 | 正文与附件转换，旧版本归档 |
处理建议一列使用固定取值：保留、转换、归档、丢弃。固定取值让底表可以直接汇总成迁移工作量，也便于评审时逐条讨论。
盘点结果如何核验并留证
盘点底表的可信度靠两条核验线支撑：总量对账和抽样比对。两者都完成，盘点结论才具备提交评审的条件。
总量对账。将来源系统的统计数字与导出文件中的记录数逐类比对。差异为零或差异可解释（例如统计含已删除记录、导出按权限过滤）才算通过。对账结果记录在核验表中，注明统计时间点、统计方式和导出文件名。
抽样比对。按对象类别抽取样本，逐字段核对导出内容与来源系统页面显示是否一致。样本量按类别数据量确定，覆盖不同状态、不同项目和不同字段组合。抽样重点放在自定义字段、富文本、附件和关联关系上，这些位置最容易出现截断或丢失。
差异登记。发现的问题逐条登记，类型至少包括：缺失（应有记录未导出）、重复（同一记录出现多次）、截断（字段内容或附件不完整）、编码异常（乱码、特殊字符丢失）。每条差异记录对象类别、记录标识、差异类型、影响范围和初步原因。
证据留存。导出文件、统计截图、核对记录统一归档到指定位置，命名包含日期和版本号。归档要求写入盘点计划，避免核验完成后证据散落在个人电脑里。
结论签署与版本管理。盘点结论由各类别数据责任人确认签署，底表和核验记录标注版本号。后续任何修订都生成新版本，保留修订说明，确保映射阶段使用的是最新且可追溯的结论。
盘点的停止条件与回退准备
盘点不是必须一次做完的线性过程，遇到以下情形应暂停并退回补充，而非带着不确定的数字继续推进：
- 只读或导出权限未获批，或权限范围不足以覆盖盘点对象
- 关键字段字典缺失，自定义字段含义无法确认
- 总量对账出现无法解释的差异，且抽样比对无法定位原因
- 业务侧责任人未确认数量口径或处理建议
数据冻结窗口内如果仍发生大量变更（例如批量导入、字段配置调整），原盘点基线失效，应重新确认冻结时刻并重做受影响的统计，而不是在旧数字上打补丁。
盘点结论修订时，保留旧版本并记录修订原因、修订范围和影响的对象类别。若盘点尚未完成就启动字段映射或试迁移，映射规则会建立在未经验证的数字上，试迁移样本也可能选偏，因此建议在核心对象类别完成核验并签署后再进入映射阶段；非核心类别可与映射并行推进，但需在交接说明中标注其未完成状态。
盘点结果如何衔接迁移映射与协作管理
盘点底表到字段映射表的转换以“对象类别 + 字段”为键。底表中的字段登记行直接成为映射表的来源字段行，处理建议决定映射动作：标注“保留”的字段进入直接映射，“转换”的字段需要写明转换规则和取值对照，“归档”的内容进入归档存储方案，“丢弃”的字段记录理由并通知业务方。关联关系列转化为映射表中的关联映射项，历史与评论处理列转化为迁移范围说明。这样转换后，映射表不需要重新采集信息，只需补充目标字段和转换规则。
盘点任务本身也需要被跟踪。建议按对象类别拆分任务，每类任务包含数据采集、核验、责任人确认三个状态节点，任务负责人即该类别数据责任人。差异记录作为独立条目跟踪，闭环后再关闭对应任务。盘点结论的评审以底表版本和核验记录为输入，评审意见记录在案，形成从盘点、评审到映射交接的完整链路。
在 ONES 中，这类盘点工作可以用工作项承载按对象类别拆分的任务与差异条目，用文档承载盘点范围说明、底表和核验记录，评审结论随文档版本留存。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 迁移方案覆盖空间、页面、附件和权限结构，迁移用户、用户组和系统配置；这些范围可作为目标侧接收能力的参照，具体字段类型与宏的对应规则仍需在映射阶段逐项评估确认。
常见问题
盘点时发现来源系统只能逐页查看、无法批量导出，怎么办？
先确认系统是否提供报表导出或 API 查询能力，很多系统把批量导出放在管理员权限或独立菜单下，普通只读账号看不到入口。若确实只能逐页查看，应调整盘点方式：按项目或时间分批采集，每批记录采集时间点和页码范围，并在核验阶段用抽样比对补足可信度。这种情况下盘点周期会明显拉长，建议在范围说明中把受影响的类别标注为“分批采集”，并相应推迟这些类别的映射启动时间。
自定义字段很多，盘点时每个字段都要登记吗？
建议全部登记，但登记深度可以分层。使用频率高、承载业务判断的字段（如严重程度、优先级、模块）按完整五项登记：字段名、类型、必填、取值范围、空值比例。长期无人填写、空值比例接近 100% 的字段可以只登记名称、类型和空值比例，并在处理建议中标注“丢弃”或“归档”，同时通知业务方确认。这样既不会漏掉潜在映射需求，也不会让底表被低价值字段撑得难以评审。
数据冻结窗口内业务还在正常提交工作项，盘点数字还能用吗？
冻结窗口的作用是让盘点数字对应一个明确时刻，业务完全停摆通常不现实。可行的做法是：以冻结时刻的导出数据为盘点基线，窗口内新增的记录单独统计并标注“冻结后增量”，在映射与试迁移阶段作为增量数据处理。如果窗口内发生批量导入、字段配置调整这类会改变数据结构或统计口径的操作，原基线失效，应重新确认冻结时刻并重做受影响类别的统计，不在旧数字上打补丁。
盘点结论已经签署，映射阶段发现字段含义理解错了，怎么处理？
按版本管理流程修订盘点底表：生成新版本，记录修订原因、修订范围和影响的对象类别，由对应类别的数据责任人重新确认。映射表中依赖该字段的行同步更新，并在交接说明中注明变更。若该字段已进入试迁移样本，需要评估样本是否仍然有效，必要时重新抽取。修订记录保留在案，保证从盘点、映射到试迁移的链路可追溯。
盘点阶段需要确认目标系统的哪些接收能力？
盘点不要求完成映射，但需要初步确认三件事：目标系统是否存在对应字段类型（如多选、级联、富文本），选项集长度是否够用，必填约束是否会阻断导入。以 ONES 为例，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 迁移方案覆盖空间、页面、附件和权限结构，迁移用户、用户组和系统配置；这些范围可作为目标侧接收能力的参照，具体字段类型与宏的对应规则仍需在映射阶段逐项评估确认。
