信创替换即时通讯工具时，旧客户端与新环境并行期怎么管理

上午刚给两个部门换了国产终端，下午就有人来问：旧客户端还能不能登录，原来的群要不要重建，聊天记录能不能搬过去。信创替换即时通讯工具时，这些问题几乎都会出现。

旧客户端与新环境并行，不是把两套软件同时开着就结束了。它本质上是一次即时通讯国产化替代，涉及终端、账号、会话、数据和权限在两边怎么对应，以及什么条件下可以关掉旧系统。管不好，员工会在两个窗口之间来回切换，消息散落，文件找不到，管理员也不知道哪套系统才是准的。

下面按实施顺序拆开讲：先定边界，再盘资产，选共存架构，分批安装验收，处理账号群组和数据，最后设退出条件。

一、先定并行期的边界：哪些要并行，哪些必须单轨

并行期最常见的失控，是所有人都知道要并行，但没人说清并行到什么程度。有人理解为旧客户端先别卸载，有人理解为旧系统继续收发消息，还有人理解为两套系统长期共存。三种理解对应的工作量完全不同。

1. 三种并行不要混在一起

信创替换里至少有三层并行：终端并行（Windows 与国产操作系统）、客户端并行（同一 IM 的新旧客户端）、系统并行（旧 IM 与新 IM）。

只换终端、不换 IM 时，优先让新旧终端接入同一套服务端，减少一套系统。只有换厂商、旧系统无法接入新服务端，或外部协作必须保留旧入口时，才需要双系统并行。把三种情况都做成双系统，管理成本会翻倍。

先判断是哪一层并行，再决定要不要双系统。

2. 用一张范围表把“管什么”写死

并行期范围表不用复杂，但要覆盖六类对象。

对象	要写清的内容	容易漏的点
终端	部门、机型、CPU 架构、操作系统版本、替换批次	只写“麒麟/UOS”，没写小版本和架构
账号	正式员工、外包、借调、共用终端、外部联系人	离职、转岗、长期不用账号
会话	关键群、群主、成员、外部群、通知群	群主离职后无人接手
文件	群文件、共享文件、附件链接、归档位置	只迁消息，不管文件
业务入口	与 IM 相关的通知、会议、集成入口	以为换 IM 不影响业务通知
旧系统权限	可写、只读、停用时间、责任人	没有明确谁有权关旧系统

这张表同时也是验收表。每一项都要有责任人和完成时间，不能只写“由 IT 负责”。

3. 退出条件先写，日期后定

新旧系统并行管理，多长取决于终端到货、部门批次、试点结果和问题关闭情况，没有统一天数。更稳妥的做法是先写退出条件，再倒排时间。

• 在用终端完成客户端安装，关键部门没有遗漏；
• 关键群完成重建，群主和成员确认；
• 文字、文件、离线消息、多端同步验收通过；
• 账号和组织架构完成同步，离职、转岗账号已处理；
• 历史数据完成迁移或归档，旧系统具备只读查询能力；
• 试点期问题关闭，回退方案经过一次实际演练。

这些条件满足后再关旧系统，比拍一个日期可靠。 不要用“一个月后下线”代替退出标准。

二、盘清三类资产：终端、账号、会话

盘资产是并行期最容易被跳过的一步。很多单位直接发安装包，装到一半才发现终端架构不对、账号对不上、关键群没人管。

1. 终端盘点先看 CPU 架构

信创终端不是一种机器。按 CPU 指令集和操作系统组合，常见办公终端可以归为四类。

终端类型	典型组合	uname -m	安装包重点关注
ARM	飞腾/鲲鹏 + 银河麒麟	aarch64	aarch64 的 deb 或 rpm
x86	海光/兆芯 + 统信 UOS	x86_64	amd64 或 x86_64 的 deb
LoongArch	龙芯 + 统信 UOS/银河麒麟	loongarch64	loongarch64 的 deb 或厂商包
申威	申威 + 国产操作系统	sw_64	厂商提供的对应架构包

