迁移验证检查清单：数据完整性与附件校验项怎么列

迁移验证检查清单要把“数据完整”和“附件可用”拆成能逐项判定的条目。数据完整性按对象、字段、记录、关联四层列，附件按数量与容量、可访问性、内容一致性、权限继承四类列，每项写明通过标准、证据、负责人和检查时点，并标出阻断项。下文给出可直接填写的表格结构和判定口径。

要点总览（TL;DR）

• 数据完整性按对象、字段、记录、关联四层列检查项，每层单独判定，前一层不通过时后一层比对参考价值有限。
• 记录层要同时做总数对平和按状态、项目分组计数对平，只对总数容易掩盖分组错位。
• 附件校验按数量与容量、可访问性、内容一致性、权限继承四类列，抽样比例写入清单，避免执行口径不一。
• 每项检查写明可判断的通过标准、可归档的证据、到岗到人的负责人和对应切换节点的检查时点。
• 记录总数对不平、关键附件打不开、权限越权可见、关键流程走不通列为阻断项，清零后才进入切换窗口。

谁在什么时点用这份清单

这份清单解决的是“谁在哪个节点检查什么”，避免验证工作集中在迁移执行方一方，也避免业务验收方在切换当天才第一次接触目标系统。建议在项目启动时就把三类角色和三个时点写进迁移计划，清单随计划一起评审。

三类角色的分工如下：迁移执行方负责执行检查并提交原始证据，包括导出报表、比对记录和截图；业务验收方负责确认关键业务对象和流程在目标系统中可用，对业务口径的通过与否签字；系统管理员负责账号、权限、通知配置等系统层检查，并保障检查环境可用。

三个时点各有侧重：试迁移后做全量结构核对和抽样内容比对，目的是暴露映射和脚本问题；正式切换前复核试迁移问题的关闭情况，并确认增量数据已纳入；切换后观察期复查关键计数、附件可访问性和业务流转，确认没有在切换过程中产生新的偏差。

角色	试迁移后	正式切换前	切换后观察期
迁移执行方	执行对象、字段、记录、关联四层全量核对，提交比对记录	复核问题关闭情况，确认增量数据范围	复查关键计数与抽样附件
业务验收方	抽查关键项目的数据与附件是否符合业务预期	确认遗留问题处理计划可接受	走通关键业务流程并签字
系统管理员	核对账号、角色、项目成员与权限结构	确认切换窗口内的系统配置就绪	检查通知触达与权限实际生效情况

范围上，本清单以数据完整性和附件校验为主体，权限继承与业务验收作为配套项一并检查。数据映射规则的设计、字段对应关系的制定属于迁移方案阶段的工作，不在本清单展开。

数据完整性检查项怎么分层列

分层的目的，是让每一层都有独立的通过判断，出问题时能快速定位是对象漏迁、字段规则错、记录数不对还是关联断裂。四层从粗到细，前一层不通过时后一层的比对结果参考价值有限，建议按顺序执行。

对象层：迁移对象清单与源系统逐项对应

先列出源系统中需要迁移的对象类型，例如项目、工作项、状态、字段、流程、评论、附件、历史记录，再与迁移方案中的对象清单逐项对照，确认没有遗漏，也没有把不需要迁移的对象误列入。通过标准是两份清单一一对应，差异项均有书面说明和处置结论。证据为两份清单的对照表及差异说明。

字段层：取值规则逐字段核对

字段层检查的是“值迁过来后还是不是原来的意思”。重点核对四类字段：必填字段是否存在空值；枚举值是否映射到目标系统的对应选项，有无落到默认值或空值的情况；日期字段的时区与格式是否一致，起止时间有无偏移；人员字段是否指向正确的账号，离职或停用账号的记录如何处理需事先约定。通过标准为逐字段核对无未说明的异常值，异常项有清单和处理结论。

记录层：总数与分组计数同时对平

