这几类系统，迁移清单上可以先空着

结论先行：迁移清单通常是一路往上加系统的——资产盘完，凡是不在国产系统上的都进清单，然后按业务重要性排期。问题在于清单本身没有排除项，于是首批上线时会被四类系统卡住：厂商根本不做国产版本的专用软件、依赖专有外设驱动的设备、业务方自己也说不清版本的遗留系统、以及明年就要下线或替换的系统。这四类先空着，比硬排进首批更省时间；但空格必须挂复评时间，否则一年后没人记得为什么空在那里。

本文只谈迁移范围该怎么划、哪几类先排除，不谈某类系统该怎么适配、也不谈部署形态该选裸机还是虚拟化。适配是执行层的活，形态是另一个决策点。

已有的痛点里，有一半是范围问题

现有国产化改造中被反复提到的几类问题，拆开看会发现它们不是技术难点，是范围划得太宽：办公软件适配差、业务系统兼容不全、外设驱动缺失。这三句描述的共同点是——它们都是「用了之后才发现」的。

为什么会用了之后才发现？因为评估阶段拿到的是清单，不是测试结果。清单上写着一个系统，评估结论是「有国产版本」，这条就过关了；至于这个版本在你的业务场景里跑不跑得通、性能掉多少、外设认不认，要等真正装上去才知道。

所以范围这件事的核心，不是判断「支持不支持」，而是判断「这个支持对你意味着什么」。有些系统的国产版本功能完整、有些只是能装上、还有些要等厂商的下一版。

四类先空着

下面四类不是永远不迁，是说在首批里把它们留空，比硬塞进去更划算。

四类里，第二类的代价最高，因为它是硬停摆。软件跑不起来还能降级用，外设认不出来就是业务动作做不了——打印不出来、扫不进去、读卡器不响应。这类设备往往集中在窗口、车间、门禁这些不能停的地方。

厂商无版本这一类的代价最隐蔽：它不表现为失败，而表现为「迁完了但仍有一套旧环境在跑」。表面上国产化率达标，实际上运维要同时管两套。这种做法在验收时能过，在半年后开始出问题——因为那套旧环境没人升级、没人打补丁、也没人知道它在哪台机器上。

空着的格子要写三个字段

排除项最怕的不是排除了，是排除之后没人记得。一份能长期用的迁移清单，每个空格里至少要有三样东西。

• 排除原因的类型：是厂商没有版本、是外设没驱动、是资产不清、还是即将退役。四种原因的后续动作完全不同。
• 解锁条件：什么条件成立时可以重新评估。比如「厂商发布国产平台版本并通过功能对齐验证」「外设驱动通过验证」「业务方完成版本梳理」。
• 复评日期：写具体日期。只写条件不写日期，条件永远不会被触发检查。

这三样加起来只是一行字，但它把一张静态清单变成了一份有生命周期的计划。没有这一行，第二年做规划时，同样四类系统会被重新讨论一遍，结论可能还不一样。

清单位于哪一层，决定了它靠不靠得住

资产梳理这件事，粒度差别极大。按部门盘一遍，得到的是「某科室有几台机器、装了什么系统」；按业务系统盘一遍，得到的是「某个系统部署在哪几台机器上、依赖什么中间件、用什么外设」。这两种清单在迁移时能做的事完全不同。

按部门盘的清单只能回答覆盖率，第二种才能回答排期。因为迁移的单元是业务系统，不是机器——一个系统往往横跨几台服务器、几种中间件、若干外设。评估阶段的正确产出应该是：每个业务系统对应一份依赖清单，加上一份结论，结论只有三种——可以直接迁、需要适配后迁、暂时不迁。

做到这个粒度，排除项会自然浮现，不需要专门去开会讨论「哪些不迁」。因为盘点过程中被标为「暂时不迁」的，本来就有明确理由。

首批的范围，宁可小一点

试点这一步的作用常被低估。它不只是验证技术可行性，更重要的作用是把评估阶段的结论与真实结果对一遍：评估说可以直接迁的，实际迁过去有没有出问题；评估说要适配的，适配工作量估得准不准。

如果试点选的是最容易的几个系统，这个对照就失去意义了。更合理的选法是在三类结论里各选一两个代表，让首批的结果同时检验三种判断。这样得到的偏差数据，才是后面批量推广的排期依据。

批量推广阶段再按批推进，每批的结论回写到清单里，清单才越用越准。反过来，如果首批全部挑软柿子，第二批就会撞上所有被推迟的问题，那时候已经没有调整窗口了。

边界与前提

三点说明。其一，本文讨论的是迁移范围与排除项的划法，不涉及任何具体产品的适配结论；某一系统能不能迁，以厂商答复与本单位验证结果为准。其二，排除项的判断与资产清单的准确度直接相关，台账本身不清时，先做梳理再谈排期。其三，涉及行业监管要求的系统，迁移时序可能受外部约束，应在计划中留出合规评审的时间。

深圳市奇摩计算机有限公司做过不少从评估走到批量的信创项目，经验是：清单上敢留空的单位，后面推进得更快，因为它把不确定性提前暴露在纸面上，而不是留到上线当天。预约咨询，可以按你现有的系统与资产清单，先把这四类排除项标出来。