迁移用户映射时遇到离职账号和邮箱变更，处理原则并不相同：离职账号要先判断历史数据是否仍需归属，再决定保留为停用账号、挂到接替人还是归入公共账号；邮箱变更则要用工号、手机号等稳定标识确认是同一人，把新旧邮箱归并到一个目标账号。两类异常都应在映射表中单独标记并留下判定证据，迁移后抽样核验工作项归属和登录可用性。本文只讨论迁移数据内容层面的用户映射，工作流与插件行为迁移、迁移结果整体核验与切换管理不在范围内。
要点总览（TL;DR）
- 离职账号先判断历史数据是否仍需归属，再按保留为停用账号、挂到接替人、归入组织公共账号三类处置，并在映射表中记录判定依据。
- 邮箱变更用工号、手机号或第三方唯一ID确认是否同一人，邮箱只作辅助字段，新旧邮箱归并到一个目标账号，避免同一人被拆成两个用户。
- 排查顺序是先按稳定标识聚类，再查人事系统确认人员状态，最后决定映射去向；证据不足的记录标记为待确认并挂起。
- 批量合并前备份源映射表并设置停止点，先小范围试跑核对工作项与评论归属，再扩大执行范围。
- 迁移后按处置类型抽样核验工作项、评论、附件归属，核对源账号总数与已处置、待确认数量是否对得上。
先分清两类异常：离职账号与邮箱变更的表现
用户映射表通常以“源账号—目标账号”成对记录。异常往往不是迁移工具报错，而是映射表里出现无法直接配对的记录。先按症状归类，后续排查和处置才有明确方向。
离职账号的典型表现是：源系统中账号存在，人员已离开组织，目标侧没有对应的在职用户。映射表里这一行可能空着目标账号，也可能被临时指向某个在职同事，但没有任何交接说明。如果直接跳过，历史工作项、评论和附件会失去归属；如果随意指向他人，又会把责任错误地转移给无关人员。
邮箱变更的表现更隐蔽：同一个人在源系统里有新旧两条账号记录，或者源账号邮箱与目标账号邮箱不一致。映射表里会出现两个源账号指向同一个目标账号，或者一个源账号找不到匹配目标。若按邮箱直接匹配，同一个人容易被拆成两个用户，工作项归属被分散到两个身份下。
两类异常混在一起处理，常见后果是重复用户和数据归属丢失同时出现。比如把邮箱变更误判为离职，给旧邮箱建一个停用账号，结果同一人的历史数据被切成两段；或者把离职账号直接合并到接替人，却没有记录交接依据，后续无法追溯。下表对照两类异常的症状，便于在映射表中快速识别。
| 异常类型 | 映射表表现 | 直接后果 | 判定方向 |
|---|---|---|---|
| 离职账号 | 源账号有记录，目标侧无在职用户；或目标账号被临时指向他人 | 历史数据失去归属，或责任错误转移 | 判断人员状态与历史数据归属需要 |
| 邮箱变更 | 同一人新旧邮箱并存；源邮箱与目标邮箱不一致；两个源账号指向同一目标 | 同一人被拆成两个用户，工作项归属分散 | 用稳定标识确认是否同一人 |
原因假设与排查证据：先确认是哪一种情况
映射异常的原因需要证据支撑，不能凭邮箱相似或姓名相同直接下结论。排查时先按稳定标识聚类，再判断人员状态，最后决定映射去向。这个顺序能避免把邮箱变更误判为离职，也能避免把离职账号错误合并。
离职账号的常见成因
- 人员已离职，但历史工作项、评论和附件仍需保留归属，源账号未被删除，只是停用。
- 账号被停用但未删除，迁移时仍出现在源用户列表中。
- 外包、实习或临时协作账号到期，人员关系结束但项目数据仍在。
邮箱变更的常见成因
- 企业域名更换，同一人的邮箱从旧域名切换到新域名。
- 个人改名导致邮箱前缀变化。
- 账号重建，同一人在源系统中出现两条记录，邮箱不同但实际是同一人。
验证证据与排查顺序
可用证据包括人事系统在职状态、工号或员工编号、手机号、第三方登录唯一ID、账号创建与停用时间。排查顺序建议如下：
- 先按工号、手机号或第三方唯一ID对源账号聚类，把疑似同一人的记录归到一组。
- 再查人事系统确认人员当前状态，区分在职、离职和临时关系结束。
- 对在职人员，核对新旧邮箱是否指向同一人，判断是否需要归并。
- 对离职人员，确认历史数据是否有明确接替人或归属部门，再决定处置类型。
- 无法取得上述证据的记录，标记为待确认并挂起，不直接合并或丢弃。
需要提醒的是，邮箱只能作为辅助字段。域名更换和改名都会让邮箱失去稳定性，单靠邮箱匹配容易把同一人拆开，也容易把不同人误合。把判定依据写进映射表，后续复核才有据可查。
处置步骤：离职账号怎么映射
离职账号的处置取决于历史数据是否仍需归属，以及业务上是否有明确接替人。建议在映射表中先分类，再批量执行，避免边判断边操作导致状态混乱。
三类处置路径
| 处置类型 | 适用条件 | 操作方式 | 注意事项 |
|---|---|---|---|
| 保留为停用账号 | 历史工作项、评论、附件仍需归属原账号，且无明确接替人 | 目标侧建立同名停用账号承接历史数据 | 保留原账号标识作为映射依据，避免与在职账号混淆 |
| 挂到接替人 | 业务已明确交接，接替人愿意承接历史数据 | 将历史数据映射到接替人账号，映射表记录原账号与接替关系 | 交接关系需有业务确认记录，不能仅凭口头约定 |
| 归入组织公共账号 | 无人接替的团队资产，如部门或项目公共账号 | 将数据归到部门或项目公共账号 | 公共账号需有明确管理责任人，避免成为新的无主数据 |
操作顺序与映射表字段
操作前先备份源映射表，保留原始记录。合并类操作设置停止点：先处理一小批，确认工作项和评论归属正确后再批量执行。映射表建议包含以下字段，便于逐条判定和事后追溯。
- 源账号、源邮箱
- 稳定标识（工号、手机号或第三方唯一ID）
- 人员状态（在职、离职、临时关系结束）
- 处置类型（停用账号、接替人、公共账号）
- 目标账号
- 判定人、判定时间
- 判定证据与备注
在ONES的迁移场景中，官方资料说明Jira迁移至ONES Project时迁移范围包括用户和用户组，Confluence迁移至ONES Wiki时包括用户、用户组、空间权限与页面权限。这些说明确认了用户是迁移对象，但离职账号的具体映射规则和可选处置方式仍需在实际迁移方案中确认。实施时可以把上述映射表作为迁移前的判定记录，与迁移方案中的用户处理规则对齐后再执行。
处置步骤：邮箱变更怎么归并到同一人
邮箱变更的核心是身份识别，不是邮箱本身。处理目标是让同一人在目标系统中只有一个账号，同时保留旧邮箱的可追溯信息。
归并方法
- 以工号、手机号或第三方唯一ID作为主键聚类，把新旧邮箱记录归到同一组。邮箱只作辅助字段，不单独作为匹配依据。
- 确认新旧邮箱指向同一人后，选定一个目标账号作为主账号，把旧邮箱记录并入。
- 保留旧邮箱作为别名或备注，便于后续查历史记录和通知追溯。
- 无法确认是否同一人的记录，先挂起并列入待人工确认清单，不进入批量归并。
- 批量归并前先在小范围试跑，核对工作项数量、评论归属和附件是否完整。
待确认清单与风险边界
待确认清单至少记录：源账号、新旧邮箱、疑似同一人的依据、缺失的证据、待确认事项和负责人。清单中的记录在确认前不执行合并，避免把两个不同的人错误归并。涉及账号合并的操作须交代备份与回退方式：合并前备份源映射表和账号记录，合并后保留一段观察期，发现归属错误时能按备份恢复并重做。回退边界应明确到具体批次，不宜在全部归并完成后才统一检查。
ONES官方资料提到迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，目标是保持研发过程连续。邮箱归并直接影响工作项和评论的归属连续性，因此归并结果应与迁移方案中的历史数据归属规则一起确认，具体识别主键和归并机制以实际迁移方案为准。
验证与复发预防：迁移后怎么确认处理正确
处置完成后，验证要覆盖数据归属、登录可用性和映射表完整性三个方面。验证不通过时，按批次回退并重做，避免错误扩散。
验证清单
- 抽样核验：按处置类型各抽若干账号，检查工作项、评论、附件的归属是否正确。停用账号重点看历史数据是否仍挂在原账号下，接替人账号重点看交接数据是否完整，公共账号重点看是否有明确责任人。
- 登录与通知核验：确认目标账号可正常登录，通知能送达。停用账号应确认其不可登录但数据可查。
- 核对映射表覆盖率：源账号总数与已处置、待确认数量对得上，没有遗漏记录，也没有重复处置。
- 核对归并结果：邮箱变更归并后，同一人只对应一个目标账号，旧邮箱作为别名或备注可查。
复发预防
迁移前先做人事数据与账号数据的对账，把在职状态、工号和邮箱变更记录对齐。建立稳定标识字段，后续账号变更走统一登记，避免迁移时再次出现新旧邮箱并存。映射表作为迁移资产保留，记录判定人和判定时间，为后续审计和二次迁移提供依据。
发现归属错误时，先定位受影响的批次和账号范围，按备份恢复映射表，再重新执行该批次的处置。回退范围以批次为界，不宜只改单条记录而忽略关联的工作项和评论。ONES迁移方案建议在正式迁移前确认数据范围、功能匹配和系统适配，并把迁移工具、原厂服务和分阶段切换结合起来。用户映射中的异常处置可以纳入这一准备过程，在正式迁移前完成分类判定和待确认清单清理，降低迁移后返工的概率。
常见问题
离职员工的账号在源系统里已经停用，迁移时还需要保留吗？
需要先判断历史数据是否仍需归属。停用账号往往仍挂着工作项、评论和附件，直接跳过会让这些数据失去归属。若业务上没有明确接替人，可在目标侧建立同名停用账号承接历史数据，并保留原账号标识作为映射依据；若有明确交接，则映射到接替人账号并记录交接关系。停用状态本身不构成删除理由，处置依据应写进映射表。
同一个人新旧邮箱都在源系统里，怎么确认是同一人而不是两个人？
以工号、员工编号、手机号或第三方登录唯一ID作为主键聚类，把新旧邮箱记录归到同一组，再结合人事系统的在职状态和账号创建、停用时间交叉验证。邮箱受域名更换和改名影响，稳定性不足，只作辅助字段。确认是同一人后选定一个目标账号归并，旧邮箱保留为别名或备注；无法确认的记录列入待人工确认清单，不进入批量归并。
离职账号挂到接替人之后，原账号的评论和附件还能追溯吗？
能否追溯取决于归并时是否保留了原账号标识和交接记录。操作上建议在映射表中记录源账号、接替人账号、交接依据和判定时间，合并前备份源映射表和账号记录，合并后保留一段观察期。迁移后抽样检查接替人账号下的工作项、评论和附件是否完整，发现归属错误时按批次回退重做。具体的数据归属表现以实际迁移方案为准。
映射表里待确认的记录比较多，迁移还能按计划推进吗？
可以分批推进：先把已确认的记录按处置类型执行，待确认记录单独挂起，不参与批量合并。迁移前尽量完成人事数据与账号数据的对账，把在职状态、工号和邮箱变更记录对齐，减少待确认数量。若待确认记录涉及关键项目的历史数据，建议在正式迁移前完成人工确认，避免迁移后再返工。待确认清单应记录缺失证据和负责人，作为迁移准备的一部分保留。
邮箱变更归并和离职账号处置可以放在同一批操作里执行吗？
建议分开执行。两类异常的操作对象不同：邮箱归并涉及账号合并，离职处置涉及数据归属转移，混在一批里出问题时难以定位影响范围。可以先完成邮箱归并并核对同一人只对应一个目标账号，再按处置类型分批处理离职账号，每批设置停止点并核对工作项与评论归属。批次划分方式可结合迁移方案中的用户处理规则确定。
