信创改造的并行期，新旧两套通讯怎么平稳过渡？

信创改造进入新旧通讯系统并行期，文章按定主系统、并组织账号、处置群文件、终端适配、重建集成、双轨运行、验收回退的顺序，给出可执行的过渡方法与检查清单。

预计阅读时间24分钟发布时间2026-11-06 更新时间2026-11-06 作者：杨晓敏

信创改造走到并行期，新旧两套通讯系统并存，往往先让人感到别扭。旧系统里还有没结项的项目群，新系统已经装到了国产终端上；同一个通知，行政在旧群发一遍，项目经理又在新群发一遍。两套系统都在跑，实际却形成了两套事实。

这里说的通讯，主要指日常办公用的企业即时通讯系统，也包括挂在它上面的通知、审批提醒和机器人。邮箱、会议系统如果也在替换范围内，可以按同样的顺序处理，但账号和组织的底座要先统一。

平稳过渡的关键，不是把两套系统都保留下来，而是尽快确定一套正式入口，再按组织、账号、群组、文件、集成的顺序把业务关系迁过去。双轨运行负责验证和兜底，不负责长期共存。

据公开报道，国资委2022年发布的79号文提出，中央企业要在2027年底前完成信息化系统的信创替代。距离2027年底只剩一年多，留给单位反复试错的空间已经不多。下面按实际推进顺序，把并行期该做的事拆开。

一、先定主系统和边界，别让两套入口都办正式业务

并行期常见的做法是两边都发。旧群发一份，新群再发一份，生怕谁看不到。这个动作看起来稳妥，实际会把责任和版本拆散。员工不知道该以哪边为准，管理者也无法判断哪条消息是正式通知。

正式入口只能有一个。 涉及制度发布、项目决策、财务附件、生产异常、客户敏感信息和管理通知的事项，优先走新系统；旧系统只保留历史查询和短期过渡沟通，不再承接新的正式业务闭环。这个边界要由项目组发文确认，不能只靠IT口头通知。

主系统要满足四个条件：覆盖多数员工，承载关键业务群，接得住现有身份源，有明确的运维和审计责任人。功能多少不是首要条件。一个功能很全但没人会运维的系统，放到信创环境里反而会增加切换风险。

常见的并行方式有三种，适合的情况不同。

方式	适合情况	主要代价
单主系统	多数信创改造项目，业务重叠度高，合规边界允许统一管理	迁移工作集中，切换窗口要排好
双系统共存	独立法人、不同合规边界、整合过渡期较长	两套目录、两套群、两套权限，运维和培训成本高
保持隔离	涉密、跨境、强监管，或业务本身需要独立	只能做有限连接，不合并账号和资料

多数信创改造适合单主系统加一段过渡期。双系统共存不是不能做，但要把它当成有期限的过渡安排，而不是默认长期方案。决定之前，先把回退条件写下来：什么情况下暂停切换，由谁决定，旧系统怎么恢复，恢复后数据以哪边为准。回退方案不写清楚，切换时很容易被现场情绪推着走。

两套IM合并时的组织、账号与资料处理顺序，可以先看这篇实践文章，里面把三种模式和验收口径拆得更细。

二、组织和账号先并，别从聊天记录开始搬

组织架构是账号、群组和权限的底座。 组织没并清楚，账号就只能靠姓名和部门猜，后面容易出现重名、错配和权限残留。

先确定权威组织源。HR系统、AD/LDAP或集团主数据，选一个作为准绳，其他系统向它对齐。再画一张正式组织树，至少包含法人、事业部、部门、岗位四级。项目组、专项组和临时协作关系不要写进正式组织树，它们应该放在群组里，否则组织树会随着项目变化反复调整。

组织编码要统一。部门ID、上级部门ID、部门名称、负责人、管理员、生效日期，这几项在两套系统之间建立对应关系。重名部门很常见，两个市场部或三个研发中心，只靠名称匹配很容易出错。编码不要求复杂，但要保证不重复、稳定、能追溯历史变更。

权限边界要在建账号前定。总部管理员能管哪些单位，子公司管理员能管哪些部门，跨公司通讯录是否可见，外部联系人由谁审批。这些规则如果等到账号建完再补，往往要返工。

