并购后两套 IM 怎么合并：组织、账号与资料的处理顺序

并购后两套 IM 怎么合并，难点通常不在把聊天记录导过去，而在顺序。组织边界没定，账号就会重复；账号没统一，群主、权限和审计就落不到人；资料没分级，迁移就会变成把旧系统的历史包袱整体搬进新系统。更稳妥的顺序是，先定主系统和合并边界，再并组织，随后并账号，处理群组关系，最后迁移消息、文件和权限，重建集成并切换。这里的资料不只是聊天记录和文件，还包括群组关系、权限、审计记录、机器人和集成配置。群组关系依赖账号，所以放在账号之后、文件和消息之前。

这篇文章面向正在做并购整合的 IT 和信息化负责人，讨论两套企业 IM 合并时组织、账号与资料的处理顺序。具体厂商的迁移工具和交付范围差异很大，文中给的是可执行的判断框架和验收方法，不替代厂商实施文档。

顺序	先做什么	主要产出
1	定主系统与合并边界	合并模式、范围清单、决策记录
2	并组织架构	组织树、部门编码、负责人和管理员
3	并账号身份	账号映射表、权限和账号类型
4	理群组关系	群组台账、群主和处置结论
5	迁资料	资料分级、迁移清单、归档记录
6	重建集成	机器人、Webhook、单点登录清单
7	切换验收	验收表、只读期、回退预案

先定主系统与合并边界

两套 IM 合并，第一步不是选一个功能更多的系统，而是确定哪套系统承担主目录、主账号和主数据。主系统通常要满足几个条件，覆盖大多数员工、承载关键业务群、能承接现有身份源、具备必要的审计和权限能力、团队有运维能力。功能清单只能作为参考，不能替代这些条件。

常见有三种合并模式。

• 单主系统：一套保留为主系统，另一套在过渡期后停用。长期管理成本低，但迁移工作集中，适合业务重叠度高、监管要求允许统一管理的组织。
• 双系统共存：两套都保留，通过目录同步、消息互通或统一入口连接。适合被收购方需要保留独立品牌、独立法人或不同合规边界的组织，但运维和体验一致性成本更高。
• 保持隔离：只在通讯录、审批或特定项目上做有限连接，不合并账号和资料。适合涉密、跨境、强监管或业务独立的场景。

先写清五条原则，再开始动数据。 统一权威组织源，以 HR 系统、AD/LDAP 或集团主数据为准，避免两套通讯录各自维护。 单一账号主键，工号、邮箱或手机号选一个作为主键，其他字段只做辅助匹配。 资料分级，先分一般、重要、敏感，再决定迁移、归档、重建还是放弃。 旧系统只读期，停用前保留一段可查询的时间，避免历史消息和文件突然消失。 回退条件，写清什么情况下暂停切换、由谁决定、如何恢复旧系统。

如果目标系统是私有化 IM，例如喧喧IM，数据留在企业自己的服务器上，部署方式和网络要求会影响合并方案，可以先核对 私有化部署的边界。这里要提醒一句，私有化解决的是数据存放位置，不自动等于数据可以一键搬走，后面的资料迁移仍要单独设计。

第一步，合并组织架构

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

先画一张正式组织树，至少包含法人、事业部、部门、岗位四级。被收购方如果保留独立法人，不要在通讯录里直接抹平，可以在集团树下保留独立节点，再决定哪些层级对集团可见。项目组、专项组和临时协作关系不要写进正式组织树，它们应该放在群组或项目空间里，否则组织树会随着项目变化反复调整。

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

权限边界要在组织合并时一起定。总部管理员能管哪些单位，子公司管理员能管哪些部门，跨公司通讯录是否可见，外部联系人由谁审批，这些规则如果等到账号建完再补，往往要返工。组织隔离能力比较强的系统，可以把不同组织的通讯录、会话和会议分开管理；具体能力边界要看版本和部署配置，不能默认所有版本都一样。

组织合并的成功信号不是部门建好了，而是三件事对得上。组织树层级和 HR 主数据一致，部门负责人和管理员落到具体的人，跨组织可见范围经过抽样确认。如果这三件事还有空白，不要进入账号批量创建。

第二步，合并账号与身份

账号合并的目标是一个人一个主账号，不是把两张表拼在一起。账号背后挂着登录、群主身份、文件权限、审批记录和审计日志，错一个，后面会连着错。

先建账号映射表。至少包含源账号 ID、目标账号 ID、工号、姓名、部门、岗位、账号类型、状态、冲突处理和负责人。主键优先选工号或企业邮箱，手机号可以作为辅助，但不要用它做唯一依据，员工换号或共享号码都会带来麻烦。

几类账号要单独处理。

