# 旧系统菜单权限迁移，先核对哪几类映射关系

- Link: https://www.itor.cn/604.html
- Published: 2026-10-16T15:16:14+08:00
- Author: it

系统升级时，权限迁移最容易出问题的环节，往往不是代码，而是映射关系没对齐。旧系统
按部门建菜单，销售部看销售入口，财务部看财务入口，各自清楚。新系统改成按角色分权，
迁移一完成，员工登录却发现该有的入口没了，不该出现的反而冒了出来。根子通常不在技术，
而在迁移前没有把三类对象的对应关系逐条核对清楚。

先分清三类对象

菜单权限迁移只围绕三类对象展开：菜单节点、角色组、人员归属。菜单节点是系统里一个
个可点击的入口；角色组是权限的集合；人员归属决定谁被分到哪个角色。任何一类漏核对，
都可能造成越权或漏权。只搬了菜单名称，没核对角色组，原本属于主管的审批入口可能被
普通员工看到；只核对了人员归属，漏了菜单节点，某些历史入口就会彻底消失。

核对菜单路径与业务动作的对应关系

旧系统的菜单名称常带历史痕迹，“综合查询”“内部事务”这类名字，光看字面根本不知道对应
什么操作。迁移时不能只搬名称，要逐条确认这个菜单背后实际执行的动作：是查看数据、
提交申请，还是审批流转。建议做一张对照表，左边写旧菜单路径，右边写新系统对应的功能
模块和操作权限。凡是无法确认业务动作的菜单，先标记出来，不要直接映射。

核对默认权限与例外授权

历史系统里常有一批临时放行：某员工因项目需要被单独开了权限，项目结束后没人收回。
迁移时若直接按当前权限复制，这些例外授权会被一并带过去。正确做法是先梳理默认权限，
即角色本身应包含的菜单范围，再单独列出所有例外授权，逐条确认是否仍然需要。凡是找不到
依据的例外，迁移时应取消，而不是默认保留。

用同一批测试账号做对照验证

迁移完成后，不要只靠管理员账号测试。选一批覆盖不同部门、不同职级的测试账号，分别
在旧系统和新系统里登录，记录每个账号能看到哪些菜单、能执行哪些操作。把两份记录并排
对照，差异清单就是需要修正的地方。重点看三类差异：旧有新无、旧无新有、两边都有但
操作范围不同。这份清单比任何口头确认都可靠。

把权限调整流程写进交付文档

迁移结束不代表权限管理结束。后续人员调岗、新角色增加、临时授权回收，都需要有明确
依据。交付文档里应写清楚：菜单节点由谁维护，角色组变更走什么审批，例外授权最长保留
多久，离职或调岗后由谁在几个工作日内完成权限回收。把这些规则写下来，后续维护才不会
又变成一笔糊涂账。

权限迁移看起来是技术活，本质是管理活。菜单、角色、人员三类对象对齐了，业务动作核对
清楚了，默认权限和例外授权分开了，再用测试账号验证一遍，最后把维护规则落到文档里，
员工该看到的入口才不会丢。it数运在参与企业数字化项目时，通常会把这类映射核对作为
交付前的固定动作，因为权限一旦错位，后续排查成本远高于迁移前多花的那几个小时。