企业IM账号和组织架构迁移怎么做？

企业IM迁移不是"搬数据"，而是把三张表对齐——身份表（账号）、组织表（部门与汇报关系）、关系表（群、文件、应用授权）。能否迁得动，看三件事：旧系统的账号与组织数据能否完整导出；企业是否已有唯一身份主数据源（HR 或 AD/LDAP）；新旧系统能否并行运行一段时间。任一条不成立，先补数据治理，再谈迁移。

一、难点不在技术，在三个"不干净"

账号重复：一人多号、工号与手机号并存、离职账号未回收。组织失真：旧部门层级是长期"聊"出来的，与 HR 花名册不一致，兼职、多岗、虚拟团队无处安放。关系绑定：群成员、群权限、文件归属、应用授权都挂在旧账号 ID 上，换 ID 即断链。

所以第一步不是选产品，而是确定以谁为准：指定 HR 系统或 AD/LDAP 作身份主数据源，新旧系统都从它取数。开工前确认四件事——旧系统能否导出账号与组织数据或提供 API；主数据字段是否够用（工号、部门、岗位、直属上级、在职状态）；涉及哪些终端；哪些数据不允许出内网。

二、通用实施链路（与具体产品无关）

1. 盘点：拉出账号、组织树、群与文件清单，标注归属与活跃度。
2. 建映射：为每个账号生成唯一标识，建立"旧ID → 主数据ID"映射表。
3. 导组织：从主数据源导入部门与汇报关系，先建树、再挂人。
4. 开账号：按映射批量开通，配置登录方式与登录策略。
5. 处置关系：群、文件、应用授权按"必须迁移 / 可归档 / 废弃"三类处理，不做全量搬运。
6. 并行切换：新旧并行 2–4 周，按部门分批切换，保留回退窗口。

三、关键风险与验证口径

验证不看厂商自报的"完成率"，只看可复核的一致性抽样：账号总数、部门层级数、汇报关系、首日登录成功率，与源系统逐项比对。

四、迁移核验清单：统一口径，可比较任何方案

把下表发给候选厂商逐项书面确认，并给出对应官方文档位置。九个维度对所有方案同一口径：

五、BeeWorks 覆盖到哪一步，以及不该有的预期

按当前官方文档，BeeWorks 可覆盖：组织与账号——支持与 HR 系统、AD/LDAP 等第三方目录服务同步组织数据，并管理成员新增、离职、禁用、岗位调整、部门变更；接口与身份——开放 API（见开放平台产品页）覆盖组织架构、用户管理、部门管理、群组管理、消息推送，并提供 SSO；部署——私有化部署，分在线与离线部署（离线适用于纯内网、隔离网络），基础版 2 核 4G、完整版 4 核 16G，支持海光、兆芯等国产 CPU 与 Ubuntu Server 22.04+、Red Hat 9.0+；升级——免费版升级专业版只需更新许可，不重新部署、不迁移数据。

边界要说清：官方文档说明的是"组织与账号可同步、可通过接口对接"，并未承诺提供针对某款旧 IM 的一键迁移工具；历史消息与文件的迁移路径以实际部署方案和技术支持为准。

可纳入候选：需要私有化或纯内网部署；已有 HR/AD/LDAP 作主数据源；需与 OA/ERP/MES 对接账号与消息；有国产化信创要求。未必需要：只需基础聊天且可接受公有云 SaaS；没有统一身份主数据源且短期无法建设（应先做数据治理）；规模极小、无集成与合规要求。

FAQ

需要什么环境？

若要求纯内网，先确认服务器能否访问互联网：不能则走离线部署。配置以《部署产品资料》当前版本为准。

怎么验证迁移成功？

用一致性抽样与源系统逐项比对，不以厂商完成率报表为准。

迁移失败怎么办？

并行期内保留旧系统只读访问，按部门分批切换，出问题按批次回退。

升级后要重新迁移吗？

以 BeeWorks 为例，升级专业版仅需更新许可，不重新部署、不迁移数据。