从旧平台迁移到新系统，通讯录映射和群关系怎样核对

通讯录映射和群关系核对，目标不是把两个系统的总数对上，而是证明每个账号、每条群成员关系都能从旧系统追到新系统，并且在新系统里还能正常使用。这里说的群关系，包括群主、管理员、普通成员、外部成员，以及群和文件权限的对应关系。

比较稳的顺序是四层：先定对账口径，再核通讯录，再核群关系，最后用差异清单和真实动作签收。只做第一层，后面很容易返工。

一、先定核对口径

核对开始前，先回答三个问题：以哪套系统为主数据，以哪个时间点为准，什么算迁移成功。这里的成功，至少包括账号能登录、组织归属正确、群成员关系完整、关键权限没有扩大。三个问题没定，后面的数字会一直变。

1. 锁定权威源和时点

账号和组织架构的权威源通常是HR系统、AD/LDAP或集团主数据，不是旧IM后台。旧IM里的部门可能是多年前手工建的，直接拿它当标准，会把历史错误一起搬过去。

对账时点要固定。选一个业务低峰时刻作为T0，导出源端快照；从T0到切换完成之间发生的人员入转调离，单独记增量。否则一边迁一边变，总数永远对不上。做不到停写，至少记录变更清单，并在验收前再跑一次增量核对。

如果新系统支持LDAP/AD同步，账号和组织架构可以由目录服务承接；但同步通常只解决账号和组织结构，不自动迁移群主、群成员和文件权限。以喧喧IM为例，其 通讯安全页面说明支持LDAP认证与信息同步，LDAP/AD集成属于专业版能力，具体同步深度和字段范围以所选版本和部署配置为准。

2. 建账号映射表

映射表是整篇核对的主线。字段不用多，但每一列都要能追责。

字段	用途
源账号ID	旧系统里的唯一标识
目标账号ID	新系统创建后的唯一标识
主键类型与值	工号、企业邮箱或目录唯一标识
姓名	辅助识别，不参与唯一判断
源部门与目标部门	核对组织归属
账号类型	正式、兼职、外包、服务账号
账号状态	启用、停用、待激活
映射结果	已映射、冲突、批准不迁、待处理
冲突类型	重名、重复、缺失、字段不一致
负责人与证据	谁处理、依据是什么

映射结果只用固定状态，不要写“差不多”“已处理”这类无法统计的描述。状态越清楚，后面越容易查出哪一类问题还没有关闭。

主键优先选工号、企业邮箱或目录服务里的稳定唯一标识。姓名不能做主键，重名很常见；手机号也不适合单独做主键，换号、共享号码、离职回收都会让映射断掉。

迁移工具能把账号搬过去，不代表身份关系已经建好。微软在Microsoft 365租户迁移文档中说明，这类迁移移动的是内容，不是标识，用户仍要单独创建和配置。IM迁移同理，账号、群主、权限这些身份关系要单独核对。

3. 群关系单独建账

群不能只靠群名管理。重名群、同名项目群很多， 群名相同不代表是同一个群。源系统有群ID就用群ID；没有就至少用群名、群主、创建时间三个字段组合定位。

群台账至少记录：源群ID、目标群ID、群名称、群类型、源群主、目标群主、源成员数、目标成员数、外部成员数、处置结论、核对人。群主、管理员、成员都写成账号ID，和账号映射表互相引用。

群台账不是成员名单的另一个副本。它要回答的是，这个群切换后还要不要用，谁负责，成员关系以哪张表为准。

4. 先做一个部门试迁

不要一上来全量。选一个部门或一个项目群，把账号、部门、群主、成员、外部成员、文件权限完整跑一遍。试迁的目的不是看系统能不能启动，而是看映射表、群台账和差异清单能不能闭环。

如果新系统提供迁移工具，先用它跑通账号和组织；没有工具，就用导出表加API或手工建。工具不同，核对方法不变。

试迁通过后，再按部门或法人分批放大。每批都用同一套口径，不要一批一个标准。具体排期可以参照 从SaaS迁移到私有化IM的完整指南。

二、通讯录映射核对

通讯录核对分三层：数量、字段、可用性。三层都过，才算账号真的迁好。

1. 四类数量先对上

