3. 升级迁移前期调研与现状评估

Windchill 升级迁移项目失败最常见的原因，不是目标版本装不上，而是前期对现状掌握不足：定制化点数量被低估、集成接口被遗漏、数据量估算偏差过大，导致停机窗口、硬件规格和回滚方案全部失准。本章的目标是建立一套可执行的现状盘点方法，并最终输出一份可量化的迁移风险评估报告，让"风险高"变成"某模块有 37 个定制点，其中 12 个依赖已废弃 API，预计改造工时 96 人天"这样的可决策结论。

一、盘点对象的五个维度

Windchill 环境的现状盘点应覆盖五个维度，缺一不可：系统与版本基线、定制化点、集成接口、数据量与结构、用户与权限规模。前两项决定改造工作量，第三项决定联调复杂度，第四项决定停机窗口与硬件规格，第五项决定上线切换与培训成本。

系统基线盘点需要记录：当前 Windchill 版本与补丁号（如 11.0 M030）、数据库类型与版本（Oracle 19c）、应用服务器（Tomcat 9）、是否使用集群、是否启用 Windchill Directory Server、已安装的模块（PDMLink、ProjectLink、MPMLink、PartsLink 等）。这些信息可通过 windchill version、xconf 目录下的 wt.properties、db.properties 以及 Windchill Shell 中的 windchill wt.load.LoadFromFile -h 辅助确认。

二、定制化点盘点：从文件到清单

定制化点是迁移风险的主要来源。建议按"代码类、配置类、界面类、流程类"四类分别盘点，并逐条记录改造难度。

• 代码类：自定义 JSP、Java 类、Listener、Delegate、自定义 Action。可通过扫描 codebase 目录下非标准包路径（非 com.ptc.*、wt.*）的 class 与 jar 识别。
• 配置类：wt.properties、service.properties、*.rbInfo、*.xml 中的自定义项，以及自定义的 LifeCycleTemplate、WorkflowTemplate。
• 界面类：自定义 JSP 覆盖、custom-actionmodels.xml、custom-actions.xml、*-ui.xml 中的界面调整。
• 流程类：自定义工作流、生命周期模板、团队模板、对象初始化规则（OIR）。

每条定制点应记录：名称、类型、所在文件/路径、依赖的标准 API、是否使用已废弃接口、改造难度（低/中/高）、预估工时。例如某企业盘点出 37 个定制点，其中 12 个使用了 Windchill 11.0 中已标记 deprecated 的 wt.fc.PersistenceHelper 旧方法，改造难度为高，单点预估 8 人天，合计 96 人天。

三、集成接口盘点

集成接口决定了迁移的联调复杂度。常见接口包括：与 ERP（SAP/Oracle）的物料与 BOM 同步、与 CAD 工具（Creo/SolidWorks）的检入检出、与 MES 的工艺数据交互、与单点登录（LDAP/AD）的认证集成。盘点时需记录：接口方向（单向/双向）、协议（Web Service/REST/文件/数据库直连）、调用频率、数据量、是否使用 Windchill API、对方系统版本。

四、数据量与用户规模评估

数据量评估不能只看数据库总大小，而要区分：主数据（Part、Document、BOM）、版本数据、元数据、文件卷（vault）数据、日志与历史数据。建议用以下 SQL 快速采样（示例，实际表名以现场为准）：

-- 统计主要业务对象数量（示例）
SELECT 'Part' AS obj, COUNT(*) FROM partmaster
UNION ALL SELECT 'Document', COUNT(*) FROM documentmaster
UNION ALL SELECT 'EPM Document', COUNT(*) FROM epmdocumentmaster;

-- 统计文件卷占用（示例）
SELECT COUNT(*) AS file_count, SUM(file_size)/1024/1024 AS size_mb
FROM applicationdata;

用户规模需区分：注册用户数、月活用户数、并发峰值用户数。并发峰值直接决定目标环境的硬件规格与许可数量。例如注册 2000 人、月活 800 人、并发峰值 180 人，则目标环境至少需按 200 并发设计。

五、迁移风险评估报告的结构

盘点完成后，输出一份可量化的风险评估报告，建议包含以下字段：风险项、风险类别、影响范围、发生概率、影响程度、风险值（概率×影响）、缓解措施、责任人、预估工时。风险值可采用 1–5 分制，风险值 ≥ 15 的列为高优先级。

报告不是一次性文档，而应在迁移各阶段持续更新。建议每周复核一次风险值，将已缓解项降级、新发现项补入。

六、实操建议与常见陷阱

盘点工作建议采用"三遍法"：第一遍由运维团队提供系统清单与配置文件；第二遍由开发团队逐条核对定制化点与接口；第三遍由业务团队确认用户规模与关键流程。三遍结果交叉比对，差异项即为高风险项。

最终输出的风险评估报告应能回答三个问题：哪些风险会导致迁移延期、哪些风险会导致数据丢失、哪些风险会导致业务中断。每个风险项都必须有明确的缓解措施、责任人和完成时间，否则报告只是一份清单，无法驱动决策。