账号合并的目标是 一个人一个主账号，不是把两张表拼在一起。账号背后挂着登录、群主身份、文件权限、审批记录和审计日志，错一个，后面会连着错。先建账号映射表，至少包含源账号ID、目标账号ID、工号、姓名、部门、岗位、账号类型、状态、冲突处理和负责人。主键优先选工号或企业邮箱，手机号可以做辅助，但不要拿它当主键。

有几类账号要单独处理。重名账号用组织编码加主键区分；兼职和返聘人员明确主部门、主账号和额外权限；离职和停用账号先冻结、回收权限、移交群主和文件，再决定是否删除；外包和外部账号单独标记类型、有效期和审批人；服务账号和机器人单独建台账，记录用途、负责人和调用范围。

身份源尽量统一到HR系统、AD/LDAP或集团统一身份平台。能自动同步的，不要长期靠Excel手工维护。喧喧IM可以通过LDAP/AD承接已有账号体系，具体认证能力和版本边界可以看通讯安全页面的说明。

账号验收看四个数：账号总数与主数据一致，目标系统可登录率达到约定值，重名和冲突账号清零，离职账号完成冻结和权限回收。再加一项人工抽检，随机选几个部门，核对管理员权限和群主身份，确认没有把旧系统的管理员权限原样带过来。

三、群和文件按四类处置，历史消息不必全搬

账号建完，不代表群能用。群主、管理员、成员、外部联系人和文件权限，都要在新系统里重新落一遍。即时通讯系统迁移的难点，通常不在账号数量，而在群、文件、权限和集成这些关系。

先把群分成六类：组织与通知群、项目与业务群、外部协作群、临时与事件群、交接风险群、集成与机器人群。分类的目的不是整理好看，而是决定处置方式。每个群至少记录群名称、群类型、群主和备份管理员、成员范围、外部成员、最近活跃时间、关联项目或合同、关键文件、处置结论。

处置结论通常有四类。业务跨切换日继续、成员和文件还要用的，迁移；项目结束或业务不再活跃但有留存义务的，归档；群结构、外部成员或集成需要调整的，重建；临时群、重复群、没有业务价值的文件，由负责人确认后放弃。

群主离职或调岗的群要优先处理。先补一名备份管理员，再把群主变更到在岗负责人，随后移交文件。不要等离职当天才操作，也不要把交接责任只放在离职员工身上。同名群和重复群要在这一步合并，同一项目、同一客户、同一部门保留一个主群，其余群发迁移说明后归档或解散。

外部客户群建议重建，不直接沿用。重新确认外部成员身份，重新审批入群，重新设置文件权限。合同、报价、研发资料不放进外部群；必须共享时用受控链接，并设置访问范围和有效期。

文件盘点先按业务价值分四类：业务凭证、核心资产、人员与客户信息、过程记录。每份文件记录文件名、类型、所属项目或群、现行版本、主副本位置、维护人、敏感级别、权限范围、最近使用时间和处置。

文件迁移的关键是主副本和现行版本。同一份文件在群里可能有很多个版本，真正算数的那份只有发送的人知道。先确定哪个版本算数，再把主副本迁到新系统或归档目录，历史版本单独归档。 文件复制过去不等于关系恢复，文件与消息的引用、权限和版本要一起处理。外部共享链接要回收或重设有效期，敏感文件重新设权限，不要沿用旧系统的公开范围。

如果单位已有数据分类分级制度，直接沿用。没有的话，可以参考2024年10月1日实施的GB/T 43697-2024《数据安全技术数据分类分级规则》，至少区分一般、重要和核心数据，再决定迁移范围和权限。

历史消息不必全部迁移。 先看业务是否还需要回溯，是否存在合同、审计或诉讼留存义务，目标系统能不能承接原格式。多数单位只保留关键群和关键时间段的记录，其余在旧系统保留一段只读期后归档。把全部历史消息搬过去，成本高，价值未必大。

这里要提前知道一个边界：如果目标系统是喧喧IM，目前不支持把聊天记录一键导出为加密或明文格式，迁移通常要结合原平台的导出格式做备份、清洗和映射。这不是一句能不能导的问题，而是导出后能不能还原成可用会话的问题。群和文件的盘点字段、处置规则，可以参考企业内部沟通平台切换前，哪些群和文件需要先盘点。

四、国产终端和旧终端混用，客户端与网络提前排