• 重名账号：用组织编码加主键区分，不要用姓名加数字临时凑。
• 兼职和返聘：明确主部门、主账号和额外权限，避免一人多号或权限叠加。
• 离职和停用账号：先冻结、回收权限、移交群主和文件，再决定是否删除；不要直接删除后留下无主群组。
• 外包和外部账号：单独标记类型、有效期和审批人，不放进内部员工目录。
• 服务账号和机器人：单独台账，记录用途、负责人和调用范围，不要挂在个人账号下。

身份源尽量统一到 HR 系统、AD/LDAP 或集团统一身份平台。能自动同步的，不要长期靠 Excel 手工维护；不能自动同步的例外账号，要走审批和定期复核。LDAP/AD 同步能减少入职、离职、调岗的重复操作，但同步深度、字段范围和版本支持要以实际部署为准。喧喧IM可以通过 LDAP/AD 承接已有账号体系，相关认证与组织隔离能力可以参考 通讯安全页面的说明。

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

第三步，处理群组与成员关系

群组是 IM 合并里很容易被低估的部分。账号建完不代表群能用，群主、管理员、成员、外部联系人和文件权限，都要在新系统里重新落一遍。

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

处置结论通常有四类。

• 迁移：业务跨切换日继续，成员和文件还要用。重建群关系，迁移关键文件，按角色重设权限。
• 归档：项目结束或业务不再活跃，但有合同、审计或知识留存义务。旧系统设只读或导出归档，登记保管人和期限。
• 重建：群结构、外部成员或集成需要调整。在新系统新建群，重新审批成员，重要文件重新归位。
• 放弃：临时群、重复群、无业务价值的文件。由负责人确认后解散或清理。

同名群和重复群要在这一步合并。同一项目、同一客户、同一部门保留一个主群，其余群发迁移说明后归档或解散。不要一次性全解散，先设只读，给文件移交留时间。群主离职或调岗的群优先处理，先补备份管理员，再变更群主，最后移交文件。外部客户群建议重建，不直接沿用，重新确认外部成员身份、入群审批和文件权限。

群和文件的详细盘点字段、处置规则和交接方法，可以参考 企业内部沟通平台切换前，哪些群和文件需要先盘点，那篇把群组台账和文件台账拆得更细，这里不重复展开。

第四步，迁移资料

资料迁移要先分级，再决定搬多少。把所有历史消息和过期文件都搬过去，成本高，价值未必大；只搬账号不搬关键资料，业务又会断。比较稳妥的做法是按对象分别定策略。

资料类型	建议策略	关键动作
账号与组织架构	全量迁移	以 HR/AD/LDAP 为主数据，建立映射表
群组与成员关系	按需迁移	按业务价值筛选，重建群主、管理员和外部成员
历史消息	关键群、关键时间段	先评估导出格式、保留义务和检索需求
文件与附件	主副本优先	确定现行版本，迁移文件并保留消息引用关系
权限与审计	重建	按角色重设可见范围，保留必要的审计记录
机器人与集成	重新配置	对照旧系统清单逐项重建和联调

聊天记录要单独评估。很多企业以为导出就是迁移，实际不是。导出可能拿到的是归档包、JSON、文本或数据库备份，目标系统能不能读、能不能还原成会话、能不能保留附件和引用关系，是另一回事。Slack 官方帮助中心说明，常规数据导出通常包含的是文件链接而不是文件本身，部分历史数据还会受留存策略限制；企业级合规导出则依赖单独的接口和授权。微软的 Microsoft 365 租户到租户迁移文档也明确提到，Teams 内容依赖 Exchange 邮箱，邮箱要在 Teams 之前或同时迁移，分阶段迁移还要规划共存期的邮件路由、日历忙闲和 Teams 联合身份验证。这些例子说明，聊天记录迁移不是单点动作，而是和账号、邮箱、文件、权限绑在一起的工程。

如果目标系统是喧喧IM，需要提前知道一个边界，喧喧IM目前不支持把聊天记录一键导出为加密或明文格式，迁移通常要结合原平台的导出格式做备份、清洗和映射。这不是一句能不能导的问题，而是导出后能不能还原成可用会话的问题。更完整的迁移边界和资产分层，可以参考 私有化IM的数据迁移边界。

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

迁移过程建议按备份、导出、清洗、映射、试迁、抽样验证、分批放大推进。备份要做恢复验证，只备份不验证等于没有备份。先选一个部门或一个项目试迁，抽样检查消息可检索、文件可打开、权限正确，再扩大范围。旧系统保留一段只读期，具体时长按数据量和合规要求定，确认新系统稳定后再停。

第五步，重建集成与切换入口

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

先把旧系统的集成清单拉出来，逐项记录用途、调用方、接收方、负责人和触发条件。机器人、Webhook、审批提醒、监控告警、OA/ERP 通知、单点登录，分别在新系统重建并测试。接口协议和目标系统不同，移植往往比重建更麻烦，不要假设旧配置能直接复制。每重建一项，就用真实业务场景跑一遍，确认消息能到正确的人、正确的群，失败时有告警。

