最近看到一个很有意思的政府采购项目。

2026年，北京某单位发布“核心业务系统能力提升项目”采购公告，项目总预算454.7万元。其中，“应用软件开发与适配”预算415.5万元。

而采购需求里有一句话格外醒目：

“在保证原有功能不变的前提下”，完成2个业务系统操作系统等基础软件升级替代，对各业务应用模块进行代码适配和优化，并完成数据迁移。

也就是说，从业务人员的使用感受来看，原来能审批，现在还是审批；原来能查询，现在还是查询；原来的功能原则上一个都没有增加。

但项目仍然需要投入四百多万元。

如果站在建设单位的角度，很自然会产生一个疑问：

功能都没增加，这几百万到底买了什么？

这个问题，其实比“信创迁移贵不贵”更值得弄清楚。

很多人第一次接触信创迁移，会把它理解成一次“系统搬家”。

原来的软件装到国产服务器上，再换一套国产操作系统、数据库、中间件，重新部署一下，不就完成了吗？

实际往往没这么简单。

一个已经运行多年的业务系统，背后可能绑定了特定操作系统、数据库、中间件和第三方组件。底层环境发生变化之后，用户看到的功能虽然没有变，支撑这些功能运行的代码却可能需要调整。

例如，数据库更换以后，原来的SQL语句、存储过程、驱动程序可能需要修改；中间件变化以后，部分接口和配置需要重新适配；一些原来依赖的第三方组件不能继续使用，还要重新寻找替代方案。

除此之外，还有数据迁移、接口联调、兼容性测试、性能优化、系统割接、回退方案等工作。

所以：

信创迁移的费用，通常不是一个简单的“迁移费”。

有的钱花在应用适配。

原有代码为了在新的操作系统、数据库和中间件环境中正常运行，需要进行修改和优化。

有的钱花在数据迁移。

几十GB数据和几十TB数据显然不是一回事；同构数据库迁移和异构数据库转换，工作量也可能完全不同。

有的钱花在接口改造。

一个系统可能还连接统一身份认证、电子签章、短信平台、数据共享平台以及其他业务系统。底层环境变化以后，这些接口是否仍能正常运行，需要重新验证甚至改造。

还有的钱花在测试和上线保障。

一些重要业务不能长时间停机，就可能需要新旧系统并行、分批迁移，甚至准备完整的回退方案。

所以，对于建设单位而言，面对一笔几百万元的信创迁移预算，最重要的其实不是自己学会算软件造价。

而是能够问清楚：

这几百万分别在解决什么问题？

如果这个问题始终说不清楚，后面的价格判断自然也很难说清楚。

现实项目里，更值得建设单位关注的是另一种情况：

需求文件里只写一句：

“完成现有系统国产化适配改造。”

然后下面直接对应一个几百万元的总价。

至于哪些模块需要改代码、多少数据需要迁移、涉及多少接口、哪些基础软件需要替换、有没有新增功能，很少进一步拆开。

这时候，“信创适配”就很容易变成一个大筐。

应用改造放进去；

数据迁移放进去；

系统部署放进去；

接口调整放进去；

甚至原来系统已经具备的功能，也可能重新包装成“适配开发工作量”。

最后建设单位看到的，只剩下一句话：

工作量很大。

但到底哪里大，却很难验证。

所以从建设单位视角看，信创项目真正应该控制的，并不是把价格一味压低，而是不能让“技术复杂”替代费用边界说明。

几百万可以合理。

但几百万应该能够被解释。

其实很多价格争议，并不是到了结算阶段才产生的。

问题往往在项目立项和需求编制阶段就已经埋下了。

如果建设单位只提供一个系统名称和一句“进行信创适配”，后续不管是供应商报价、财政评审还是造价审核，都只能再花大量时间反推项目到底要做什么。

所以这类项目在前期有一个很实用的做法：

先把“存量”和“变化”分开。

首先要知道原系统是什么样。

现在使用什么操作系统、数据库和中间件？有多少业务模块？多少接口？数据规模多大？有哪些第三方组件？

然后再明确这次准备改什么。

哪些基础软件需要替换？哪些代码预计需要调整？哪些接口需要重新适配？数据是否需要转换？有没有趁迁移同步新增或优化业务功能？

这两部分一对照，项目边界就会清楚很多。

对于建设单位而言，并不要求自己逐行分析代码。

但是至少应该能够要求设计单位、原系统厂商或者咨询机构形成一份能够支撑投资测算的改造范围清单。

否则，很容易出现一种情况：

方案写得很厚，但真正与费用有关的内容只有一句“完成国产化适配”。

信创项目中还有一个比较隐蔽的问题：

费用拆得很细，不代表费用边界就一定清楚。

比如一个项目同时出现：

“应用适配开发费”

“系统迁移费”

“数据库迁移费”

“部署实施费”

“接口适配费”

看起来分得非常专业。

真正应该关注的是：这些费用背后的工作有没有重叠。

例如，应用适配费用里已经包含数据库相关代码调整，后面的数据库迁移又把同一部分改造工作算了一次；

或者系统适配开发已经包含安装部署，上线时又单独出现一笔“部署实施费”。

《信息技术应用创新 信息系统适配改造成本度量》已经专门对这类项目的成本测算进行了规范。该标准适用于信息技术应用创新环境下的信息系统适配改造项目，覆盖费用估算、结算审计、合同变更以及成本管理等场景，并对软硬件设备采购费用、应用系统适配改造规模、工作量和费用测算等进行了规定。换句话说，信创迁移并不是简单把原系统“重新开发一次”，而是需要结合实际适配改造范围，对软硬件采购、应用适配、迁移实施等工作分别识别和测算。

这对建设单位其实有一个很重要的启发：

在项目预算编制或送审前，可以要求把新增开发、适配改造、系统迁移、产品购置等费用边界分别说明。

对于确实涉及新增或实质性改造的软件功能，也可以委托造价咨询机构进一步梳理功能清单和软件规模。在实际测算中，可借助软件造价喵辅助开展功能点识别、功能清单整理和费用测算，结合平台沉淀的10年行业基准数据及70余项国家、行业、省市级软件和信息化项目造价标准，对其中属于软件开发的部分进行测算。

这里最重要的不是把所有信创费用都拿去“算功能点”。

而是先搞清楚：

哪些是开发的钱，哪些是迁移的钱，哪些是买产品的钱。

各算各的，反而更容易把预算说清楚。

前期把钱说清楚以后，还有一个容易被忽略的问题：

几百万花完以后，建设单位最终应该拿什么来证明这些工作真的完成了？

如果验收只停留在：

系统能登录；

原来的功能还能使用；

页面没有明显报错；

那其实只能证明“系统现在能运行”。

却很难证明预算里那些适配、迁移和优化工作是否真正完成。

因此，对于这类项目，验收成果最好能够和前期的改造范围对应起来。

哪些模块完成了代码适配，应有对应成果；

哪些接口进行了改造，应有联调和测试记录；

迁移了多少数据，应有迁移结果和完整性、一致性验证；

涉及新旧环境切换的，还应关注割接记录、回退方案、试运行和性能验证。

尤其值得注意的是：

如果预算里写了十几项工作，而验收时最终只有一份“系统运行正常”的验收报告，建设单位其实很难判断这些钱分别形成了什么成果。

这也是信创项目不能只在结算阶段关心造价的原因。

真正有效的成本控制，应该从需求范围、预算编制，一直延伸到实施、验收和结算。