迁移用户映射时遇到离职账号和邮箱变更，先判断三件事：账号在源系统是否仍存在、身份能否唯一确认、历史数据应归属给谁。离职账号通常保留为历史归属主体并标注停用，邮箱变更以工号、域账号或原系统用户ID等稳定标识匹配。两类情况叠加时，先确认人员身份，再决定归属，避免历史工作项错挂到他人名下。
要点总览（TL;DR）
- 先按“账号是否仍存在、身份能否唯一确认、历史数据归属给谁”三件事分类，再决定映射动作。
- 离职账号保留为停用映射条目，历史工作项继续指向该条目；并入在职人员会让工作量统计和决策追溯失真。
- 邮箱变更以原系统用户ID、工号或域账号匹配，邮箱只作辅助证据；旧邮箱保留为曾用标识便于检索。
- 两类叠加时先确认人员身份再定归属，邮箱变更记录写入映射备注；身份无法确认的条目挂起交业务负责人。
- 改动前备份映射表，处置后抽样核对归属、通知接收与条目数量，验证不通过用备份恢复后重新处置。
先分清两类异常：离职账号与邮箱变更各自的表现
离职账号和邮箱变更都会表现为“映射对不上人”，但源系统中的痕迹不同，处置方向也不同。先识别异常类型，再判断影响范围，可以避免把身份问题当成数据问题处理。
| 异常类型 | 源系统表现 | 对映射的影响 | 优先级 |
|---|---|---|---|
| 离职账号 | 账号已停用、已删除，或仅保留历史记录 | 工作项归属丢失，或被迫挂到接手人、默认管理员名下 | 高：涉及历史数据归属 |
| 邮箱变更 | 同一人新旧邮箱并存；旧邮箱被他人复用；域名整体更换 | 按邮箱匹配时认错人，历史记录错挂，通知发错对象 | 高：涉及身份唯一性 |
| 两类叠加 | 离职账号同时存在邮箱变更记录 | 归属与身份两个问题同时出现，处置顺序容易混乱 | 最高：需先定身份再定归属 |
离职账号的典型状态有三种：账号已停用但记录仍在、账号已被删除只留历史引用、账号仅作为历史操作人出现在工作项和评论中。三种状态对映射的要求不同，前两种还能找到原始用户记录，第三种只能依赖历史数据中的用户ID或显示名回溯。
邮箱变更的表现更隐蔽。常见情况包括同一人同时存在新旧两个邮箱、旧邮箱被新入职员工复用、企业域名整体更换导致全员邮箱后缀变化。按邮箱做匹配键时，这三种情况都会造成错配：新旧邮箱并存会让同一人产生两条映射，邮箱复用会把前一位持有人的历史数据挂到新持有人名下，域名更换则会让整批用户匹配失败。
两类异常的影响集中在三处：工作项、评论、附件的创建人与经办人归属丢失或错挂；历史操作记录显示为陌生账号；通知和提醒发送给错误对象。这些问题在迁移完成后才暴露，回查成本较高，因此需要在映射阶段处理。
还需要与几类相邻异常区分开。重名是显示名相同但用户ID不同，处置靠用户ID区分；外部协作者是账号不在组织目录内，处置靠来源标记；组织调整是人员换了部门但账号未变，通常不需要改映射归属。这三类问题的证据和动作与离职、邮箱变更不同，混在一起处理容易扩大改动范围。
判断归属：哪些证据能确认身份，哪些只是假设
映射改动的核心风险是把猜测当成结论。判断身份时，优先使用不随人员状态变化的稳定标识，邮箱、显示名这类可变字段只作辅助证据。下表给出常用证据字段的可信度和适用场景。
| 证据字段 | 可信度 | 适用异常类型 | 使用说明 |
|---|---|---|---|
| 原系统用户ID | 高 | 离职账号、邮箱变更、两类叠加 | 系统内部唯一标识，不随邮箱和显示名变化，优先作为主键 |
| 工号 | 高 | 邮箱变更、组织调整 | 需确认源系统工号字段填写完整且未被复用 |
| 域账号 | 较高 | 邮箱变更 | 企业目录统一管理时可作为匹配依据，需确认离职后是否回收 |
| 创建人记录、历史操作日志 | 中 | 离职账号 | 用于回溯历史数据归属，需与人员清单交叉核对 |
| 邮箱 | 低 | 仅作辅助 | 可变更、可复用、可多人共用，不能单独作为身份依据 |
| 显示名 | 低 | 仅作辅助 | 存在重名和改名情况，不能单独作为身份依据 |
邮箱只能作辅助证据，原因很直接：员工换邮箱后旧地址可能被回收再分配，团队共用邮箱会被多人使用，域名更换会让同一人的地址整体变化。把邮箱当主键，等于把最容易变化的字段当成身份依据。稳定标识缺失时，才退回到“用户ID加历史操作记录加人员清单”的组合比对。
离职账号的处置有一个基本取舍：保留为历史归属主体并标记停用，还是并入某位在职人员。并入在职人员的做法看起来能让数据“有人管”，实际会把离职人员的历史工作项、评论和操作记录转移到他人名下，后续统计工作量、追溯决策过程时都会失真。保留停用映射条目的代价只是目标系统中多一条非活跃用户记录，历史归属保持准确。除非业务负责人明确要求交接，否则不主动合并。
确认身份可以用抽样比对的方法：从源系统取若干条该用户创建或经办的工作项，与目标系统中同一条数据的创建人、操作时间、评论内容对照，确认迁移前后指向同一人。抽样应覆盖离职前最后一段活跃期和邮箱变更前后的时间段，这两个区间最容易出现归属断裂。
无法确认身份时要有明确的停止点。证据互相矛盾、用户ID在源系统中重复、邮箱持有人无法对应到具体人员，这些情况都不应擅自合并或删除映射条目。正确做法是把条目挂起，记录已收集的证据和疑点，交由业务负责人或原系统管理员确认后再处置。挂起条目需要单独登记，避免在批量处理中被遗漏。
按异常类型处置：离职账号、邮箱变更及叠加情况的处理步骤
处置动作建立在上一节的判定规则之上。动手前先导出并备份当前映射表，记录备份时间和版本；批量改动前先用少量条目试跑并核对结果。以下按异常类型给出操作顺序。
离职账号：保留停用映射条目
- 在映射表中为该用户创建或保留一条映射条目，目标账号状态标记为停用，备注中写明离职时间和源系统账号状态。
- 历史工作项、评论、附件的创建人和经办人继续指向该条目，不改为在职人员。
- 核对源系统中该用户名下的工作项数量与映射后归属数量是否一致，差异条目逐条查明原因。
- 如业务方确认需要交接，交接动作放在迁移完成后单独执行，并在备注中记录交接对象和时间，不与迁移映射混在一起。
邮箱变更：按稳定标识匹配，保留曾用邮箱
- 以原系统用户ID、工号或域账号作为匹配键，在目标系统中找到对应用户。
- 更新目标账号的邮箱为新地址，旧邮箱作为曾用标识保留在映射备注或用户扩展信息中，便于后续按旧地址检索历史记录。
- 检查源系统中是否存在同一人的两条用户记录（新旧邮箱各一条），如有则合并为一条映射，合并前确认两条记录下的工作项归属一致。
- 验证该用户登录和通知接收正常，确认提醒发送到新邮箱。
两类叠加：先定身份，再定归属
- 以原系统用户ID为主键定位该用户，确认其在源系统中的账号状态和邮箱变更历史。
- 先判断人员身份是否唯一可确认：用户ID唯一、工号可对应、历史操作记录一致，三项满足即可进入归属处置。
- 身份确认后，按离职账号规则保留停用映射条目，同时把邮箱变更记录写入映射备注，包括旧邮箱、新邮箱和变更时间。
- 身份无法确认时挂起该条目，不执行合并或删除，登记疑点后交业务负责人确认。
邮箱被他人复用：按用户ID切开
旧邮箱被新员工复用时，按邮箱匹配会把两位用户的数据混在一起。处置时以用户ID区分两条映射，前一位持有人按离职账号规则保留停用条目，新持有人建立独立映射并绑定新邮箱。映射备注中注明邮箱复用关系，避免后续按邮箱检索时再次混淆。
批量处理与逐条处理的适用条件
规则明确、证据一致的场景适合批量处理，例如企业域名整体更换、全员邮箱后缀统一变化，这类情况可以按域名规则批量替换并抽样验证。涉及离职账号、邮箱复用、身份证据不一致的条目应逐条处理，因为每条的归属判断依赖具体证据。批量改动前必须完成映射表备份，改动后保留操作日志，便于回退和审计。
在迁移执行过程中，人员清单核对和映射条目状态跟踪往往跨多个角色。ONES 的迁移方案覆盖用户、用户组以及项目、工作项、评论等数据的迁移，并提供企业级账号目录 ONES Account 作为账号管理的基础模块。实施时可以把离职账号的停用状态、邮箱变更备注、挂起待确认条目统一登记在迁移清单中，由迁移负责人维护状态，业务负责人确认归属，验证记录随迁移文档留存，使映射处置过程可查、可交接。
处置后怎么验证，以及如何减少下次迁移的同类问题
映射处置完成后，需要验证归属正确、通知可达、数量一致，并为验证不通过的情况准备回退路径。验证通过后再进入整体迁移结果核验环节。
验证清单
- 抽样核对离职人员的历史工作项：创建人、经办人、评论作者是否仍指向停用映射条目，抽样覆盖离职前活跃期。
- 核对邮箱变更用户：能否正常登录，通知和提醒是否发送到新邮箱，按旧邮箱检索历史记录是否仍能命中。
- 核对映射条目数量：映射表中的用户条目数与源系统用户数比对，差异部分逐条说明原因，包括挂起条目和合并条目。
- 核对邮箱复用场景：新旧持有人各自的工作项归属是否分开，无交叉挂载。
- 核对挂起条目：是否全部有负责人和确认结论，未确认条目不得进入正式切换。
验证不通过时的回退方式
发现归属错误或条目缺失时，用改动前的映射表备份恢复，恢复到备份版本后重新按判定规则处置问题条目，不在错误映射上继续叠加修改。回退后重新执行上述验证清单，确认恢复范围覆盖全部已改动条目。回退操作同样需要记录时间和操作人，便于追溯。
复发预防措施
- 迁移前导出人员清单，核对在职状态、邮箱、工号和域账号，提前标记离职账号和近期邮箱变更人员。
- 建立身份主键规范：明确以原系统用户ID或工号作为映射主键，邮箱和显示名只作辅助字段，写入迁移方案。
- 把异常处置规则写入迁移方案，包括离职账号保留策略、邮箱变更备注要求、挂起条目的确认流程和备份要求。
- 在迁移方案中约定与流程迁移、结果核验环节的交接边界：用户映射确认完成后，再启动依赖人员归属的流程和权限迁移，整体核验阶段复核映射条目与业务数据的对应关系。
这套处置路径解决的是映射数据本身的归属问题。工作流、插件行为的迁移配置，以及迁移结果的整体核验与切换管理，属于相邻环节，需要在各自方案中单独安排。
常见问题
离职账号在源系统已被删除、只剩历史引用，映射时还能保留归属吗？
可以按历史引用回溯。先从工作项、评论、附件中提取该用户的原始用户ID或显示名，再与迁移前导出的人员清单交叉核对，确认对应的是哪一位离职人员。确认后在映射表中建立停用状态的条目，把历史数据归属挂到该条目上。
如果源系统连用户ID都没有保留，只能依赖显示名回溯，这时需要把该条目列为待确认，由原系统管理员或业务负责人核对后再定归属，不直接并入在职人员。
邮箱变更后旧邮箱被新员工复用，怎么避免两人的历史数据混在一起？
按用户ID把两条映射切开。前一位持有人按离职账号规则保留停用条目，新持有人建立独立映射并绑定新邮箱，映射备注中注明邮箱复用关系。处置后抽样核对两位用户名下的工作项归属，确认没有交叉挂载。
如果源系统中两人共用同一条用户记录，说明数据本身已经混在一起，这类条目应挂起，交由业务负责人确认拆分方式后再处理。
批量替换邮箱后缀时，哪些条目可以批量处理，哪些必须逐条看？
规则明确、证据一致的场景适合批量处理，例如企业域名整体更换、全员邮箱后缀统一变化，可以按域名规则批量替换后抽样验证。涉及离职账号、邮箱被复用、身份证据互相矛盾的条目应逐条处理，因为每条的归属判断依赖具体证据。
批量改动前先备份映射表并保留操作日志，改动后按抽样结果决定是否需要回退。
映射条目挂起后一直没人确认，会不会影响正式切换？
会。挂起条目意味着该用户的历史数据归属尚未确定，带着未确认条目进入切换，后续回查成本更高。建议在迁移方案中约定挂起条目的确认责任人和时限，由业务负责人给出结论；未确认的条目单独登记，不随批量处理一起推进。
如果确认时限内无法定论，可以在切换前把该条目及其影响的数据范围记录下来，作为遗留事项跟踪，而不是默认并入某个在职账号。
迁移完成后发现个别离职人员的工作项挂错了人，怎么回退？
用改动前的映射表备份恢复，恢复到备份版本后重新按判定规则处置问题条目，不在错误映射上继续叠加修改。回退后重新执行验证：抽样核对离职人员历史工作项的创建人与经办人、变更邮箱用户的登录与通知接收、映射条目数量与源系统是否一致。
回退操作记录时间和操作人，便于追溯改动范围。
