结论先行：不少替代项目实际走的不是一次性切换，而是一台机器上并存两套系统、过渡一段时间——业务软件还没适配完、专用设备还没替代方案，先让业务跑起来。这个折中解决了当期问题，代价是把四件事同时变复杂：操作日志只盖住新系统那一半、共享分区成了跨系统的数据通道、账号两套各管各的、补丁两条线分开走。可行的做法是把这四件事写成过渡期的边界条款，同时约定什么时候必须收口。
本文只谈同机并存两套系统这段时间里，审计与管控口径怎么补、什么时候该结束过渡，不谈迁移路径怎么选、不谈用户侧的培训与验收，也不谈该选哪套系统。
双系统是怎么出现的
它的出现通常不是因为方案设计，而是因为现场妥协，原因无非三类。
业务软件没有对应版本。某些行业软件、专用工具、报表插件只有旧平台版本，替代窗口又要按期推进，于是同一台机器上留一套旧系统专门跑这个软件。
专用设备的驱动链太长。票据打印机、身份阅读器、加密介质、老型号数控与检测设备，驱动只有旧平台的版本，换设备的预算和周期都跟不上。
窗口与预算的考虑。一次性切换的风险集中在一个窗口里，分两步走可以把风险摊薄，先保证业务连续，再慢慢收尾。
三类原因都合理。问题不在要不要双系统，而在于多数项目只准备了装机方案，没有准备过渡期的管控方案——两套系统装上之后，「按新系统的标准管」这句话就落不了地了。
漏点一：日志只盖住了新系统
合规要求里写得最实的一条，是操作要可追溯、日志要留存到规定期限。双系统情形下，这条要求会出现一个很具体的裂缝：采集与审计的配置通常只做在新系统上，旧系统那部分是空白。
空白带来的后果不是抽象的。同一台机器上，有人在旧系统里拷走了一批文件、装了一个软件、改了一次共享设置——这些动作在新系统的日志里完全不存在，因为动作压根没在新系统里发生。
可行的补法有两条。一条是把旧系统的关键日志也纳入采集范围，范围不必求全，先覆盖登录、账户与权限变更、外发与拷贝三类，这三类与追责的关系最直接。另一条是把旧系统的日志留存期与原系统区分开：过渡期的留存要求应当按正式环境看待，而不是按「临时环境」处理，理由很简单——过渡期发生的操作，事后一样会被问到。
还有一处容易忽略：两个系统的时间基准可能不一致。日志分析类平台对时间戳口径很敏感，两套系统的时钟不齐，事后拼时间线就拼不上。过渡期开始前，把两个系统的时间同步指向同一个来源，这是一件五分钟就能做完的事。
漏点二：共享分区成了跨系统的通道
为了让两个系统之间能交换文件，最常见的一种做法是划一个共享分区，两边都挂载。这个做法在装机阶段最省事，在安全侧却可能是整件事的破口。
原因是：新系统的安全设计通常建立在「数据不落在没有管控的位置」这个前提上，而共享分区恰好是一个两边都能写、权限口径很难统一的位置。文件放在这里，前面做的加密、管控、外发审计都绕过去了。
可行的处理是把共享分区从「双向读写」改成「单向」：由新系统向共享分区写、旧系统只读，或者反过来。方向按业务实际需要定，但不要双向。确实需要双向交换的，改成由人在两个系统里各做一次导入导出，虽然麻烦，但每一次都有记录。
另一个常被忽略的点是分区的清理责任。共享分区里的文件没有归属人，会一直堆着，堆到没人知道哪些还有用。可行的做法是给分区设一个保留期，到期由指定岗位确认后清理。
漏点三：账号有两套，回收只做了一边
两套系统就是两套账户体系。过渡期最常见的一类隐患，是人员离职或转岗时，账号只在其中一边被处理掉。
这类情况的特征是安静：旧系统里的账号没人登录，所以没有告警；它也出现在资产清单里，因为资产清单统计的是设备，不是账号。等到某次检查或者某个异常登录才被发现，通常已经过去了很久。
可行的做法是确立一个单一来源：以人事名单为准，把两个系统的账号清单各自导出来，按月比对一次。比对只看两个结果——应删未删的、和权限与岗位不符的。一次比对的工作量通常在一两个小时，把它写进月度例行工作里，比事后排查便宜得多。
另外给过渡期一个硬约束：从过渡期开始那天起，不再新增旧系统的账号权限申请。老账号按名单逐步清理，新需求一律走新系统。这条约束能防止过渡期变成两个系统并行增长。
漏点四：补丁分成两条线
新系统有正常的补丁通道，旧系统在过渡期里往往处在「不升级」状态——怕升级之后专用软件和设备又不能用了。于是同一台机器上，一个系统在持续修补，另一个系统的漏洞停在几个月前。
这个安排本身是理性的，但它必须被写下来，否则会被当成「设备已经纳管、补丁已覆盖」。可行的做法有三步。
其一，把旧系统单独列成一个资产分组，补丁覆盖率单独统计，不与新系统混在一起报一个总数。
其二，对旧系统做一次漏洞评估，按月更新一次结论。评估的目的不是马上修补，而是给一个明确的判断：哪些漏洞在两套系统并存的边界下无法被利用，哪些可以。
其三，用边界补丁替代系统补丁。旧系统不打的补丁，可以在接入层、外设管控、访问路径上做补偿——虽然不如修掉彻底，但比什么都不做要好，而且这些补偿动作是可核对、可留痕的。
四个信号，能看出过渡期在失控
过渡期最怕的是「过渡成了常态」却没人说。四个可观测的信号可以用来定期看。
- 旧系统登录日志的缺失率。某几个部门的旧系统日志一直采不上来，说明采集配置从未补齐，不是偶发问题。
- 共享分区的写入量趋势。持续上升说明跨系统交换在变频繁，边界正在被业务需求一点点撑开。
- 两个系统的账号数差异。差距不再收窄，说明清理动作停了。
- 旧系统最近一次补丁的月份。超过半年没有动过，它的风险等级已经变了，只是没人重新评估。
四个信号都只需要现成的数据，不需要新建采集。按月看一次，够用。
什么时候必须收口
过渡期需要一个结束条件，否则它会因为「用着也还行」而长期存在。三个条件，任何一个满足就该启动收口。
其一，推动双系统的原始原因消失了——业务软件有对应版本了，专用设备有替代方案了。原因消失而双系统还在，通常只是没人推动。
其二，旧系统出现了在两套系统边界下无法缓解的漏洞。这时候留着它的风险已经明确超过切换的成本。
其三，过渡期的管理成本超过了切换成本。这条最容易被忽略：两边维护账号、两条补丁线、两套日志，这些重复劳动是持续的，而且不产生新的价值。
收口时还有一些具体动作不能漏：旧系统的数据要迁走或明确作废、账号要一次性清理干净、共享分区要确认没有遗漏文件、最后一轮旧系统日志要归档留存——过渡期的日志本身也是证据，不能随系统一起下线就消失。
落地清单
- 过渡期开始时，先把两个系统的时间同步到同一来源。
- 旧系统的登录、权限变更、外发拷贝三类日志纳入采集，留存按正式环境对待。
- 共享分区只做单向，确实要双向的改成人做导入导出并留痕。
- 以人事名单为单一来源，两套系统账号按月比对，只处理应删未删与权限不符。
- 过渡期起不再新增旧系统权限，新需求一律走新系统。
- 旧系统单独列资产分组，补丁覆盖率单独统计，按月更新漏洞评估结论。
- 不打的补丁在接入层与外设管控上做补偿，并留下记录。
- 事先写清三个收口条件，任一满足即启动收口流程。
边界与前提
三点说明。其一，双系统并存属于过渡期做法，其适用条件须结合业务软件适配进度与专用设备替代方案判断，本文不构成对任何具体项目节奏的建议。其二，日志留存期限、审计范围与账号管理要求因行业而异，具体口径须以本单位制度与所在行业的合规要求为准，文中描述的期限不作通用承诺。其三，两套系统的挂载方式、分区权限与采集能力取决于具体系统版本与部署方式，落地前应以实际环境验证为准。
深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在国产化替代与桌面环境项目里，遇到需要并存过渡的场景，会先把四类边界条款与收口条件一起写进实施方案，再开始装机——顺序反了，过渡期往往一拖就是一两年。预约咨询，可以先盘一遍现有环境里还有多少台机器在跑两套系统。