只对总数容易掩盖分组错位，例如两个状态之间互相串了记录而总数不变。建议同时做两组比对：源系统与目标系统的记录总数；按状态、按项目分组的计数。通过标准是总数相等且各分组计数逐项相等，差异为零或有经确认的合理差异说明。证据为两侧的导出报表或统计截图，注明导出时间和筛选条件。

关联层：关系随记录一起迁移

关联层抽查父子任务层级、需求与缺陷的关联关系、评论归属、工作项与迭代或版本的归属是否在目标系统中保持。抽查应覆盖有代表性的项目，包括层级较深的任务树和关联较多的需求。通过标准为抽查样本的关联关系与源系统一致，断链或错挂数量为零。

层次	检查项	通过标准	证据	负责人
对象层	迁移对象清单与源系统对象清单对照	一一对应，差异项有书面说明	对照表、差异说明	迁移执行方
字段层	必填、枚举、日期、人员字段取值核对	无未说明的异常值	字段核对记录、异常清单	迁移执行方
记录层	总数及按状态、项目分组计数对平	总数相等，分组计数逐项相等	两侧导出报表、统计截图	迁移执行方
关联层	父子任务、需求缺陷关联、评论归属抽查	抽查样本关系一致，断链为零	抽查记录、截图	迁移执行方与业务验收方

在工具层面，记录层对平依赖目标系统能按状态、项目等条件导出或统计工作项数量。ONES 的 Jira 迁移覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移后可在目标系统中按条件筛选和统计工作项，用于与源系统报表比对；具体统计口径和导出方式需在迁移项目中与实施方确认。

附件校验项怎么列才不漏

附件的问题往往在切换后才被发现：数量少了、点开是空白、文件名对了内容不对、或者本不该看到的人能看到。四类检查点分别对应这四种失效方式，建议逐类设置检查项并写明抽样比例。

数量与容量对平

统计源系统与目标系统的附件总数和总容量，按项目或按对象分组比对。通过标准为总数相等、总容量在合理误差范围内，差异项能定位到具体对象。证据为两侧的附件统计报表，注明统计时间。

可访问性抽查

从不同项目、不同文件类型中抽样，逐条执行打开、下载、预览操作。通过标准为抽样附件全部可正常打开和下载，预览失败率在约定阈值内且有替代查看方式。抽样比例建议按附件总量分档设定，例如小规模全量、大规模按项目和类型分层抽样，具体比例在清单中写死，避免执行时口径不一。

内容一致性比对

比对文件名、文件大小，条件允许时比对哈希值；对关键附件（如合同、验收单、设计稿）做抽样内容比对，打开确认内容与源系统一致。通过标准为文件名与大小全部一致，哈希或抽样内容比对无差异。

权限继承检查

确认附件的可见范围与所属工作项或页面的权限一致，重点检查受限项目中附件是否被越权可见，以及公开对象的附件是否被错误收紧。通过标准为抽查样本的附件权限与所属对象权限一致，越权可见为零。

检查类别	检查项	抽样比例	通过标准	证据
数量与容量	附件总数、总容量与源系统对平	全量统计	总数相等，容量差异可解释	两侧统计报表
可访问性	抽样打开、下载、预览	按项目与文件类型分层抽样，比例写入清单	抽样全部可打开下载，预览失败在阈值内	操作截图、抽查记录
内容一致性	文件名、大小、哈希或内容比对	全量比对名称与大小，关键附件抽样比对内容	无差异	比对记录、哈希清单
权限继承	附件可见范围与所属对象权限一致	覆盖受限与公开两类对象	越权可见为零	权限截图、抽查记录

附件权限继承的检查依赖目标系统对附件与所属对象的权限绑定方式。ONES 的 Confluence 迁移可将空间、页面、附件和权限结构迁移到 ONES Wiki，附件随页面组织，权限结构一并迁移；Jira 迁移场景中附件随工作项迁移。迁移工具是否提供附件计数或哈希比对报告，需在具体项目中向实施方确认，清单中可先以人工统计和抽样比对作为证据来源。