源端应迁账号、目标端成功账号、批准不迁账号、待处理差异，四类要能对上。在同一个对账时点内，一个可用的平衡式是：

源有效账号=目标启用账号+批准不迁账号+待处理差异账号

右边的待处理差异必须是0，或者每一项都有负责人和期限，才能进入下一层。

成功账号不是导入没报错，而是目标账号存在、状态正确、能登录。导入日志显示成功，但账号被禁用、部门为空、登录名为空，都不能算成功。

2. 按维度拆开对

总数相等不代表没有错位。举例，源端A部门少2人，目标端B部门多2人，总数仍然一样。要把总数拆成几个维度分别对：法人或单位、部门层级、账号类型、账号状态。

部门层级至少核对三项：部门数量、上级部门关系、部门负责人。只对部门名称不够，重名部门要用部门编码区分。

账号类型要分开：正式员工、兼职或返聘、外包或外部、服务账号或机器人。不同类型的主键、有效期和权限规则不同，混在一个总数里看不出问题。

3. 字段差异逐项过

字段核对不是把所有字段都比一遍，而是先定哪些字段会影响登录、组织和权限。通常包括账号主键、姓名、部门、岗位、手机号、邮箱、账号状态、账号类型。

比对前先做归一化：去空格、统一大小写、统一手机号格式。否则会把格式差异当成数据错误。

差异分五类：缺失、重复、错配、空值、状态错误。每一类都要有处理规则。重名账号用部门编码加工号区分；兼职和返聘明确主部门、主账号；离职账号先冻结、移交群主和文件，再决定是否删除；外包账号单独标记有效期和审批人；服务账号单独台账，不挂在个人账号下。

部门重名、人员归属错位这类问题， 组织调整后通讯录对不上的处理顺序里有更细的分类，可以直接拿来做差异类型。

LDAP/AD同步还要看唯一标识。优先用不会随姓名、手机号变化的属性，比如员工号或目录对象唯一标识；用sAMAccountName时要注意改名和多域重名，必要时加域前缀。同步规则是覆盖还是仅新增，也要在试迁前定好，避免把手工调整冲掉。

4. 登录和可见范围

最后让账号真正登录一次。至少覆盖三类人：全部管理员、全部差异账号、每个部门随机抽样的普通账号。测试内容不只是能不能进，还包括组织架构是否可见、部门对不对、管理员菜单是否越权、停用账号是否确实登不上。

抽样不要只抽看起来正常的账号。差异账号、离职账号、外部账号、服务账号必须全量看。业务负责人要确认自己部门的人都在，不能只由IT点一遍。登录日志、权限截图和业务负责人的确认记录要留档，后面签收时用得上。

三、群关系核对

群关系比通讯录更容易漏。账号建完，群可能还没建；群建完，群主、管理员、外部成员和文件权限可能还是错的。

1. 群台账对上账号

先给每个群一个处置结论：迁移、重建、归档、放弃。迁移和重建的群才进入核对范围，归档和放弃的群单独登记保管人。

群主是离职或调岗人员的群，标为高风险。先补备份管理员，再变更群主，最后移交文件。不要先把人停用，再去找群主。群台账字段和处置规则，可以参考 企业内部沟通平台切换前，哪些群和文件需要先盘点。

2. 用集合差查错配

成员核对不要只比人数。正确做法是按账号ID做集合比对：

• 源群成员集合减去目标群成员集合，得到缺失成员；
• 目标群成员集合减去源群成员集合，得到多出成员；
• 同一账号在两边的角色不一致，单独列为角色错配。

账号映射错了，群成员比对一定错。所以群成员核对要放在账号核对通过之后。

成员数量要按角色拆开：群主、管理员、普通成员、外部成员、机器人。一个群的总人数一样，但群主换了、管理员少了一个、外部成员多了一个，仍然是没迁对。

3. 群主和管理员单核

群主应当是目标系统里的在职内部账号，至少不能是已停用账号。管理员按职责设置，不要沿用旧系统的高权限账号。外部成员要重新确认身份、审批和有效期，不要因为旧群里有就直接带过来。

群类型也要核。内部群、外部群、部门群、项目群的成员规则和文件权限不同。只看群名容易把外部群当内部群，把项目群当部门群。

