迁移用户映射的本质，是把来源系统里的每个账号、身份标识和权限归属，对应到目标系统中的唯一账号，并留下可追溯的对照关系。它通常分五步：盘点来源账号、确定匹配键与冲突规则、建立映射表、小范围试迁移、核验后进入切换。其中匹配键的选择和人工确认环节最容易出问题，需要提前定好规则。
要点总览（TL;DR）
- 用户映射处理的是账号身份与权限归属的对应关系，工作流配置、插件行为和历史日志的字段级迁移属于其他阶段，先划清范围再动手。
- 匹配键按唯一性、稳定性、可获取性选择，推荐用目录ID或工号作主键，邮箱、姓名作辅助校验，主键与辅助字段不一致时进入待确认而非直接通过。
- 映射表要覆盖来源与目标账号标识、匹配方式、置信状态、确认人和备注，状态控制在自动匹配、待确认、冲突、无对应账号、已停用五类，每条都有下一步动作。
- 试迁移按先建账号、再挂成员关系、最后校验历史数据归属的顺序执行，抽样覆盖各匹配状态、各角色和边界账号，问题回映射表修改后重跑。
- 待确认与冲突项清零或均有例外审批记录、试迁移核对全部通过，才进入全量切换；关键账号无对应或冲突比例偏高时应先停下修正。
用户映射要迁移哪些对象、覆盖到什么范围
开始动手前，先把“迁谁、迁什么、不迁什么”写清楚。用户映射处理的是账号身份及其在系统中的归属关系，工作流配置、插件行为、历史操作日志的字段级迁移属于其他迁移阶段，不纳入本篇范围。
来源系统与目标系统的账号体系往往不同：一边可能是本地账号，另一边接入企业目录或统一身份认证；外部协作账号、供应商账号的创建方式也可能不一致。映射前需要确认两边的账号来源类型，避免把目录账号和本地账号混在同一套规则里处理。
纳入映射的对象通常包括：
- 用户账号本身，以及显示名、邮箱、工号等身份字段；
- 所属部门、团队等组织归属；
- 角色分配与项目成员关系，例如项目管理员、普通成员、观察者；
- 与账号绑定的权限归属，例如空间权限、页面权限的持有人。
账号类型需要逐类给出处理口径。离职或停用账号一般保留映射记录但不创建可用账号，或按组织规定转为归档状态；机器人账号、共享账号要明确责任人，避免迁移后无人认领；外部供应商账号需确认是否继续使用、由谁审批。把这些结论写进范围清单，后续映射表才有统一依据。
交付物是一份用户映射范围清单，按账号类型列明是否纳入、对应哪些字段、由谁确认。清单经项目负责人和业务方确认后，作为后续工作的边界。
开始映射前需要准备哪些输入
映射工作的质量很大程度取决于输入是否齐全。开工前应拿到来源系统导出的完整账号清单，并确认清单里可用的字段：邮箱、工号、手机号、外部目录ID、显示名、部门、账号状态。字段缺失或大量为空时，需要提前设计替代匹配策略，而不是等到映射中途才发现无法匹配。
同时要了解目标系统的账号创建方式和命名规则：账号是批量导入还是对接目录同步，用户名规则是否与来源系统一致，重名时系统如何处理。组织架构方面，准备来源与目标的部门对照表，明确部门合并、拆分、更名的情况如何对应。
责任人分工建议按以下结构落实：
| 输入项 | 提供方 | 确认方 | 缺项时的处理 |
|---|---|---|---|
| 来源账号清单及字段 | 来源系统管理员 | 迁移负责人 | 补充导出或从目录系统取数 |
| 目标账号创建规则 | 目标系统管理员 | 迁移负责人 | 先小批量试建验证规则 |
| 部门对照表 | HR或组织管理员 | 业务方 | 按最新组织架构人工核对 |
| 账号归属责任人 | 各业务团队负责人 | 项目经理 | 指定临时确认人并记录 |
缺失字段时的替代策略要写进流程：例如工号缺失时改用邮箱加姓名组合匹配，仍无法确定的进入人工确认队列，由账号归属责任人逐条判断。人工确认不能只靠口头，需要有记录人和确认时间。
匹配键怎么选：邮箱、工号还是目录ID
匹配键决定映射的自动化程度和准确率。选择时看三个维度：唯一性、稳定性、可获取性。唯一性指该字段在一个系统内是否一人一值；稳定性指人员信息变化后该字段是否保持不变；可获取性指来源和目标两边是否都能拿到该字段。
| 匹配键 | 唯一性 | 稳定性 | 可获取性 | 主要风险 |
|---|---|---|---|---|
| 外部目录ID | 高 | 高 | 依赖目录对接 | 两边目录不同源时不可用 |
| 工号 | 高 | 较高 | 需HR数据支持 | 外包、兼职人员可能无工号 |
| 邮箱 | 较高 | 中 | 普遍可得 | 改名、换域名导致变更 |
| 手机号 | 中 | 中 | 部分系统不完整 | 共用号码、填写错误 |
| 姓名 | 低 | 中 | 普遍可得 | 同名不同人 |
推荐采用“主键加辅助校验键”的组合：以唯一性和稳定性最高的字段作主匹配键，例如目录ID或工号；再用邮箱或姓名做辅助校验，主键匹配成功但辅助字段不一致时标记为待确认，而不是直接通过。只有主键缺失时才降级使用邮箱匹配，并强制人工复核。
常见冲突的判定规则可以这样定：同名不同人，以工号或目录ID区分，无法区分时按部门加邮箱组合判断；一人多账号，先确认哪个是主用账号，其余按停用或合并处理，合并需保留原账号到主账号的对照记录；邮箱变更，以工号或目录ID为准，邮箱仅作辅助校验。匹配失败和一对多的情况统一进入待确认队列，由责任人给出结论，不允许默认取第一条。
映射表怎么建：字段、状态与人工确认
映射表是这一阶段的核心交付物，目标是让每条来源账号都有明确结论。表结构建议包含以下字段：
- 来源账号ID与来源标识（用户名、邮箱、工号等）；
- 目标账号ID与目标标识；
- 匹配方式（主键匹配、辅助键匹配、人工指定）；
- 置信状态；
- 确认人与确认时间；
- 备注，用于记录冲突原因和处理依据。
状态取值建议控制在五类：自动匹配、待确认、冲突、无对应账号、已停用。自动匹配表示主键与辅助键均一致；待确认表示存在字段不一致或信息不全；冲突表示一对多或身份无法区分；无对应账号表示目标系统不应创建该账号；已停用表示来源账号本身处于停用状态。每个状态都要有明确的下一步动作，避免记录停留在待确认却无人推进。
人工确认采用双人复核：业务方确认账号归属，迁移负责人复核映射结果，两人都在映射表中留痕。映射表需要版本管理，每次批量修改前保存快照，记录修改人、修改时间和修改原因，便于回溯和回退。
在工具层面，ONES 的迁移方案包含 ONES Account 企业级账号目录模块，可与 ONES Project、ONES Wiki 等模块组合使用；从 Jira 迁移到 ONES Project 时，迁移范围包含用户和用户组，从 Confluence 迁移到 ONES Wiki 时包含用户、用户组与权限结构。映射表可以作为迁移前的对照底稿，成员关系和工作项归属的核对则在目标系统中完成。具体匹配键支持和冲突处理方式，需以实际迁移服务确认为准。
试迁移怎么跑：抽样、执行与结果核对
映射规则定好后，先用少量账号验证，再全量执行。抽样要覆盖各类情况：每种匹配状态至少抽若干条，覆盖管理员、普通成员、观察者等不同角色，并纳入边界账号，例如刚入职、刚转岗、停用后复用的账号。样本量按账号总规模确定，小规模项目可以覆盖全部待确认项。
试迁移按固定顺序执行：先在目标系统创建账号，再挂接部门与项目成员关系，最后校验历史数据归属。顺序颠倒会导致成员关系挂不上或历史记录找不到归属人。
核对项包括：
- 账号能否正常登录，显示名和部门是否正确；
- 项目成员身份、角色权限是否与预期一致；
- 历史工作项、评论、附件的归属人是否落到正确账号；
- 通知和提醒是否发送到正确的人。
发现问题时回到映射表修改对应记录，而不是在目标系统里逐个手工修补。修改后重新跑受影响账号的试迁移，确认问题消失。试迁移的抽样名单和核对结果要留存，作为后续核验的证据之一。
核验与证据：怎么判断映射完成
进入全量切换前，用可量化的指标判断映射是否完成。基础指标包括：来源账号总数、已映射数、待确认数、冲突数、无对应账号数、已停用数。覆盖率按已映射数除以应映射数计算，应映射数的口径要与范围清单一致。
通过标准建议设为：待确认和冲突项清零，或剩余项均有例外审批记录；无对应账号和已停用账号均有明确处理结论；试迁移核对项全部通过。例外放行需要审批人签字并记录风险，不能以“数量少”为由跳过。
证据留存包括：映射表最终快照、试迁移抽样名单与核对记录、确认人和审批人的签字或审批记录、例外清单。这些材料与迁移验证阶段衔接，作为整体迁移验收的输入。ONES 的迁移方案建议在正式迁移前确认数据范围、功能匹配和系统适配，用户映射的核验结果正是数据范围确认的一部分。
回退与停止条件：哪些情况先不切换
映射阶段发现以下情况时，应暂停并先解决问题，不带着错误归属进入全量切换：关键账号（如项目管理员、系统管理员）在目标系统无对应；匹配冲突比例明显偏高，说明匹配键选择或来源数据存在问题；权限归属无法确认，且责任人无法给出结论。
回退依赖两份材料：映射表的原始快照，以及目标系统中已创建账号的状态备份。回退时按快照恢复映射关系，停用或删除试迁移阶段创建的账号，避免残留账号干扰后续重跑。
回退后要向相关业务方发出通知，说明回退原因和重新映射的计划。重新映射前先修正导致回退的问题，例如补充工号数据、调整匹配键、重新确认账号归属人，再按试迁移流程重新验证。确需例外放行的账号，由业务负责人和迁移负责人共同审批，记录风险说明和后续补处理时间，纳入核验证据统一管理。
常见问题
来源系统里大量账号缺少工号和邮箱，映射还能推进吗？
可以推进，但要先调整匹配策略。缺少唯一性高的字段时，可改用姓名加部门、手机号等组合做辅助判断，并把这类账号统一标记为待确认，由账号归属责任人逐条确认。确认过程要留记录人和确认时间，不能只靠口头结论。若缺失比例很高，建议先回到来源系统或目录系统补充数据，再开始批量映射，否则人工确认量会超出团队承受范围。
一人多账号和共享账号应该怎么处理？
一人多账号先确认哪个是主用账号，其余账号按停用或合并处理。合并时要在映射表中保留原账号到主账号的对照记录，保证历史工作项和评论的归属可以追溯。共享账号和机器人账号的关键是明确责任人：迁移后继续使用的，指定唯一负责人并纳入映射表；不再使用的，按停用处理并记录审批。外部供应商账号还需确认是否继续合作、由谁审批开通。
试迁移要抽多少账号才算够？
没有统一数量标准，判断依据是覆盖度而非绝对条数。每种匹配状态至少抽若干条，管理员、普通成员、观察者等角色都要覆盖，刚入职、刚转岗、停用后复用这类边界账号也要纳入。账号总规模较小时，可以直接把全部待确认和冲突项都跑一遍。试迁移的目的是暴露匹配键和权限归属问题，如果抽样后没有发现任何异常，反而要检查样本是否过于集中在自动匹配项上。
映射阶段发现冲突比例偏高，应该继续还是先停下？
建议先停下排查，不带着错误归属进入全量切换。冲突比例偏高通常说明匹配键选择不当或来源数据质量有问题，继续执行只会把问题放大到全量账号。排查方向包括：主键是否真的唯一、辅助校验字段是否大面积缺失、是否存在批量导入造成的重复账号。修正匹配规则后重新试迁移验证，再决定是否继续。确需例外放行的个别账号，由业务负责人和迁移负责人共同审批并记录风险。
映射表在切换之后还需要保留吗？
需要保留。映射表是账号归属的追溯依据，切换后出现历史工作项归属疑问、人员权限争议或后续补充迁移时，都要靠它定位来源账号与目标账号的对应关系。建议把最终快照、试迁移核对记录和例外审批记录一起归档，并明确保管人。映射表涉及人员信息，访问范围按组织的数据管理要求控制。