信创改造和国产化替代不是把所有电脑一次换完。更常见的情况是，同一部门里既有旧Windows终端，也有国产桌面，还有手机和会议室设备。通讯系统要在这几种终端之间保持可用，客户端分发和网络访问得提前安排。

信创适配不能只看客户端能不能装。 真正要验证的是一条链：服务端、数据库、中间件、操作系统、CPU，以及消息中转组件能不能整体跑通。国产操作系统常见的有银河麒麟、统信UOS、Deepin，国产CPU包括申威、麒麟、兆芯、鲲鹏、海光、飞腾、海思盘古、龙芯。不同产品的适配清单和实测深度差异很大，具体范围要以厂商清单和本单位真机测试为准。

如果单位正在做国产终端替换，可以先核对信创适配页面上的操作系统与CPU范围，再用实际终端做一轮验证。验证项不要只写登录，至少包括消息收发、文件上传下载、文件预览、音视频设备调用、消息提醒、@成员、断网重连和客户端升级。

客户端分发要提前公告。登录地址是否变化，移动端是否要重新配置，旧入口什么时候关闭，升级包从哪里获取，这些问题要在切换前说清楚。可以选一个部门或一个项目试点，跑通真实流程后再扩大范围。切换窗口尽量避开重大项目交付、月末结算和业务高峰。

网络边界也要一起排。服务端部署在公网可访问的环境，还是只在企业内网访问，移动端在外网时怎么连，专网和办公网之间是否隔离，这些都会影响用户体验。不要让用户自己猜，也不要在切换当天才发现某个楼层的网络访问不到新系统。

培训只讲差异，不发厚手册。新客户端怎么登录，群从哪里进，文件在哪里找，消息怎么搜，通知怎么设，这几个动作讲清楚，比发一本操作手册有用。培训材料可以按岗位拆成几页，让部门管理员先学会，再回到部门里带人。

五、机器人和集成常是断链点，切换前逐项重建

IM不只是聊天窗口，还接着机器人、Webhook、审批通知、监控告警、OA/ERP通知、单点登录和业务系统回调。这些集成往往不在群成员列表里，却直接影响业务是否断链。

先把旧系统的集成清单拉出来，逐项记录用途、调用方、接收方、负责人、触发条件和频率。机器人、Webhook、审批提醒、监控告警、OA/ERP通知、单点登录，分别在新系统重建并测试。接口协议和目标系统不同，移植往往比重建麻烦，不要假设旧配置能直接复制。

每重建一项，就用真实业务场景跑一遍，确认消息能到正确的人、正确的群，失败时有告警。 漏掉一个告警通道，可能出现系统以为发了、业务却没收到的情况。 单点登录和组织同步要一起测，覆盖入职、离职、调岗这几个动作，避免人已经调走，权限还留在原部门。

切换入口也要一起设计。客户端怎么安装，旧入口什么时候关闭，移动端怎么切换，这些要写进切换通知。可以先选一两个部门试点，跑通发消息、建群、传文件、开会、@人、机器人通知等真实流程，再逐步放大。

扩展能力要看接口和事件是否够用。API、Webhook、机器人、单点登录分别解决不同问题，选型时不要只看功能列表，要让厂商按你们的实际系统清单做一次联调演示。

六、双轨运行设止损线，按三段推进

双轨运行的本质，不是两套系统同时让用户随便用，而是新系统小范围真实运行、旧系统全面保底。理解成想用哪个用哪个，后面数据一定乱套。

比较稳妥的安排分三段。

影子期，新系统只给试点部门用，不对外承接正式业务，旧系统继续保底。重点验证登录、消息、文件、音视频、集成和权限，发现问题先修，不急着放量。

双轨期，关键业务在新系统跑，旧系统保留历史查询和回退能力。两边的差异要挂到具体的人，按取数差异、流程差异、权限差异分开处理，每周对账。这个阶段的目标不是让两套系统一样忙，而是让新系统逐步接管正式业务，旧系统逐步退到查询和兜底。

切换期，按部门或项目分批放量。每批观察一段时间，确认关键业务没有阻断，再扩大下一批。不要一次全量切换，也不要在同一天切换所有单位。

