迁移用户映射要解决的是“来源系统里的每个账号，迁到目标系统后对应谁”。做法可以拆成四步：盘点来源用户并去重，建立映射表，处理同名、离职、外部协作等特殊情况，用试迁移和抽样核对验证结果。本文聚焦用户数据本身，工作流配置、插件行为和权限策略细节不在展开范围内。
要点总览（TL;DR）
- 迁移用户映射先写范围说明：固定来源到目标的方向，明确在职、离职、外部协作、服务账号各自是否纳入，工作流与权限细节不混入映射表。
- 映射表至少包含来源账号、姓名、邮箱、组织、状态、目标账号、映射依据、确认状态八列；匹配按唯一标识优先、姓名辅助的顺序执行，冲突项挂起人工确认。
- 试迁移样本覆盖不同组织、角色和账号状态，核对登录、历史工作项归属、通知指向和组织角色归属，通过标准在试迁移前写成可核验条目。
- 关键用户无法匹配、历史归属大面积错位、特殊账号口径未确认时暂停迁移；保留来源系统只读访问和映射表历史版本，修正后只重跑受影响样本。
- 映射结果落地后，用户与工作项归属需在日常协作中持续可用；ONES 的 Jira 迁移场景覆盖用户、用户组和系统配置，ONES Account 可作为账号目录承载模块，具体配置需实施前确认。
迁移用户映射要迁哪些对象、覆盖到什么范围
用户映射的第一步是写清范围说明：从哪个来源系统迁到哪个目标系统，哪些账号进入映射表，哪些内容本次不处理。范围说明是后续导出、匹配和核验的共同依据，缺少它，映射表容易出现对象混入或遗漏。
来源系统与目标系统的用户体系通常存在差异。来源侧可能以登录名作为账号，目标侧要求邮箱唯一；来源侧的组织树按部门划分，目标侧按项目团队组织；来源侧的角色绑定在项目上，目标侧的角色可能由用户组继承。这些差异决定了映射不能只对“账号”一个字段，还要把姓名、邮箱、组织归属和账号状态一并纳入对照。
纳入映射的用户范围
建议按账号状态和协作关系划分纳入范围，并在范围说明中逐类写明处理方式：
- 在职用户：纳入映射，作为试迁移核验的主要对象。
- 离职用户：其历史工作项仍需保留归属，通常纳入映射或做归档处理，具体口径由业务方决定。
- 外部协作账号：供应商、外包、客户侧账号是否迁入目标系统、以何种账号类型存在，需要提前确认。
- 服务账号与共享账号：用于集成、自动化或多人共用的账号，要明确是迁移、停用还是替换为新的集成账号。
不纳入本次映射的内容
工作流配置、插件行为、字段选项和权限策略细节属于其他迁移阶段的工作。用户映射表只回答“人对应谁”，不承担“流程怎么走”“权限怎么配”的职责。把这些内容混入映射表，会让核对口径变得模糊，也会让映射责任人承担超出职责范围的确认工作。
迁移方向必须固定为来源到目标。映射表按“来源账号 → 目标账号”的方向记录，试迁移也从来源数据向目标系统导入。方向颠倒会造成字段对应关系错位，后续核验难以判断问题出在映射还是导入环节。
本阶段交付物：一份用户映射范围说明，列明来源系统、目标系统、纳入映射的用户类别及处理口径、排除在本次映射之外的内容。
开始映射前需要准备哪些输入
映射表的质量取决于输入是否齐全。开始匹配之前，需要拿到来源用户清单、目标系统的账号规则、组织与角色清单，以及业务方对特殊账号的处理决定。缺项时应先挂起相关账号，不用猜测填补。
来源用户清单与去重口径
从来源系统导出用户清单时，至少包含账号、姓名、邮箱、所属组织、账号状态和最近活跃时间。导出后先做去重：同一邮箱出现多条记录、同一人拥有多个账号、账号已停用但仍有历史数据归属，这些情况要在清单阶段标记出来。去重口径要写进范围说明，例如“同一邮箱保留最近登录的账号，其余标记为待合并”。
目标系统账号创建规则
目标系统的账号唯一标识决定了匹配的主键。常见选择是邮箱或工号。需要确认：目标系统是否允许同一邮箱对应多个账号，账号创建是否依赖组织先行建立，账号状态有哪些取值。唯一标识一旦确定，映射表的匹配规则就围绕它展开，姓名只作为辅助核对字段。
组织架构、角色清单与特殊账号决定
组织架构清单用于核对用户归属是否完整，角色清单用于判断迁移后权限承载方式。离职账号、外包账号、共享账号的处理决定需要业务方书面确认，例如“离职用户保留账号并转为只读”“外包账号迁入后归入外部协作组”。这些决定直接影响映射表中“目标账号”和“映射依据”两列的填写方式。
责任人与确认人分工
建议明确三类角色：数据导出人负责来源清单的完整性和去重，映射责任人负责逐条匹配和特殊情况标注，确认人负责对挂起项和特殊账号处理口径签字。分工表与输入清单放在一起，便于在试迁移前逐项核对是否齐备。
| 输入项 | 用途 | 缺失时的处理 | 责任人 |
|---|---|---|---|
| 来源用户清单（含状态、组织、邮箱） | 映射表基础数据 | 暂停导出，补齐字段后再匹配 | 数据导出人 |
| 目标系统账号规则与唯一标识 | 确定匹配主键 | 先按邮箱试匹配，标记待确认 | 目标系统管理员 |
| 组织架构与角色清单 | 核对归属完整性 | 映射表组织列留空并挂起 | 业务方 |
| 特殊账号处理决定 | 确定离职、外包、共享账号去向 | 相关账号挂起，不进入试迁移 | 业务方确认人 |
| 责任人与确认人名单 | 挂起项流转与签字 | 映射表确认状态无法闭环 | 迁移负责人 |
用户映射表怎么建：字段、规则与特殊情况处理
映射表是这一阶段的核心交付物。它要能回答两个问题：这个来源账号迁过去是谁，依据是什么。表结构建议固定为以下字段，匹配规则按优先级执行，特殊情况单独标注而不是直接删除。
映射表字段
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 来源账号 | 来源系统登录名或账号 ID | 定位来源记录 |
| 姓名 | 来源系统显示名 | 辅助核对，不作主匹配 |
| 邮箱 | 来源系统登记邮箱 | 常用唯一标识候选 |
| 组织 | 来源侧部门或团队 | 核对归属完整性 |
| 状态 | 在职、离职、外部、服务账号等 | 决定处理口径 |
| 目标账号 | 目标系统账号或待创建标记 | 回答“迁过去是谁” |
| 映射依据 | 邮箱一致、工号一致、人工确认等 | 支撑可追溯 |
| 确认状态 | 已确认、待确认、挂起、不迁移 | 控制试迁移范围 |
匹配规则与冲突判定顺序
匹配按以下顺序执行，前一步无法唯一确定时进入下一步：
- 用唯一标识匹配，优先邮箱，其次工号或来源系统账号 ID。
- 唯一标识命中但姓名不一致时，标记为待确认，由映射责任人核对是否为改名或账号复用。
- 唯一标识未命中时，用姓名加组织辅助查找，结果必须经人工确认后才能写入目标账号。
- 同名且同组织、或同一邮箱对应多个来源账号时，挂起处理，不自动选择其中一个。
姓名只作辅助的原因很直接：同名在研发组织中并不少见，仅凭姓名匹配会把历史工作项归到错误的人名下。邮箱也可能出现一人多账号或别名邮箱的情况，因此冲突判定要保留人工确认环节。
离职、外部协作与服务账号的处理
离职账号的处理取决于历史数据是否需要保留归属。常见做法是保留账号并转为只读，或在目标系统中建立归档账号承接历史工作项。外部协作账号要确认目标系统的账号类型和可见范围，避免迁入后获得超出原范围的访问。服务账号与共享账号建议逐个确认用途，能替换为正式集成账号的，在映射表中记录替换关系；无法确认用途的，挂起并列入切换前检查项。
无法自动匹配时的挂起流程
挂起项集中记录在映射表的待确认区，注明挂起原因、需要谁确认、确认截止时间。确认完成后回填目标账号和映射依据，状态改为已确认。试迁移只使用已确认的记录，挂起项不进入试迁移，避免用未定结果验证映射质量。
试迁移与核验：怎么确认映射结果正确
映射表填完不等于映射正确。试迁移的作用是用一小批有代表性的用户走完导入流程，核对账号、归属和通知是否按预期落到目标系统。通过标准要在试迁移前写好，核验记录与映射表一起留存。
选取代表性用户
试迁移样本应覆盖不同组织、不同角色、不同账号状态，以及至少一个曾改名的账号和一个外部协作账号。样本数量不必大，但要能暴露匹配规则中的边界情况。样本名单从映射表中已确认的记录里选取，挂起项不纳入。
核对项与通过标准
- 账号可登录：目标账号能正常登录，账号状态与映射表一致。
- 历史工作项归属正确：抽查样本用户名下的工作项，确认创建人、经办人、评论作者指向正确的人。
- 通知与提及指向正确：触发一次提及或状态变更通知，确认接收人是映射后的目标账号。
- 组织与角色归属正确：样本用户进入目标系统后所在团队和角色与映射表记录一致。
通过标准建议写成可核验的条目，例如“样本用户全部可登录，抽查工作项归属错误数为零，通知接收人全部正确”。出现差异时，记录差异类型、涉及账号和映射表对应行号，回到映射表修正后重新试迁移受影响的样本。
抽样与全量核对的分工
试迁移阶段以抽样核对为主，由映射责任人执行，确认人复核差异记录。正式迁移前，对映射表中标记为人工确认、曾改名、外部协作的账号做全量复核；对自动匹配且唯一标识一致的账号，可按组织抽样复核。核验证据包括试迁移样本名单、核对结果记录、差异清单及修正后的映射表版本，统一归档，作为切换前确认的材料。
映射出错或无法匹配时的回退与停止条件
带着错误映射进入正式切换，修正成本会明显上升。需要在试迁移阶段就约定阻断条件和回退点，出现下列情况时暂停迁移，回到映射表修正。
阻断条件
- 关键用户无法匹配，例如项目负责人、系统管理员或高频经办人没有确定的目标账号。
- 历史工作项归属出现大面积错位，抽查错误比例超出试迁移前约定的阈值。
- 外部协作账号或服务账号的处理口径未确认，影响目标系统的访问范围。
- 映射表存在未闭环的挂起项，且涉及试迁移样本之外的关键角色。
回退点与修正范围
回退点包括两项：来源系统在切换前保持只读访问，供核对历史归属；映射表保留版本记录，每次修正生成新版本并注明变更行。修正后重新试迁移的范围限定在受影响账号及其关联工作项，不必全量重跑，但修正记录要并入核验证据。
切换前的最终确认
正式切换前，由映射责任人和确认人对映射表最终版本签字，确认挂起项已全部处理或明确不迁移，试迁移差异已闭环。签字记录与范围说明、输入清单、核验记录放在同一归档位置，形成从范围到结果的完整链条。
映射结果落地到目标系统后，用户与工作项的归属关系需要在日常协作中持续可用。以 ONES 为例，其 Jira 迁移场景覆盖用户、用户组和系统配置，迁移后工作项、状态、字段和历史记录继续承载研发过程；ONES Account 提供企业级账号目录，可作为账号组织的承载模块。具体匹配规则、特殊账号处理和核验材料导出方式，需在实施前结合目标系统实际配置确认。
常见问题
来源系统里同一个人有多个账号，映射表应该保留几条记录？
建议在来源用户清单阶段先做去重，把同一人的多个账号标记出来，再决定保留哪一条进入映射表。常见口径是同一邮箱保留最近登录的账号，其余标记为待合并，并在映射依据列写明合并原因。被合并的账号如果仍有历史工作项归属，需要在试迁移核验时确认这些工作项是否已正确归到保留账号名下；无法确认归属的，先挂起，不进入试迁移。
离职用户的历史工作项必须迁过去吗？
取决于业务方对历史数据归属的要求。如果离职用户名下的工作项仍需在目标系统中可查、可追溯，通常需要为其保留账号或建立归档账号承接归属；如果这部分历史数据不在迁移范围内，则应在范围说明中明确排除，并在映射表中标记为不迁移。两种口径都要由业务方书面确认，映射责任人按确认结果填写目标账号和确认状态，避免试迁移阶段临时决定。
试迁移抽样要抽多少人，抽少了会不会漏掉问题？
样本数量不是关键，覆盖边界情况才是。建议覆盖不同组织、不同角色、不同账号状态，并至少包含一个曾改名的账号和一个外部协作账号，这些是最容易暴露匹配规则问题的情况。自动匹配且唯一标识一致的账号可以在正式迁移前按组织抽样复核，人工确认、曾改名、外部协作的账号做全量复核。抽样发现差异时，记录差异类型和映射表行号，修正后重新试迁移受影响样本。
映射表修正后，之前做过的试迁移核验记录还有效吗？
修正会影响哪些账号，就重新核验哪些账号，其余记录继续有效。操作上建议映射表每次修正生成新版本并注明变更行，试迁移核验记录关联到对应版本；重新试迁移的范围限定在受影响账号及其关联工作项，修正记录并入核验证据。切换前签字确认的是映射表最终版本和与之对应的核验记录，版本之间要能对应上，否则签字材料无法说明核验的是哪一版映射。
用户映射做完后，目标系统里的账号组织还需要额外处理吗？
需要。映射表解决的是“人对应谁”，账号在目标系统中的组织归属、用户组和角色承载方式属于落地环节。以 ONES 为例，其 Jira 迁移场景覆盖用户、用户组和系统配置，ONES Account 提供企业级账号目录，可作为账号组织的承载模块；具体匹配规则、特殊账号处理和核验材料导出方式，需在实施前结合目标系统实际配置确认。
