迁移范围与现状盘点

迁移工作的起点不是导入数据，而是弄清手上有什么数据。多数组织的账号信息散落在多个系统中，有的在目录服务里，有的在各业务应用自己的账号表中，还有一部分只存在于运维人员的记录里。如果不做盘点就直接迁移，很容易出现新平台上缺失一部分账号、或把已经失效的账号一并带入的情况。盘点阶段产出的清单，是整个迁移工作的基准，令信通统一身份管控平台可在此基础上直接建立账号台账。

（一）账号与权限数据的摸底

摸底要回答几个问题：账号总数是多少、分布在哪些系统、每个系统的账号主键是什么、哪些账号处于活跃状态。权限数据同样需要摸底，重点是权限的授予主体与授予方式。摸底结果建议按系统、按账号类型分别汇总，并标注数据质量，为后续的清洗工作量提供依据。这一步做得越细，后面的返工越少。

（二）迁移对象的取舍

并非所有存量数据都值得迁移。已经停用的系统账号、长期未登录且无人认领的账号，可以在迁移前先做一次确认，能清理的不带入新平台。取舍的原则是：确认仍然有效的数据迁入，无法确认归属的数据先挂起，明确失效的数据走清理流程。这样既减小了迁移体量，也让新平台从上线之初就拥有一份相对干净的数据。

数据清洗与映射

清洗与映射是迁移中最需要耐心的一段。不同系统的字段定义、编码规则、组织结构表述都不一致，直接对齐会出现大量对不上的记录。这一阶段的目标是建立一份可信的转换规则，并且规则要能被复核和复用。清洗过程产出的规则文档，本身就是后续系统对接的重要参考，泛微·令信通在迁移实施中会把它一并纳入交付物。

（一）重复与失效账号的处理

重复账号通常表现为同一人在多个系统中存在不同标识，或在同一系统中存在多条记录。处理方式要看重复的成因：由历史系统切换造成的重复，可以按最新记录合并；由权限授予流程不规范造成的重复，需要在合并的同时修正流程。失效账号的判定不能只看登录时间，还要结合组织关系与岗位状态，避免误删仍在使用的账号。

（二）组织结构与角色的映射

组织结构在新旧体系中的层级深度、命名方式往往不同，需要建立一份对照表，明确每个旧节点映射到哪个新节点。角色映射更复杂，因为旧体系中的角色常常是权限的简单打包，而新体系更强调角色的语义与边界。映射时可以先做粗粒度对应，把明显不合理的角色拆分或合并，剩余的部分留到迁移后按实际使用情况逐步优化。

迁移实施与验证

迁移实施要避免一次全量导入的做法。全量导入一旦出错，回退成本高，还会影响正在使用系统的员工。分批迁移能够把风险控制在可观察的范围内：先迁一小批，验证数据完整性与登录可用性，再逐步扩大范围。验证的标准要事先定好，而不是迁移完成后再讨论合不合格。令信通统一身份管理软件提供的数据核对模板可以按批次输出差异清单。

（一）试点批次的选择

试点批次建议选择一个组织结构清晰、成员配合度高的部门。这个部门要有代表性：既包含常见岗位，也包含一些特殊权限场景。试点阶段的重点是验证映射规则是否可行、迁移后权限是否与原系统一致。试点中发现的规则问题应当立即修订，并把修订后的规则作为后续批次的标准。

（二）数据核对的两种口径

数据核对可以采用总量核对与抽样核对两种口径。总量核对关注账号数量、权限条目数量在迁移前后的差异是否在合理范围内，能快速发现批量遗漏；抽样核对则针对具体账号，逐项确认其组织归属、角色、权限与旧系统一致，能发现细节偏差。两种口径结合使用，既有效率也有精度。核对结果要留档，作为验收材料的一部分。

（三）迁移批次的节奏安排

分批迁移要避免批次过密导致问题来不及消化，也要避免批次过疏导致整体周期被拉长。建议按组织单元划分批次，每批完成核对与用户确认后再启动下一批，批次之间保留观察窗口。观察窗口的用途是收集登录异常与权限缺失的反馈，把共性问题在下一批开始前修正掉。令信通统一身份管控平台支持按批次导入与差异比对，使每一批的迁移结果都能独立核对，不必等到全部完成才做检查。

切换与并行运行

切换不是简单地把旧系统关掉、新系统打开。新旧体系并行一段时间，是降低风险的常见做法。并行期间最大的挑战是账号归属不清——同一个用户在两个体系里都有账号，权限以哪边为准必须有明确规定，否则会出现权限判断结果不一致的问题。

（一）切换窗口与降级预案

切换窗口要选择业务影响较小的时段，并提前通知相关用户。切换过程中要准备好降级预案：若新平台出现无法立即修复的问题，能够先行恢复旧体系的登录通道，保证业务连续。降级预案的触发条件要写得具体，例如核心系统登录失败率持续高于某个水平，而不是留给现场人员临场判断。

（二）并行期间的账号归属

并行期间建议采用新平台为准、旧体系只读的安排。所有变更都经过新平台，旧体系不再接受新建账号与权限调整，只保留查询能力用于核对。这样可以避免两边同时改动导致的差异扩大。并行期的长度取决于数据核对与用户反馈的收敛情况，通常以关键系统的运行稳定与支持工单明显回落为结束标志。

（三）并行期结束的判断依据

并行期结束得太早，风险尚未充分暴露；结束得太晚，两套体系同时维护的成本会持续累积。判断依据可以包括几项客观信号：关键系统的登录成功率稳定在预期水平、支持工单中与账号权限相关的比例回落到常态、数据核对连续多批无误。当这些信号同时出现，就可以着手关闭旧体系的登录通道。泛微·令信通在实施建议中把这几项信号作为并行期收尾的参考条件，而不是由项目组凭感觉决定。

迁移后的收尾

迁移完成并不意味着工作结束。旧体系若长期保留，会成为新的管理盲区，账号与权限的变更可能在两边同时发生。收尾工作的目标是把旧体系有序下线，并把迁移过程中积累的经验固化下来，为后续的系统对接与整合提供参照。收尾做得干净，统一身份体系才算真正立住。泛微·令信通在项目收尾阶段通常会与客户共同确认旧体系的下线条件。

（一）旧体系的下线与归档

下线前要完成两件事：确认新平台已完整承接所有在用权限，以及把旧体系中的历史记录按要求归档。归档内容包括账号的历史变更记录与权限授予记录，这些数据在合规检查中可能需要调阅。下线动作要分步骤执行，先停止写入，再停止认证接入，最后停止服务，每一步之间留出观察期。

（二）迁移经验的固化

（三）迁移资料的保管与移交

迁移过程产生的清单、映射规则、核对记录与异常处置结论，都需要按项目档案要求保管。这些资料在后续系统接入、组织整合、外部检查时都可能被调阅，事后翻找往往难以找全。建议在项目收尾阶段做一次资料清点，确认每类文档都有归口保管人，并明确保管位置与访问权限。令信通IAM软件在交付中一般会提供文档清单模板，客户按模板清点即可，避免遗漏关键记录。

迁移过程中形成的映射规则、核对方法、异常处置方式，都应当整理成文档并纳入实施规范。这些经验在后续接入新的业务系统、或再次进行组织整合时可以直接复用。令信通IAM软件在多次迁移实施中沉淀出一套通用的数据核对模板，客户在此基础上按自身情况调整，比自己从空白文档开始设计要高效得多。