这张表是典型组合，不是全部机型清单。安装前用 uname -m 和 cat /etc/os-release 核对架构、发行版和小版本，比只看“麒麟”或“UOS”可靠。有 Linux 安装包，不等于适配所有国产电脑。安装包架构不对，双击也会失败；依赖缺失，装完也可能启动不了。

以喧喧IM为例，官方 信创适配页列出的范围包括银河麒麟、统信UOS、Deepin，以及申威、兆芯、鲲鹏、海光、飞腾等 CPU。具体到某一台机器，仍要以对应版本和厂商适配说明为准。

先确认架构，再选安装包；这一步错了，后面的排障都是白费。

2. 账号盘点把“人”和“账号”分开

一个人可能有多个账号，一个账号也可能被多人使用。窗口单位的公用终端、外包人员、借调人员、退休返聘人员，都会让账号关系变复杂。

盘点时要回答几个问题：账号由谁创建、由谁停用；离职和转岗什么时候同步；外部联系人是否进入新系统；公用终端用哪个账号登录；管理员有几个人，分别能做什么。

如果单位已经有 LDAP 或 AD，优先把它作为统一账号源，避免在新旧系统各维护一份通讯录。两套通讯录各改各的，是并行期最常见的返工原因。

账号盘点不是导出一份名单，而是确定账号生命周期由谁负责。

3. 会话盘点按“必须重建、只需归档、可以解散”分级

群组不是越多越好。把旧系统里的群全部搬过去，既花时间，也会把过期项目和无效通知带进新系统。

• A 类必须重建：跨部门协作群、项目群、外部协作群、业务通知群。
• B 类只需归档：历史项目群、阶段性活动群，保留查询即可。
• C 类可以解散：临时讨论、重复通知、已经结束的群。

每类都要写清群主、成员、命名规则和保留的文件。群主离职的，要先指定接手人。关键群重建后，先在旧群发布迁移通知，再逐步把旧群设为只读。不要让两个群同时承载同一件事。

三、选共存架构：单服务端多客户端，还是双系统双轨

资产盘清后，才轮到选架构。对信创IM 来说，这里有一个常见误区：把“新旧客户端并存”直接等同于“新旧系统双轨”。两者不是一回事。

1. 能单服务端多客户端，就不要双系统

如果只是终端操作系统变了，而 IM 仍然用同一家产品，优先让新旧终端接入同一套服务端。Windows 客户端、国产操作系统客户端和移动端共用一个组织架构、一套群组、一份消息记录，管理成本最低。

以喧喧IM为例，它采用 私有化部署，服务端部署在企业自己的服务器上，客户端覆盖 Windows、macOS、Linux 和移动端；信创终端通过对应架构的 Linux 客户端接入同一套服务端。这样在只换终端、不换 IM 的场景里，员工不用同时维护两个聊天入口。

适用条件也要说清楚：旧客户端能不能连新服务端，取决于版本兼容矩阵；新终端有没有对应架构的安装包，取决于具体机型和系统版本。上线前用一台真实终端做登录、群聊、文件、离线消息测试，不要只看产品介绍。

单服务端多客户端的前提，是版本兼容和终端适配都经过实测。

2. 必须双系统时，先定“主系统”

换 IM 厂商、旧系统无法接入新服务端，或者外部协作必须保留旧入口时，才需要双系统。双系统最怕的不是技术，而是规则不清：同一件事在两个系统里都有人发起，消息和文件就会分叉。

建议先定三条规则：

1. 新业务只在新系统发起，旧系统只保留查询和历史会话；
2. 外部联系人如果必须用旧系统，单独划一条通道，不把外部群混进内部群；
3. 同一件事只在一个系统里留主记录，另一个系统只做通知或归档。

两套系统之间能不能互相发消息，要看厂商有没有提供互通或适配能力。不要默认“都是 IM，应该能通”。没有互通能力时，只能人工转达，这时要指定转达人、统一模板，避免截图和口头传话造成遗漏。

场景	主系统	旧系统角色	关键动作
只换终端，不换 IM	同一套 IM 服务端	旧客户端逐步退出	核对版本兼容，分批装客户端
换 IM 厂商	新 IM	只读查询、历史归档	关键群重建，旧账号收口
外部协作必须用旧系统	新 IM 负责内部	旧系统仅外部通道	外部联系人单独管理