权限与业务验收配套检查项

数据和附件都迁过来了，仍然可能出现“能看不能用”：成员进不了项目、字段看不到、流程走不通、通知收不到。配套检查项的作用是在切换前把这些可用性问题清掉。

权限继承检查

核对角色定义、项目成员名单、字段可见范围是否随迁移保留。检查方法是选取若干典型角色（项目管理员、开发、测试、只读成员）分别登录，确认其能看到和操作的对象范围与源系统一致。通过标准为抽查角色的权限表现与迁移前一致，差异项有处理结论。证据为各角色视角的截图和权限对照表。

业务验收检查

在目标系统中走通关键流程，例如新建工作项、流转状态、关联需求与缺陷、上传附件、关闭工作项，确认每一步都能完成且留下正确记录。通过标准为关键流程全部走通，产生的记录字段值、状态和关联关系正确。证据为流程走查记录和业务验收方签字。

通知与提醒检查

确认迁移后关键事件按预期触达，包括状态变更通知、指派通知、评论提醒等。检查方法是触发若干典型事件，确认接收人、渠道和内容符合配置。通过标准为抽查事件全部按预期触达，未触达项有原因说明。

检查项	检查方法	通过标准	证据	负责人
角色与成员权限	典型角色分别登录核对可见与可操作范围	与迁移前一致，差异有结论	角色视角截图、权限对照表	系统管理员
字段可见范围	按角色核对敏感字段与普通字段的可见性	可见范围符合设计	字段权限截图	系统管理员
关键流程走通	新建、流转、关联、上传、关闭全流程走查	流程全部走通，记录正确	走查记录、签字确认	业务验收方
通知与提醒	触发典型事件确认触达	抽查事件全部按预期触达	通知截图、触达记录	系统管理员

通过标准、证据与负责人怎么填

清单能不能用，取决于每一行是否可以被第三方独立判断。填写时把握三条：通过标准写成可判断的阈值或状态，证据写成可归档的具体材料，负责人写到岗到人并对应检查时点。

通过标准写成可判断的表述

把“基本正常”“大致一致”这类表述替换为可核验的条件，例如“记录总数相等且各分组计数差异为零”“抽样附件全部可打开和下载”“越权可见数量为零”。涉及抽样时，把抽样比例和抽样方法一并写入，使不同执行人得到可比的结果。允许存在合理差异的检查项，要写明差异的判定条件和上限。

证据形式与留存

常用证据包括：两侧系统的导出报表或统计截图（注明导出时间和筛选条件）、附件抽查操作截图、哈希比对清单、权限对照表、流程走查记录、业务验收方签字确认。证据按检查项编号归档，便于切换评审时逐项调取。截图类证据应包含时间信息和操作账号，避免无法追溯。

负责人与时点对齐切换计划

每项检查指定一名负责人，避免“共同负责”导致无人执行。检查时点与切换计划中的试迁移、切换窗口、观察期节点对齐，并在清单中写明每项检查的截止时间。跨角色的检查项，例如关联层抽查和业务验收，由执行方提供证据、验收方确认结论，两个名字都写在清单上。

填写字段	填写要求	反例	正例
通过标准	可判断的阈值或状态	数据迁移基本正常	记录总数相等，按状态分组计数差异为零
证据	可归档的具体材料，含时间和条件	已检查	两侧导出报表各一份，注明导出时间与筛选条件
负责人	到岗到人，跨角色写全	迁移小组	执行方张某提供证据，验收方李某签字确认
检查时点	对应试迁移、切换前或观察期，写明截止时间	迁移期间	试迁移完成后两个工作日内

阻断项与完成条件

阻断项是必须清零才能执行切换的检查项，与非阻断项分开标记，可以避免评审时把“有处理计划”误当成“已通过”。建议在清单中用单独一列标记阻断属性，并在汇总页统计阻断项关闭数量。

必须清零的阻断项