双轨运行要设止损线。时间上限、问题数、用户反馈、关键业务是否跑通，这几个条件提前写清楚。比如连续两周关键业务无阻断、严重问题清零、试点部门登录率稳定，才进入下一批。具体标准由单位按业务复杂度定，但要有明确的暂停和回退条件。

每周至少看这几项：登录率、消息送达、文件打开、音视频可用、集成告警、工单量、用户反馈。哪项异常，就先停下来查，不要靠加班和口头解释把问题压过去。

双轨时间不是越长越稳。 两套群、两套权限、两套通知同时维护，时间一长，运维成本和用户混乱都会上升，用户也会习惯旧系统。给并行期一个明确的结束条件，比无限期延长更稳妥。

七、验收和回退，五项检查过了再停旧系统

验收不要只看账号数。 账号建完，不代表群能用、文件能打开、权限正确。切换前至少做五项检查。

数量核对。 账号数、部门层级、群数量、群成员数、文件数，和盘点表对得上。

完整性抽查。 抽10%的群，核对群主、管理员、成员和外部成员；关键项目群检查关键文件能否打开、版本是否正确。

权限检查。 用不同角色登录，测试可见范围；外部成员只能看指定内容；敏感文件没有多余的访问口。

可检索。 搜关键决策、合同编号、项目名称，能在新系统找到对应的消息或文件。

业务连续性。 让试点部门跑一遍真实流程，发通知、传文件、开会、@人，确认机器人、Webhook、审批提醒正常。

五项都过，才进入全面切换。 旧系统保留一段只读期，用于核对历史消息、文件和权限。30天是常见参考，具体时长按数据量、合规要求和业务连续性定。

回退预案要在切换前写好，不是出问题后再讨论。至少写清触发条件、恢复步骤、数据回滚范围、负责人和沟通方式。旧系统保留只读期，备份保持可用，回退路径要实际演练过。下线前确认数据归档位置、保管人、保留期限和删除方式，不要只保留一份备份。

八、选型时提前核对的能力

如果单位正准备选一套新的企业通讯系统，下面这些能力要在选型阶段核对，不要等上线后再补。

信创适配清单和真机验证。 服务端、客户端、数据库、中间件、CPU和操作系统要按本单位实际组合验证，不能只看宣传页上的支持列表。适配证书能说明验证过某个版本或组合，不能扩大解释为所有环境都兼容。

私有化部署和数据边界。 服务端部署在企业自己的服务器上，消息和文件留在企业内，数据由单位自己掌握。公网IP访问和纯内网访问两种网络环境要提前确认，移动端在外网时的访问规则也要问清楚。

组织同步和权限。 LDAP/AD或接口同步能不能承接现有账号体系，多级组织、组织隔离、管理员权限能不能按单位结构配置。同步深度、字段范围和版本支持要以实际部署为准。

群组、文件和检索。 群成员管理、消息检索、文件传输、文件预览、多端同步，这些是日常使用频率高的能力。选型时用真实部门关系和真实文件跑一遍，比看演示环境有用。

扩展和集成。 API、Webhook、机器人、单点登录能不能接住现有OA、ERP、审批和告警系统。接口文档、调用限制、失败重试和告警机制要一起看。

安全能力。 通信全链路加密、消息在数据库中加密存储、服务端文件加密、IP登录限制、消息审计、界面水印，这些能力要按单位合规要求逐项核对。高级安全能力通常与版本和部署配置有关，不要默认所有版本都一样。

以喧喧IM为例。它采用私有化部署，支持银河麒麟、统信UOS、Deepin等国产操作系统，以及申威、麒麟、兆芯、鲲鹏、海光、飞腾、海思盘古、龙芯等国产CPU；可以通过LDAP/AD承接账号体系，提供群组、消息检索、文件传输、API和Webhook等能力。版本分为开源版和专业版，信创适配、高级安全和企业级功能要结合专业版及实际部署配置确认。聊天记录目前不支持一键导出为加密或明文格式，迁移方案要提前设计。

如果单位更看重公有云生态、审批表单或外部客户连接，私有化IM的部署和运维成本要提前算清；如果核心诉求是数据留在企业内、群和文件可控，私有化部署更合适。数据留在企业服务器、由单位自己运维的方案，可以进一步看私有化部署的边界。

选型不是一次性采购。 国产操作系统和CPU版本还在迭代，厂商后续的适配跟进、升级支持和技术响应，要写进合同或服务约定里。