这张表可以用来和业务部门对齐，避免 IT 单方面决定。

3. 用兼容矩阵约束升级顺序

如果同时涉及服务端升级和客户端更换，顺序不能乱。比较稳的顺序是：服务端升级、消息中转服务确认、试点客户端验证、分批扩大范围。数据库变更单独安排，不要和客户端分发挤在同一天。

升级前要拿到兼容矩阵，至少确认：服务端与客户端版本组合、旧客户端支持周期、群聊和历史消息是否正常、文件与离线消息是否受影响。

试点时重点看新旧客户端能不能互发消息、群聊是否正常、历史消息能否加载。任何一项不通过，都不要扩大范围。

四、客户端分发与验收：按批次装，不按“全员通知”装

客户端迁移验收看起来是体力活，实际上最容易出问题。全员群发一个安装包，第二天就会收到几十条“装不上”“登录不了”“文件打不开”。

1. 试点部门要能代表真实终端

试点不要只选 IT 部门。IT 的机器通常配置高、网络好、权限全，不能代表普通业务部门。

试点至少覆盖三类角色：日常沟通频繁的部门、使用外部协作的部门、有公用终端或轮班制的岗位。终端类型尽量覆盖 ARM、x86、LoongArch；如果单位有申威终端，也要单独验证。

试点时间要跨过一个完整业务周期，比如周会、报表、月末结算。只测半小时聊天，说明不了高峰期的表现。

2. 安装包、依赖和权限一次准备齐

安装前把四件事准备好：对应架构的安装包、离线依赖、安装权限、内网下载入口。

Linux 客户端常见 deb、rpm、tar.gz 三种包。deb 系用 dpkg 或 apt，rpm 系用 rpm 或 dnf，tar.gz 适合手动放置或排查依赖。纯内网环境要提前准备本地源或离线依赖包，不能等到现场再找。

喧喧IM 后台可以按需生成客户端下载链接，管理员也可以把安装包放到内网共享盘；具体安装步骤可以查 安装升级手册。这样做的好处是版本统一，用户不用去外面找包。

普通用户没有安装权限时，由管理员统一分发或提权安装。不要把权限问题当成兼容问题，也不要用其他架构的包硬装。

安装包、依赖、权限、下载入口，四件事缺一件都会变成现场故障。

3. 验收按文字、文件、离线、多端四项走

客户端能启动，不等于可以用。信创环境里的验收，至少覆盖四项。

验收项	通过标准	失败信号
文字消息	双端到达，顺序、时间戳、换行正常；群聊和检索可用	延迟明显、乱序、乱码、部分账号收不到
文件消息	上传、下载、打开、内容完整；重要文件可比对大小或哈希	进度卡住、文件损坏、无法下载
离线消息	退出或断网后发送，重新登录能补齐，顺序正确	消息丢失、重复、文件失效
多端同步	PC 与移动端状态一致，历史记录能加载	一端收不到、历史不同步

如果使用开源版，先确认当前版本是否包含文件传输能力；把版本能力差异当成终端兼容问题，会浪费很多时间。

加密配置不能靠客户端界面判断。客户端能登录、消息能到达，不等于传输加密和服务端存储配置正确；加密要看服务端配置和部署文档。

验收记录至少写清终端型号、CPU 架构、系统版本、客户端版本、安装包名、报错原文和操作时间。给厂商提问题时，这些信息比一张截图有用。更细的终端安装和登录排查，可以参考喧喧IM的 信创环境 IM 实测，里面按 ARM、x86、LoongArch 三类终端给了步骤和记录表。

验收通过的标准是可观察的结果，不是“看起来能用了”。

五、账号、组织与群组：并行期最容易出现“两套通讯录”

并行期最常见的抱怨，是通讯录对不上：新系统里少了人，旧系统里多了离职账号，群主换人后没人知道。

1. 组织架构只维护一份源头

组织架构要以 HR 系统或 LDAP/AD 为源头，新系统从源头同步，旧系统逐步停止手工维护。同步规则要写清：新增、转岗、离职、返聘、外包、借调分别怎么处理。