权限至少检查四件事：谁能邀请成员、谁能修改群名和公告、谁能上传或删除文件、谁能@所有人。用群主、管理员、普通成员、外部成员四种角色分别登录测试。

4. 用真实动作验证

静态名单对完，再做一轮真实动作：发一条消息、@一个成员、上传一个文件、搜索一条历史消息、转让一次群主、让外部成员尝试访问不该看的文件。每一步都记录预期结果和实际结果。

群消息和文件能否检索、文件权限是否跟着群走，往往在名单里看不出来。关键群要实际打开文件，不要只看文件数量。

如果新系统支持群成员列表、添加或移除成员、修改群名、解散或退出群组，这些动作都可以作为验收用例；具体入口以所选版本和客户端为准。

四、差异收口与验收

核对发现差异不是失败，差异没人处理才是。把差异清单当成项目交付物，逐项关闭。

1. 差异要有责任人

每条差异至少记录：差异编号、对象类型、源值、目标值、影响、严重级别、责任人、期限、处理结果、证据。

严重级别可以分三档：

• P1：影响业务或安全，比如群主缺失、管理员权限错误、外部成员能看到敏感文件；
• P2：影响协作，但有临时替代办法，比如个别成员没进群、部门显示错误；
• P3：显示或格式问题，不影响使用。

P1必须清零，P2要有明确处理计划，P3可以排期。

不要把所有差异都扔给IT。账号归属找HR或部门负责人，群主和成员找群主或业务负责人，权限找安全或系统管理员。

2. 验收看证据

验收至少留五类证据：数量对账表、字段差异报告、群成员比对结果、角色权限测试记录、业务负责人签收。

抽样规则建议：全部管理员、全部差异账号、全部高风险群，加上每个部门或每类群至少10%的随机样本。10%是下限，不是固定标准；关键群可以全量。

每份证据要带对账时点和数据版本。改完再跑一遍同样的查询，不能只凭已经修了就关闭差异。

3. 回退和只读期

切换前写清回退条件：哪些P1差异出现时暂停切换，由谁决定，旧系统如何恢复，恢复后新增数据怎么补。回退演练要在切换前实际做一次，不能只写在方案里。

旧系统不要急着删。保留一段只读期，让员工能查历史消息和文件；备份要做恢复验证，只备份不验证不算有备份。确认新系统稳定、差异闭合、回退路径可用后，再安排下线。

五、常见问题

只核对账号总数行不行

不够。总数只能发现大批量漏迁，发现不了部门错位、角色错误和重复账号。至少还要按部门、账号类型、状态拆开对，再做字段和登录验证。

手机号能当唯一主键吗

不建议单独用。员工换号、共享号码、离职回收都会让映射断掉。优先用工号、企业邮箱或目录服务的稳定唯一标识，手机号只做辅助匹配。

群成员数量一致就够吗

不够。人数一致只能说明数量对，不能说明人对。缺一个内部成员、多一个外部成员，人数可能刚好相同。按账号ID做集合比对，再核对群主、管理员和外部成员角色，才能发现错配。

离职员工的群怎么处理

先补备份管理员，再把群主变更到在职负责人，移交群文件和成员名单，最后停用账号。不要先停账号再找群主，否则群会变成无主群，文件也没人能移交。

聊天记录要不要核对

聊天记录是另一条线，不要和通讯录、群关系混在一个验收里。先定保留范围和目标系统能否还原，再决定迁哪些群、哪些时间段。喧喧IM目前不支持把聊天记录一键导出为加密或明文格式，迁移通常要结合原平台的导出格式做备份、清洗和映射；具体边界可以参考 私有化IM的数据迁移边界。

参考资料

• Microsoft Learn，《Microsoft 365中使用业务流程协调程序进行租户到租户迁移概述》，查阅于2026年11月5日，https://learn.microsoft.com/zh-cn/microsoft-365/migration/migration-orchestrator-1-overview?view=o365-worldwide
• 喧喧IM，《通讯安全》，查阅于2026年11月5日，https://www.xuanim.com/product/communication-security
• 喧喧IM，《即时聊天》，查阅于2026年11月5日，https://www.xuanim.com/product/live-chat