系统升级时，权限迁移最容易出问题的环节，往往不是代码，而是映射关系没对齐。旧系统按部门建菜单，销售部看销售入口，财务部看财务入口，各自清楚。新系统改成按角色分权，迁移一完成，员工登录却发现该有的入口没了，不该出现的反而冒了出来。根子通常不在技术，而在迁移前没有把三类对象的对应关系逐条核对清楚。
先分清三类对象
菜单权限迁移只围绕三类对象展开：菜单节点、角色组、人员归属。菜单节点是系统里一个个可点击的入口；角色组是权限的集合；人员归属决定谁被分到哪个角色。任何一类漏核对，都可能造成越权或漏权。只搬了菜单名称，没核对角色组，原本属于主管的审批入口可能被普通员工看到；只核对了人员归属，漏了菜单节点，某些历史入口就会彻底消失。
核对菜单路径与业务动作的对应关系
旧系统的菜单名称常带历史痕迹，“综合查询”“内部事务”这类名字，光看字面根本不知道对应什么操作。迁移时不能只搬名称，要逐条确认这个菜单背后实际执行的动作：是查看数据、提交申请，还是审批流转。建议做一张对照表，左边写旧菜单路径，右边写新系统对应的功能模块和操作权限。凡是无法确认业务动作的菜单，先标记出来，不要直接映射。
核对默认权限与例外授权
历史系统里常有一批临时放行：某员工因项目需要被单独开了权限，项目结束后没人收回。迁移时若直接按当前权限复制，这些例外授权会被一并带过去。正确做法是先梳理默认权限，即角色本身应包含的菜单范围，再单独列出所有例外授权，逐条确认是否仍然需要。凡是找不到依据的例外，迁移时应取消，而不是默认保留。
用同一批测试账号做对照验证
迁移完成后，不要只靠管理员账号测试。选一批覆盖不同部门、不同职级的测试账号，分别在旧系统和新系统里登录，记录每个账号能看到哪些菜单、能执行哪些操作。把两份记录并排对照，差异清单就是需要修正的地方。重点看三类差异：旧有新无、旧无新有、两边都有但操作范围不同。这份清单比任何口头确认都可靠。
把权限调整流程写进交付文档
迁移结束不代表权限管理结束。后续人员调岗、新角色增加、临时授权回收，都需要有明确依据。交付文档里应写清楚：菜单节点由谁维护，角色组变更走什么审批，例外授权最长保留多久，离职或调岗后由谁在几个工作日内完成权限回收。把这些规则写下来，后续维护才不会又变成一笔糊涂账。
权限迁移看起来是技术活，本质是管理活。菜单、角色、人员三类对象对齐了，业务动作核对清楚了，默认权限和例外授权分开了，再用测试账号验证一遍，最后把维护规则落到文档里，员工该看到的入口才不会丢。it数运在参与企业数字化项目时，通常会把这类映射核对作为交付前的固定动作，因为权限一旦错位，后续排查成本远高于迁移前多花的那几个小时。
