名录更新后，常见的现象是：原以为已经完成的适配，在验收或联调阶段又冒出新的问题；部分老系统在新环境里跑得起来，但性能、打印、导出和接口调用总有不顺。这不是某一个组件的问题，而是底数没摸清。
与其急着列替换名单，不如先把「哪些真的依赖、哪些只是巧合」查明白。下面的排查顺序按投入产出比排，先做前两项，通常就能把改造范围收敛到可控区间。
先查清底数：现有系统到底依赖了什么
兼容性自查最常见的误区，是只盘点了服务器和数据库，漏掉运行时、浏览器控件、打印组件、加密设备以及第三方接口的证书与协议要求。这些部分往往才是联调卡壳的地方。
建议从资产台账入手，把每套系统拆成四层记录：硬件与操作系统、中间件与数据库、运行时与依赖库、外设与外部接口。四层里任何一层没写清楚，后面的迁移路线就无从判断。
- 业务系统清单：自研、外包、采购成品分别标注，责任方写清楚；
- 依赖清单：记录实际使用的组件与版本，注明是否有厂家支持；
- 接口清单：与 ERP、HR、财务、门户之间的对接关系画出来；
- 使用人群：按部门与岗位标注，便于判断停机窗口的容忍度。
底数阶段不要急着定方案。做过类似项目的团队通常会发现，盘点花的时间远少于反复返工的时间。需要外部力量参与梳理时，可以参考我们的软件定制开发与系统集成服务，先把资产与依赖关系画清楚。
逐项排查顺序：从只读报表到核心交易
自查不建议按部门铺开，而应按「业务影响」从低到高推进。先动只读类、报表类，再动有写入的流程类，最后才是核心交易与对外服务。这样每一步都能验证方法论，把风险控制在局部。
- 先核对软硬件环境清单与名录中的适用范围，确认哪些是「必须替换」、哪些是「可以保留」；
- 对每套系统做一次只读验证：能否正常启动、查询、导出、打印；
- 再做写入验证：表单提交、流程流转、附件上传与下载；
- 然后测接口：与上下游系统的取数、回传、鉴权与超时处理；
- 最后做压力与并发验证：报表导出、批量处理、定时任务。
协同办公与流程类系统在第四步最容易出问题。国产 OA 的二次开发一般绕不开组织与权限体系、流程表单定制以及与 ERP、HR、财务的对接，这些环节的兼容性问题往往在功能测试阶段看不出来，只有走完整流程才暴露。我们在政企客户的 OA 实施中通常把组织与权限梳理放在开发之前，避免后期返工。
如果系统本身就是围绕定制流程和报表搭起来的，改动范围可能比预想的大，这类情况可以参考政府与国企国产化改造案例了解实际会涉及哪些改造环节。
区分三种处置方式：保留、改造、重建
排查完成后，每套系统通常落在三类处置里。判断标准不是技术新旧，而是「依赖是否可控」和「后续是否还要持续演进」。
- 保留：依赖组件有明确支持渠道，主要业务逻辑不涉及底层差异，做隔离和配置调整即可；
- 改造：核心业务可用，但某个依赖层需要替换，工作量集中在适配与联调；
- 重建：技术栈已经难以维护，或与其他系统的耦合点太多，改动成本接近重写。
处置结论要落到迁移路线里，包含阶段划分、停机窗口、回退方案和验收方式。回退方案经常被省略，但恰恰是它决定了业务部门敢不敢配合切换。
重整范围较大时，建议分期推进，每一期都以「业务可独立运行」为边界。我们在系统重构与旧系统升级中通常按这个原则切分阶段，交付包括需求调研、开发联调、上线验收与运维交接，具体安排见服务范围与交付流程。
预防措施：把自查变成常态化的工作
名录会继续更新，一次性适配很难一劳永逸。可行的做法是把上述清单固化成台账，在采购、立项、验收三个节点各过一遍。
- 采购环节：在合同与技术附件中写明运行环境要求与适配责任；
- 立项环节：新系统上线前明确要纳入资产台账的字段，避免事后补录；
- 验收环节：把兼容性测试结果作为交付材料的一部分，而不只看功能清单。
另外，接口是长期风险点。对外接口的鉴权方式、证书与传输协议一旦变化，所有上游系统都会受影响。建议集中维护一份接口台账，记录调用方与责任联系人。预留版本号与变更记录看似琐碎，出问题时能省下大量排查时间。
可直接照着做的自查问题清单
以下问题建议逐条回答。答不上来的那一条，就是下一步要补的功课。
- 每套系统的运维责任人和供应商联系人是否明确？
- 是否记录了运行时、依赖库与外设驱动？
- 是否存在无厂家支持的组件？影响哪些功能？
- 与财务、人事、门户之间的接口是否有文档与测试记录？
- 只读验证、写入验证、接口验证、并发验证是否都做过？
- 切换窗口与回退方案是否经过业务部门确认？
- 验收材料中是否包含兼容性测试结论？
- 新增系统的运行环境要求是否写进了采购或立项文件？
这份清单不需要一次性全部完成，但建议按季度复核一次。
