3. 迁移范围与优先级定义

历史数据迁移最忌讳“一刀切”。Windchill 中往往沉淀了十几年的产品数据，动辄数百万对象，如果全部迁移，不仅周期长、成本高，还会把大量垃圾数据、过期版本、无效关系一并带入新系统，反而降低新平台的数据质量。因此，迁移工作的第一步不是写脚本，而是定义范围与优先级：哪些数据必须迁、哪些可以缓迁、哪些应当冻结甚至销毁。

本节围绕四个评估维度——业务价值、合规风险、使用频率、依赖关系——建立一套可操作的划分方法，并据此确定迁移批次、冻结范围与治理优先级。

一、四个评估维度的含义与量化方式

四个维度不是抽象口号，每个维度都需要落到可判断的字段或指标上，才能形成可执行的分类规则。

• 业务价值：该数据是否仍支撑在产产品、在售配置、有效服务备件。可用“是否关联活跃产品线”“是否被当前 BOM 引用”“是否属于有效变更单范围”来判断。高价值数据必须迁移且优先治理。
• 合规风险：数据是否涉及法规留存要求、客户合同约定、质量追溯、出口管制或知识产权证据。例如医疗器械的 DHF 记录、航空件的适航证明、汽车行业的 PPAP 文件，通常有 10 年以上的法定留存期，属于不可删除、必须可检索的数据。
• 使用频率：过去 12～24 个月内被查询、下载、引用、变更的次数。Windchill 的审计日志、访问记录、检出记录可作为统计来源。低频不等于无价值，但高频数据应优先保证迁移后的可用性与性能。
• 依赖关系：对象之间的引用链，如 CAD 文档与部件、部件与 BOM、BOM 与变更单、文档与文件夹。依赖关系决定了迁移的“最小闭包”——迁一个部件，往往必须同时迁其主文档、关联图纸和有效版本，否则新系统中会出现断链。

二、迁移批次划分：从“必须迁”到“不迁”

综合四个维度后，通常可将数据划分为四个批次，形成清晰的迁移优先级：

批次划分的关键在于依赖闭包检查。例如某部件被判定为第四批“不迁”，但它被一个第一批的在产 BOM 引用，那么这个部件实际上必须随 BOM 一起迁移，否则新系统 BOM 结构不完整。因此，批次划分不能只看单个对象，必须沿引用链向上追溯。

三、冻结范围的定义

冻结范围是指“在迁移窗口期内不允许再发生变更”的数据集合。冻结的目的有两个：一是保证迁移数据的一致性，避免迁移过程中源数据被修改导致新旧不一致；二是给治理留出稳定窗口。

冻结通常分层次执行：

1. 全库冻结：迁移切换前的最终增量同步阶段，通常只持续数小时到一天，禁止所有写入。
2. 批次冻结：某一批数据开始迁移前，冻结该批次对象的检出与修订，允许其他批次继续工作。
3. 对象级冻结：对已判定为“不迁”或“待销毁”的对象，直接设置为冻结状态，禁止访问和引用。

四、治理优先级：先治理什么

迁移不是把脏数据搬过去就结束。治理优先级决定在迁移前、迁移中、迁移后分别处理哪些质量问题。建议按以下顺序排列：

• P0：阻断迁移的问题。如主数据缺失、必填属性为空、版本状态异常、依赖对象丢失。这类问题不解决，迁移脚本会直接失败或产生断链。
• P1：影响合规与追溯的问题。如审批记录缺失、变更历史不完整、文档与部件关联错误。这类问题影响审计与质量追溯，必须在迁移前修复或标记。
• P2：影响使用体验的问题。如命名不规范、重复对象、文件夹结构混乱、元数据不一致。可在迁移后逐步治理，但应制定规则避免新系统继续产生。
• P3：优化类问题。如历史版本过多、缩略图缺失、非关键属性不完整。可在资源允许时处理。

治理优先级与迁移批次需要交叉考虑：第一批核心数据应优先完成 P0、P1 治理；第三批归档数据可只做 P0 检查，允许保留部分历史瑕疵，但必须保证可读、可检索、可追溯。

五、四维评估与批次决策的关系图

下图将四个评估维度、依赖闭包检查、批次划分与治理优先级组织为一张决策关系图，帮助在实际项目中快速定位某一类数据应归入哪个批次、需要什么级别的治理。

六、落地建议与常见误区

在实际项目中，建议先用 Windchill 的查询与报表能力导出候选数据集，至少包含对象类型、创建时间、最后修改时间、状态、所属产品线、关联变更单数量、最近访问时间等字段。然后按四维评分规则批量打标，再由业务代表、质量代表、IT 迁移团队三方评审，确认批次归属。

常见误区有三个：一是只按时间划分，认为“三年以前的数据都不重要”，结果把仍在服役的长周期产品数据误判为可冻结；二是忽略依赖闭包，导致新系统中出现大量孤立对象或断链 BOM；三是冻结范围公告不足，迁移窗口期内业务仍在检出修改，造成增量同步反复失败。

把范围与优先级定义清楚，后续的抽取、清洗、转换、加载才有稳定的输入边界。批次划分不是一次性的，随着业务评审和依赖检查的深入，允许微调，但每一次调整都应有记录、有依据、有评审，避免范围蔓延导致迁移项目失控。