• 记录总数对不平：源系统与目标系统记录总数存在未解释的差异，或分组计数出现无法定位的错位。
• 关键附件无法打开：合同、验收单、设计稿等关键业务附件在目标系统中无法打开或下载。
• 权限越权可见：受限项目或受限对象的附件、字段被无权限人员看到。
• 关键流程走不通：核心业务流程在目标系统中无法完成，或完成后记录错误。

前三项直接对应数据与附件的失效方式，第四项对应业务可用性。是否把其他检查项也列为阻断，由项目在切换评审时根据业务影响确定，但一旦列为阻断，就必须满足清零条件。

整体完成条件与观察期复查

切换放行的完成条件是：阻断项全部关闭并有证据支撑；非阻断项有明确的处理计划、责任人和完成时间；业务验收方对关键流程走查结果签字确认。观察期内的复查安排建议在切换计划中写明复查频次和复查项，至少覆盖记录计数、关键附件可访问性和权限实际生效情况，发现偏差时按预案回退或修复。观察期时长和复查频次由项目根据业务规模自行确定，并在清单中固化，避免复查流于形式。

判定项	是否阻断	关闭条件	确认人
记录总数或分组计数对不平	是	差异定位并修复，重新对平为零	迁移执行方与业务验收方
关键附件无法打开或下载	是	关键附件全部可正常访问	迁移执行方
权限越权可见	是	越权可见清零，权限配置复核通过	系统管理员
关键流程走不通	是	流程走通并留下正确记录	业务验收方
非关键附件预览失败	否	有替代查看方式或修复计划	迁移执行方
个别通知未触达	否	原因说明与修复计划	系统管理员

把这张判定表与前面的分层检查表配套使用：分层表负责发现问题和留存证据，判定表负责放行决策。两张表共用同一套检查项编号，切换评审时按编号逐项过，阻断项未清零即不进入切换窗口。

常见问题

试迁移后数据总量对平了，正式切换前还要再查一遍吗？

需要。试迁移后对平的是当时的数据快照，正式切换前源系统可能仍在产生新记录、修改状态或上传附件。切换前应复核试迁移问题的关闭情况，并确认增量数据已纳入迁移范围，再对关键计数做一次比对。如果增量数据量大或变更频繁，建议在切换窗口内安排一次最终对平，把比对时间点写进清单，避免用试迁移的旧报表作为放行依据。

附件数量对不上，但业务方说没丢东西，能放行吗？

不能直接放行。数量差异需要先定位到具体对象和文件，确认是重复计数、统计口径不同，还是确实有附件未迁移。如果差异来自统计口径，例如源系统把历史版本计入附件数而目标系统只计当前版本，应在清单中写明口径差异和换算方式，并由业务验收方确认关键附件均在。无法定位的差异应作为阻断项处理，清零后再切换。

附件权限继承检查要覆盖全部附件吗？

通常不需要全量覆盖，但抽样要覆盖受限项目和公开项目两类对象，并包含不同文件类型和不同所属工作项。重点检查受限项目中附件是否被无权限人员看到，以及公开对象的附件是否被错误收紧。抽样比例和抽样方法写入清单，执行时按清单取数。如果迁移工具或目标系统能导出附件与所属对象的权限对照，可作为全量核对的辅助证据。

阻断项清零后，观察期还要复查哪些内容？

观察期复查至少覆盖三类：记录计数是否与切换时一致、关键附件是否仍可正常打开和下载、权限配置在实际使用中是否按预期生效。复查频次和时长由项目根据业务规模确定，并在切换计划中固化。发现偏差时按预案回退或修复，复查结果作为迁移收尾的归档材料。

清单里的负责人可以写团队名称吗？

不建议只写团队名称。每项检查应指定一名具体负责人，跨角色检查项把执行方和验收方的名字都写上，例如执行方提供证据、验收方签字确认。团队名称无法追溯到人，容易出现无人执行或互相等待的情况。如果人员发生变动，在清单中更新负责人并注明变更时间。