切换入口也要一起设计。客户端怎么安装，登录地址是否变化，移动端是否要重新配置，旧入口什么时候关闭，这些都要提前公告。可以先选一两个部门试点，跑通发消息、建群、传文件、开会、@人、机器人通知等真实流程，再逐步放大。切换窗口尽量避开重大项目交付、月末结算和业务高峰。

回退预案要在切换前写好，不是出问题后再讨论。至少写清触发条件、恢复步骤、数据回滚范围、负责人和沟通方式。旧系统保留只读期，备份保持可用，回退路径要实际演练过。切换策略和回退清单可以参考 从SaaS迁移到私有化IM的完整指南，里面对直接切换、并行运行和分阶段灰度三种方式有更细的比较。

验收与回退，用五项检查确认没有断链

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

检查项	通过标准	建议负责人
数量核对	账号数、部门层级、群数量、群成员数、文件数与清单一致	IT 管理员
完整性抽查	抽 10% 的群，核对群主、管理员、成员和外部成员	业务负责人
权限检查	不同角色登录后，可见范围正确，敏感文件没有多余访问口	安全/IT
可检索	关键决策、合同编号、项目名称能在新系统找到对应消息或文件	业务负责人
业务连续性	试点部门跑通通知、传文件、开会、@人和机器人推送	项目经理

五项都过，才进入全面切换。旧系统保留一段时间只读，用于核对历史消息、文件和权限；确认新系统稳定、备份可恢复、回退路径可用后，再安排下线。下线前要确认数据归档位置、保管人、保留期限和删除方式，不要只保留一份备份。

不能合并的情况，保留两套也是一种答案

并不是所有并购都适合把 IM 合成一套。涉及涉密网络、跨境数据、强监管业务，或者被收购方需要保留独立品牌和独立法人时，强行合并可能带来合规风险和管理混乱。这时更合理的目标是可控连接，不是统一到一套。

保留两套时，至少把边界写清楚。哪套是员工日常沟通的主入口，通讯录是否互查，跨系统消息是否互通，哪些群允许跨组织协作，外部联系人由谁审批，审计记录各自保留多久。可以只做目录同步、统一登录或特定项目群的连接，不必合并全部账号和资料。双系统共存会增加运维和培训成本，这个成本要在决策时算进去，不能只看迁移当期的工作量。

常见问题

先迁账号还是先迁组织？

先定组织边界和权威组织源，再迁账号。账号是组织关系的属性，组织没定清楚就建账号，后面会出现部门归属错误、重名和管理员权限错配。组织树、部门编码和负责人确认后，账号映射才有稳定依据。

聊天记录要不要全部迁移？

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

两套 IM 能长期并存吗？

可以，但要明确主系统和连接边界。长期并存适合业务独立、合规边界不同或整合过渡期较长的组织。需要提前设计目录同步、消息互通、外部联系人审批和审计归属，否则会出现两套通讯录、两套群、两套权限，员工不知道该看哪边。

旧系统什么时候停？

验收通过、关键业务跑通、备份可恢复、回退预案准备好之后再停。停用前保留一段只读期，让员工查历史消息和文件。具体时长按数据量、合规要求和业务连续性定，不要为了赶进度提前关闭。

外部客户群怎么处理？

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

没有专职迁移团队怎么做？

先缩小范围，选一个部门或一个项目做样板，把组织、账号、群组、资料、集成和验收跑一遍，再复制到其他单位。每项工作指定负责人和备份，清单、验收标准和回退条件写成文档。不要一开始就全公司铺开，问题会在业务繁忙的时候集中出现。

参考来源

• Microsoft Learn，《Microsoft 365 迁移概述》，查阅于2026年11月，https://learn.microsoft.com/zh-cn/microsoft-365/migration/microsoft-365-migration-overview?view=o365-21vianet
• Microsoft Learn，《Microsoft 365 个租户到租户迁移》，查阅于2026年11月，https://learn.microsoft.com/zh-cn/microsoft-365/migration/microsoft-365-tenant-to-tenant-migrations?view=o365-worldwide
• Slack Help Center，《Slack 导入和导出工具指南》，查阅于2026年11月，https://slack.com/intl/zh-cn/help/articles/204897248-Slack-%E5%AF%BC%E5%85%A5%E5%92%8C%E5%AF%BC%E5%87%BA%E5%B7%A5%E5%85%B7%E6%8C%87%E5%8D%97
• 喧喧IM，《私有化IM的数据迁移边界》，查阅于2026年11月，https://www.xuanim.com/column/private-im-data-migration-boundaries-cuv-InstantMessaging
• 喧喧IM，《企业内部沟通平台切换前，哪些群和文件需要先盘点》，查阅于2026年11月，https://www.xuanim.com/column/internal-communication-platform-switch-groups-files-audit-d7d-guides