迁移用户映射不能只按用户名匹配，因为用户名只在单一系统内唯一，跨系统可能出现重名、改名、账号复用，也可能与登录名、邮箱、工号不一致。只按用户名对齐，容易把工作项、评论和权限归到错误的人名下。稳妥做法是以稳定唯一标识为主键，结合邮箱、工号、组织归属和权限角色交叉校验，无法唯一确定的人员进入人工确认。
要点总览（TL;DR）
- 迁移用户映射是把来源系统账号与目标系统账号建立对应关系的过程，产出是可核对的对应表和未匹配清单。
- 用户名只在单一系统内唯一，跨系统重名、改名、账号复用和格式差异都会导致错误匹配或漏匹配。
- 匹配应以工号或外部目录 ID 为主键，邮箱作强校验，姓名、用户名和组织归属用于消歧，权限角色随人员一并映射。
- 执行顺序是先按唯一标识自动匹配，再交叉校验，冲突和缺失进入人工确认，确认结果留痕回写映射表。
- 用户映射解决人员身份对应，权限映射解决角色授权对应，数据归属是映射结果在工作项上的体现，三者检查顺序不同。
迁移用户映射是什么
迁移用户映射是建立来源系统账号与目标系统账号之间对应关系的过程。它回答的是“来源系统里的这个账号，到了目标系统应该对应哪个人”。映射的对象是人员身份，产出是一张可核对的对应表，以及一份未能匹配或存在冲突的清单。
映射的输入通常包括来源系统的账号、姓名、邮箱、工号、所属组织，以及该人员承担的角色和项目成员关系。这些字段来自账号导出、组织架构数据或目录服务，具体可用范围取决于来源系统的导出能力，实施前应先核对字段清单。
映射的产出不只是“匹配成功”的名单。一份可用的对应表至少应包含来源账号、目标账号、匹配依据、匹配方式（自动或人工）、确认人和确认时间；未匹配清单则记录缺失字段、一对多冲突和待确认人员。迁移执行和后续核验都以这张表为依据。
只按用户名匹配会在哪些地方出错
用户名的唯一性有明确边界：它在单一系统内通常唯一，跨系统不保证唯一。两个系统各自维护账号体系，命名规则、注册时间和管理员都不同，同一个字符串完全可能指向两个不同的人。把用户名当作跨系统主键，等于假设两个系统的命名空间天然一致，这个假设在多数迁移场景中并不成立。
具体失效情形主要有以下几类：
- 同名不同人。来源系统和目标系统各有一个 zhangsan，实际是两名员工。直接匹配会把前者的历史工作项和评论挂到后者名下。
- 同人不同名。员工改名、更换登录名，或来源系统使用拼音、目标系统使用工号，用户名对不上，导致漏匹配，人员被当作新用户处理。
- 离职账号复用。旧账号被回收后分配给新员工，用户名相同但身份已变，历史数据归属随之错乱。
- 格式差异。大小写、分隔符、前后空格、域名后缀的差异，会让本应匹配的账号被判为不匹配，或让本不相同的账号被误判为同一人。
- 字段口径不一致。用户名与登录名、邮箱、工号在不同系统中含义不同，同一字段在两边可能存的是不同信息。
这些错误的后果集中在归属上：工作项的处理人、评论作者、附件上传者、项目成员和权限授予对象都可能指向错误的人。错误一旦写入，后续按人员统计工作量、追溯操作记录、审计权限都会失真，纠正成本远高于迁移前多花时间做校验。
映射需要综合哪些身份标识与权限信息
可靠的映射以稳定唯一标识为主键，其余字段用于校验和消歧。各字段的分工可以按下表理解：
| 字段 | 在映射中的角色 | 使用条件与注意点 |
|---|---|---|
| 工号、外部目录 ID | 首选主键 | 由组织统一分配、不随改名变化；需确认来源系统已导出该字段 |
| 邮箱 | 次选主键或强校验字段 | 企业邮箱通常唯一，但存在别名、历史邮箱、共用邮箱等情况，不能默认唯一 |
| 姓名 | 辅助校验 | 重名常见，只用于缩小候选范围，不单独作为匹配依据 |
| 用户名 | 辅助校验 | 反映登录习惯，可能随改名或系统规则变化 |
| 组织与部门归属 | 消歧 | 在重名或字段缺失时帮助判断候选人，需注意组织调整带来的历史差异 |
| 角色与项目成员关系 | 随人员一并映射 | 人员对应关系确定后，其在项目中的角色和成员身份需要同步落到目标账号 |
权限角色需要随人员一起映射，原因是权限授予的对象是人。人员对应错了，角色再准确也会授给错误的人。因此映射表应同时记录人员在来源系统中的角色和项目成员关系，作为目标系统授权配置的输入。
一套可执行的匹配与确认流程
匹配流程按“先自动、再校验、后人工”的顺序推进，每一步都有明确的完成标志。
- 准备字段。从来源系统导出账号、姓名、邮箱、工号、组织和角色信息，与目标系统现有账号数据对齐字段口径，形成两侧的字段清单。完成标志是两侧关键字段均可读取、含义已确认。
- 按唯一标识自动匹配。以工号或外部目录 ID 为主键做第一轮匹配，命中即写入对应表。完成标志是自动匹配结果和未命中清单分别生成。
- 交叉校验。对自动匹配结果用邮箱、姓名、组织做一致性检查；对未命中人员改用邮箱做第二轮匹配，再用姓名和组织缩小候选范围。完成标志是每条匹配记录都带有匹配依据。
- 人工确认。一对多、多对一、字段缺失、校验不一致的记录进入人工确认队列，由熟悉组织情况的人员逐条判定。完成标志是队列清空，每条记录都有确认结论。
- 留痕与回写。确认结果写回映射表，记录匹配方式、确认人和时间，作为迁移执行与后续核验的依据。完成标志是映射表版本固定，可被迁移任务直接引用。
在匹配确认和映射表留痕环节，ONES 的迁移方案覆盖用户、用户组及相关权限数据的迁移，例如从 Jira 迁移到 ONES Project 时迁移范围包括用户、用户组和系统配置，从 Confluence 迁移到 ONES Wiki 时包括用户、用户组、空间权限与页面权限。映射确认后，人员对应关系可以直接用于目标系统中的成员配置和工作项归属，减少迁移后逐条修正归属的工作。具体支持哪些匹配字段和冲突处理方式，需在实施前与迁移方案确认。
和相邻概念的区别：账号映射、权限映射、数据归属
用户映射、权限映射和数据归属描述的是迁移中三个不同层次的问题，混用会导致责任和验收标准不清。
用户映射解决人员身份对应，回答“来源账号对应目标系统的哪个人”，产出是人员对应表和未匹配清单。
权限映射解决角色与授权的对应，回答“这个人在来源系统中拥有的角色和权限，在目标系统中应配置成什么”，它以用户映射结果为前提，产出是角色对照和授权配置。
数据归属是映射结果在工作项、评论、附件等对象上的体现，回答“这条记录最终挂在谁名下”。它依赖前两者，但属于迁移执行后的结果状态。
三者的检查顺序是先确认人员，再配置权限，最后核对数据归属。工作流与插件行为的迁移、迁移结果的整体核验与切换管理属于另外的环节，本文不展开。
一个具体例子与常见误解
假设来源系统有一个账号 zhangsan，对应研发一部的张三；目标系统也有一个 zhangsan，对应市场部的张三。只按用户名匹配，研发一部张三的历史工作项、评论和项目成员身份会全部落到市场部张三名下。迁移完成后，市场部张三的待办列表里出现大量研发任务，研发一部张三的历史记录则显示为空。这类错误在数据量小时容易被忽略，在按人员统计和权限审计时集中暴露。
另一个常见情形是改名。员工李四在来源系统中使用 lisi 登录，入职后改名并更换登录名为 lisi02，目标系统按新名字建号。按用户名匹配时两个账号对不上，李四被当作新用户，历史工作项无人认领，需要人工补挂。
与之相关的典型误解有四个：
- “邮箱一定唯一。”企业邮箱通常唯一，但别名、历史邮箱、共用邮箱和外部协作账号会让这一假设失效，邮箱适合作为强校验字段，仍需与其他字段配合。
- “姓名可以当主键。”重名在组织中很常见，姓名只能用于缩小候选范围。
- “用户名对得上就没问题。”用户名对得上只说明字符串相同，不说明是同一个人，也不说明权限和角色应当一致。
- “匹配完成即迁移完成。”匹配只是人员对应关系确定，权限配置、数据归属写入和结果核验仍需分别完成。
把匹配依据、确认过程和未匹配清单记录下来，是让上述错误在迁移前被发现、在迁移后可追溯的关键。
常见问题
来源系统导不出工号或外部目录 ID，还能做可靠的用户映射吗？
可以，但需要调整主键选择并接受更高的人工确认比例。此时可把企业邮箱作为第一轮匹配依据，再用姓名和组织归属缩小候选范围。前提是先确认邮箱在两侧都完整、且不存在大量别名或共用邮箱；如果邮箱也不可靠，就只能以姓名加组织做候选筛选，逐条人工判定。字段可用范围取决于来源系统的导出能力，实施前应先核对字段清单，再决定自动匹配能覆盖多少人员。
员工在迁移窗口期内改名或换部门，映射表要怎么处理？
以迁移执行时点的数据为准，并在映射表中记录来源侧的原始字段值。改名或换部门会改变姓名、用户名和组织归属，但工号、外部目录 ID 这类稳定标识通常不变，因此主键匹配仍然有效。需要额外注意的是：如果来源系统在改名后新建了账号，就会出现同一人两个来源账号的情况，这类记录应进入人工确认队列，判定是否合并到同一个目标账号，并在映射表中注明合并依据。
人工确认队列应该由谁判定，判定标准怎么定？
判定人应熟悉组织架构和人员变动情况，通常是 HR、IT 管理员或各业务线的对接人。判定标准建议在迁移前写清楚，例如：工号一致且姓名一致可直接确认；工号一致但姓名不同需核对是否为改名；工号缺失但邮箱一致可确认；仅姓名和组织一致则需人工核实。标准明确后，队列处理速度和结论一致性都会提高，也便于后续复核。
用户映射做完后，权限和数据归属还需要单独处理吗？
需要。用户映射只确定人员对应关系，权限映射要在此基础上把来源系统的角色和授权配置到目标账号，数据归属则是在迁移执行时把工作项、评论、附件等对象挂到对应人员名下。三者是先后衔接的关系，人员对应错了，后面两步都会跟着错；人员对应对了，也不代表权限配置和数据写入已经完成。建议把三者分别列入验收项，逐项核对。
ONES 的迁移方案在用户映射环节覆盖哪些内容？
根据 ONES 公开的迁移方案说明，从 Jira 迁移到 ONES Project 时迁移范围包括用户、用户组和系统配置；从 Confluence 迁移到 ONES Wiki 时包括用户、用户组、空间权限与页面权限。映射确认后，人员对应关系可用于目标系统的成员配置和工作项归属。具体支持哪些匹配字段、冲突如何处理，公开资料未展开说明，实施前应与迁移方案确认。