如果单位已经有 LDAP 或 AD，可以用它做统一认证和用户同步。喧喧IM 专业版提供 LDAP 认证，能把账号入口收敛到目录服务；开源版和专业版的功能范围不同，采购前要核对版本。

管理员角色也要收敛。并行期可能需要临时管理员，但要有名单、权限范围和撤销时间。项目结束后不撤销，临时权限就会变成长期风险。

通讯录只能有一个源头，另一个系统最多做只读同步。

2. 群组迁移按必要性分级

群组迁移不是把旧群列表复制一遍。先按业务重要性分级，再决定重建、归档还是解散。

必须重建的群，优先处理跨部门、项目、外部协作和业务通知。重建时把群名、群主、成员、公告和重要文件一次定好，避免建完再改。

群名建议带部门或项目标识，减少重名。群主离职的，先指定接手人。重要文件不要只放在群文件里，复制到文档协同或文件服务器，避免换系统后链接失效。

旧群不要长期保留写入权限。发布迁移通知后，把旧群设为只读，明确最后期限。两个群同时可写，员工就会两边都发。

3. 外部联系人和跨单位沟通单独定规则

外部联系人往往不在本单位的组织架构里，迁移难度比内部账号高。先确认新系统是否支持外部联系人、是否需要单独授权、是否允许跨组织可见。

如果外部协作必须继续用旧系统，就把旧系统限定为外部通道，内部沟通全部走新系统。不要让外部联系人顺手进入内部群，也不要把内部文件发到外部通道。

组织隔离、外部联系人审批、群邀请权限，都要在并行期就定好。等出了问题再补规则，成本更高。

内部和外部两条通道要分开管，不能因为并行期就混在一起。

六、历史数据、安全与旧账号：并行期不是“先放着”

很多项目把旧系统当成“先放着”的过渡，结果旧账号、旧群和旧文件一直有人用。旧系统只要还能登录，它就是一个数据出口，也是一个管理盲区。

1. 历史消息和文件先分三类

历史数据不要默认全量迁移。先分三类：需要迁移的、需要归档的、可以按制度放弃的。

需要迁移的，通常是仍在进行的项目、未结案的审批、需要频繁查询的会话。迁移前确认旧系统能导出什么格式、新系统能导入什么格式，以及消息顺序、附件、权限关系能不能保留。

需要归档的，保留只读查询能力，明确保留期限和查询责任人。可以放弃的，按单位的数据留存制度处理，不要个人随意删除。

群组关系、回复关系、文件链接和搜索索引，未必能原样重建。不要把“聊天记录全量搬迁”写成上线前提，否则项目很容易卡在历史数据上。重要文件单独复制到文档协同或文件服务器，不要只依赖聊天记录里的附件链接。这样即使旧系统下线，文件还能找到。

历史数据的目标是“该留的查得到”，不是“所有消息都搬过去”。

2. 旧账号和旧客户端要有收口时间表

旧系统还在运行，就要有收口时间表。离职、转岗、外包离场、长期不用的账号，先停用；旧客户端从新终端上移除；旧系统的登录入口逐步限制。

如果旧系统必须保留一段时间，至少做三件事：限制登录来源 IP、关闭不必要的写入权限、定期检查异常登录。喧喧IM 的 通讯安全页面列出 IP 登录限制、组织隔离、界面水印等能力；专业版还提供 LDAP 认证、数据库消息加密存储、服务端文件加密存储等。传输侧是通信全加密，消息在数据库中加密存储，服务端文件加密存储。具体能力以版本和部署配置为准。

这些措施不能互相替代。IP 限制解决登录来源，水印解决截屏溯源，加密解决传输和存储，权限解决谁能做什么。并行期要按风险组合使用。

旧账号不收口，旧系统就会继续产生新的数据出口。

3. 权限和审计按最小必要收敛

并行期容易出现临时权限膨胀：为了方便，给一批人开了管理员；为了迁移，给一些人开了导出；为了测试，拉了很多外部联系人。项目结束后，这些权限往往没人回收。

建议在建项目时就列一张权限表：谁能创建群、谁能邀请外部联系人、谁能导出文件、谁能查看审计记录、谁能停用账号。每项权限对应一个负责人和撤销时间。

