信创适配改造中，数据库迁移是最容易在后期翻车的一步。所谓兼容性测试清单，本质是把「业务系统实际用到了数据库的哪些能力」逐项列出来，再逐一验证它们在目标库上是否可用、行为是否一致。清单不是从模板里抄来的，而是从你现有系统的代码、SQL、存储过程和运维脚本里长出来的。
先说结论：只换数据库、不改应用的做法风险最高；先梳理应用对数据库的依赖面，再决定清单范围和验证深度，比较稳妥。下面按三种常见做法展开，每种都写清代价与适用边界。我们的政府与国企国产化改造案例可以作为场景参照。
方案一：自建清单，按应用依赖面逐项梳理
适合有熟悉本系统代码的开发和 DBA、且系统规模可控的团队。做法的核心是把清单来源拆成几类，逐类生成检查项，而不是套一份通用模板。
- 优点：与业务贴合度高，能覆盖系统特有的写法；沉淀下来的清单可以复用到同系列的其他系统。
- 优点：不依赖外部工具授权，过程可控，整改责任能落到具体人。
- 缺点：对团队经验依赖大，遗漏往往出在「以为自己没用」的地方；梳理本身费时。
- 缺点：容易只测功能不测行为差异，例如排序规则、空值处理、隐式类型转换的细微不同。
清单建议分四层：语法层看 SQL 写法与函数是否存在等价实现；语义层看排序、大小写、空值、精度与日期格式；对象层看存储过程、触发器、视图、序列与自增；接口层看连接驱动、事务隔离、批量提交与分页写法。每层下面再挂具体检查项，检查项要能对应到代码或配置文件中的证据。
这一层如果觉得梳理人手不够，可以先借助我们整理的方法做一些基础铺垫，具体实施方式可参考软件定制开发与系统集成服务中的迁移与集成部分。
方案二：借助专项测试与对比工具，跑数据与 SQL 回归
适合存量数据量大、SQL 数量多、人工逐条核对不现实的系统。常见做法是把应用在旧库上的执行结果与在新库上的执行结果做比对，重点看返回值、影响行数与执行计划是否出现明显异常。
- 优点：覆盖面比人工广，能发现人工容易忽略的类型与精度问题；回归可重复执行。
- 优点：适合在迁移窗口期前反复跑，形成基线。
- 缺点：工具只解决「可比对得到」的部分，业务语义是否正确仍要人来判断。
- 缺点：需要准备脱敏样本数据与场景化用例，准备工作本身占大头。
要注意的是，比对结果一致不等于业务正确。例如金额舍入、报表口径、时序数据的排序约定，往往要业务方一起确认。（此处不要继续展开第三方工具细节，选型时看是否有可导出的用例与结果留痕即可。）
方案三：交给外部团队做整体验证与迁移实施
适合内部开发资源紧张，或系统由多年前的外包方交付、源代码与文档不齐的政府与国企存量系统。这类项目里，真正的难点往往不是换库本身，而是搞清楚系统到底依赖了什么。
- 优点：梳理、清单、验证、整改由同一方闭环负责，责任边界清楚。
- 优点：通常有现成的梳理方法与检查项集合，可减少重复投入。
- 缺点：需要较完整地开放代码、部署环境与数据库账号，配合事项多。
- 缺点：如果合同中不写明清单交付物与验收方式，最后容易只拿到一份「迁移完成」的结论。
我们做过政企与制造、物流等行业的系统集成与迁移类工作，交付过程涵盖需求调研、POC 验证、开发联调、上线验收与运维交接，可参考服务范围与交付流程。也建议在选型阶段就走一次小范围 POC，用真实模块验证清单是否够用。
清单交付时要求写清楚什么
- 每个检查项对应的系统模块与证据来源，例如具体功能、SQL 文件或配置项的位置说明。
- 结论标注要区分「通过」「需改造」「不适用」，不接受笼统的「基本可用」。
- 改造项要有责任人与计划完成时间，并明确回归验证方式。
- 明确回退条件：出现哪类问题就停止切换、回到原库。
什么情况下不要选这些方案
不要把「只换库、不改应用」当作默认方案。如果系统的存储过程与复杂 SQL 占比高、又没有熟悉的开发能跟进，绕开应用改造往往会拖长整体周期。
不要在没有梳理依赖面之前就上工具跑回归。没有场景化用例的比对，跑出来的结论很难支撑上线决策。
不要在合同或计划中承诺清单之外的确定性结论。兼容性验证本身存在不确定性，验收条款应描述交付物与验证方法，而不是直接约定「迁移后不出现任何问题」。安全合规与等保相关要求如需同步满足，也应在同一份清单里单列。
系统里如果同时涉及国产 OA 与业务系统之间的数据往来，这部分也要在清单里挂上接口层的验证项。常见做法是先梳理组织、权限与主数据的流向，再验证对接结果，可参考同类项目案例中的系统集成场景。
文字版对比清单
- 自建清单逐项梳理 → 适合有熟悉代码的开发与 DBA、系统规模可控的团队 → 主要代价是梳理耗时、易漏行为差异。
- 专项工具跑 SQL 与数据回归 → 适合 SQL 多、数据量大、需要反复回归的系统 → 主要代价是用例与脱敏样本准备成本高，结论仍需人来判断。
- 外部团队整体验证与实施 → 适合内部资源不足、文档缺失的存量政企系统 → 主要代价是配合与开放程度要求高，需在合同中明确交付物。
- 只换库不改应用（作为对照）→ 适合依赖面极窄、SQL 简单的系统 → 主要代价是风险集中在上线后暴露，不建议作为默认路线。
常见问题
清单要覆盖到存储过程吗
要。存储过程与触发器往往是兼容性问题集中的地方，逐个人工核对成本高，但可以先按被调用频率和业务重要性排优先级。
测试数据从哪里来
一般从生产环境脱敏导出，再补一批边界数据，例如空值、超长字段、特殊字符与历史数据中的脏数据。数据准备工作通常需要业务方参与。
什么时候判断可以正式切换
清单中「需改造」项已完成并回归通过，关键业务流程在新库上完整跑通，回退条件明确，才算具备切换条件。具体的判断标准建议与业务、运维共同确认后写进验收文档。