数据流转也要有规则。新系统里的文件不要随手回传到旧系统；敏感消息不要因为旧系统还能用就继续发。旧系统的访问日志定期看，发现异常登录及时处理。审计和追溯能力要在并行期就打开，不要等旧系统下线前才补。

七、切换与退出：什么时候可以关掉旧客户端

什么时候可以关掉旧客户端？这个问题不该由某个人拍板，而应该由一张验收表决定。

1. 用验收表决定是否进入只读期

进入只读期前，至少确认：在用终端完成安装，关键部门没有遗漏；关键群完成重建，成员和群主确认；文字、文件、离线消息、多端同步验收通过；账号和组织架构同步完成；历史数据完成迁移或归档；试点问题关闭，回退方案演练过。

这些条件满足后，先把旧系统设为只读，保留查询能力，再观察一段时间。观察期内重点看三件事：有没有人还在旧系统发起新话题、关键文件能不能在新系统找到、离职和转岗账号有没有及时停用。

观察期多长，按业务周期决定。跨过月末、季度结或年度审计再关闭，比固定天数稳妥。

旧系统从“可写”改为“只读”，是并行期最关键的一步。

2. 回退方案要能执行，不是写在文档里

回退不是把旧系统重新打开那么简单。账号还在不在、权限有没有变、数据能不能对上、客户端还能不能登录，都要提前验证。

试点阶段保留旧终端和旧客户端，保留旧系统备份，明确回退触发条件和决策人。切换前做一次回退演练：停用新客户端，用旧账号登录旧系统，确认关键群、文件和消息还能查。

回退方案要写清谁有权决定回退、回退后新系统里的消息怎么处理、回退期间对外怎么通知。没有演练过的回退方案，只能算愿望。

回退方案的价值在于演练过，不在于写得多完整。

3. 退出后的收尾

旧系统关闭后，还有几件事要收尾：停用旧账号、回收许可、归档数据、更新资产台账、修改新员工入职和离职流程、整理常见问题。

并行期暴露的问题也要复盘：哪些终端问题最多、哪些群迁移最困难、哪些部门培训不到位、厂商响应是否及时。这些记录会直接影响下一次系统升级。

如果单位还在选型阶段，把版本、适配范围、迁移责任、回退支持和培训写进验收表，比只看功能清单更有用。喧喧IM 的信创适配、私有化部署和通讯安全页面可以作为核对材料，但最终要用本单位真实终端做验证。

八、FAQ

1. 并行期一般要多久？

没有统一天数。终端到货、部门批次、试点结果、问题关闭速度都会影响时长。用退出条件管理，比定一个固定日期可靠。

2. 旧客户端还能登录新服务器吗？

取决于产品版本和兼容矩阵。先查官方文档，再用真实终端测试登录、群聊、文件、离线消息。不能假设旧客户端一定兼容新服务端。

3. 历史聊天记录能完整迁移吗？

不保证。先确认旧系统能导出什么、新系统能导入什么；群组关系、回复关系、文件链接和搜索索引未必能原样保留。无法迁移的内容，安排只读归档和查询方式。

4. 新旧系统能互相发消息吗？

只有在厂商提供互通或适配能力时才可以。没有互通能力时，只能人工转达，这时要指定转达人、统一模板，并规定同一件事只在主系统留记录。

5. 只换国产电脑，不换 IM，也要并行期吗？

需要。终端操作系统和 CPU 架构变了，客户端要重新适配和验收。如果同一套服务端支持新旧终端，管理会简单很多，但仍然要做试点、安装和四项验收。

并行期管理说到底，是把“换软件”拆成一组可检查的动作：终端有清单，账号有源头，群组有分级，数据有去向，权限有回收，退出有标准。

如果现在就要启动，先做三件事：列出终端架构清单，确定主系统，写出退出条件。这三件事定了，后面的安装、迁移和培训才有依据。

产品信息核对说明：本文涉及的喧喧IM能力，核对自其官网信创、私有化部署、通讯安全、版本与安装文档页面，核对时间为2026年10月。具体版本、适配范围和功能以实际部署文档为准。