研发权限迁移要先把源平台里“谁、在什么范围、对什么对象、能做什么操作”这组关系完整提取出来，再映射成目标平台的角色、成员组和资源授权，按“盘点—映射—试迁移—核验—切换与回退”推进。本文覆盖组织与项目角色、代码仓库、流水线、制品与环境权限的迁移步骤，历史操作记录搬运和上线后的日常权限治理不在范围内。
要点总览（TL;DR）
- 研发权限迁移按“盘点—映射—试迁移—核验—切换与回退”推进，先把源平台的角色定义、成员归属、资源层级授权拆成三张基础表，再对齐成一张权限映射表。
- 角色映射要标注差异并写明处理方式，成员映射以邮箱或企业目录唯一标识对齐，资源映射要确认继承关系是否一致；涉及生产环境、分支保护例外、审批放行的条目双人复核。
- 试迁移选三类代表性项目各一个，按角色、成员、资源授权的顺序执行，用真实数据验证映射表，修订后再全量。
- 核验以关键账号的实际操作结果为准，管理员、开发者、只读成员、外部协作方各抽两人，越权与缺权分开检查并留存记录。
- 切换前映射表待确认项清零、核验通过、回退预案演练过；并行期源平台冻结新增授权只做回收，触发回退条件时按预案恢复并重新核验。
迁移范围：哪些权限要迁，哪些不迁
动手前先写清楚迁移边界，否则后面盘点会不断膨胀。范围清单至少包含四项：源平台与目标平台分别是什么、各自版本与账号体系前提；纳入本次迁移的权限对象；明确排除的内容；迁移方向与各环节责任人。
账号体系前提需要提前确认：源平台使用本地账号、企业目录还是 SSO 登录，目标平台是否已接入同一套身份源。两边账号标识不一致时，成员映射会多出一轮人工核对，这个工作量应计入排期。
纳入迁移的权限对象通常分四类：
- 组织与项目角色：组织管理员、项目管理员、普通成员、只读成员等角色定义及授予关系。
- 代码仓库权限：仓库可见性、读写权限、分支保护规则、合并请求审批权限。
- 流水线权限：流水线创建与编辑、手动触发、审批放行、密钥与变量查看。
- 制品与环境权限：制品库读写、测试与生产环境的部署和访问权限。
不纳入本阶段的内容要单独列出：历史操作日志与审计记录的搬运、业务数据与工单记录的迁移、目标平台上线后的日常权限申请与定期治理。这些工作与权限迁移相邻但交付物不同，混在一起会让验收标准失焦。
责任角色建议按三层划分：迁移负责人统筹范围与排期；平台管理员负责源平台数据导出和目标平台配置；各项目负责人确认本项目成员与关键权限的准确性。范围清单经这三方签字后再进入盘点。
迁移前要准备什么：账号、角色与资源清单
这一阶段的产出是三张基础表，后续映射、试迁移和核验都以它们为输入。表格字段在导出时就按目标格式整理，能减少二次返工。
成员表
从源平台导出全部成员，字段包括：账号标识、姓名、邮箱、所属组织或团队、账号状态（在职、离职、外部协作）、登录方式。外部协作账号和已离职但权限未回收的账号要单独标记，这两类最容易在迁移中被误授或漏收。
角色权限点表
逐个角色记录其权限点，而不是只记角色名称。字段包括：角色名称、适用层级（组织级或项目级）、包含的具体操作权限、是否可自定义。源平台允许自定义角色时，要把每个自定义角色的实际权限点展开，否则映射时只能凭名称猜测。
资源层级表
列出项目、仓库、流水线、环境及其归属关系。字段包括：资源名称、所属项目、上级资源、继承关系（如项目权限是否自动下传到仓库）、当前授权对象。层级关系决定了授权是逐项配置还是通过继承批量生效，这张表填错，映射阶段的授权范围就会出错。
目标平台侧的前置条件同步准备：账号已开通并可登录、组织架构已建立、角色模板已定义。权限迁移依赖账号同步和 SSO 先完成，如果身份源对接还在调试，成员映射只能做纸面推演，无法进入试迁移。
权限映射方法：角色、成员与资源三层对齐
映射的核心是把三张基础表对齐成一张权限映射表，每一行回答“某个成员在某个资源上应获得哪个角色”。三层分开处理，遇到问题时能定位到具体是哪一层没对上。
角色映射
建立源角色到目标角色的对应表，并标注差异。两个平台的角色很少完全对等，常见差异是源平台一个角色包含的权限点在目标平台被拆成两个角色，或目标平台某角色额外带有源平台没有的权限。差异项要写明处理方式：拆分授予、降级授予还是提交人工确认。
| 源角色 | 目标角色 | 差异说明 | 处理方式 |
|---|---|---|---|
| 项目管理员 | 项目负责人 | 目标角色额外包含项目归档权限 | 接受，归档操作另行审批 |
| 仓库维护者 | 开发者＋分支保护例外 | 目标平台无单一对应角色 | 拆分授予，例外名单单独登记 |
| 流水线审批人 | 发布审批角色 | 权限点基本一致 | 直接对应 |
成员映射
以邮箱或企业目录唯一标识作为对齐依据，逐条核对账号标识。一人拥有多个源账号时合并为一个目标账号并保留权限并集，合并前需本人确认。离职账号不迁移，外部协作账号按项目单独授予并设置有效期。
资源映射
把源平台的项目、仓库、环境对应到目标平台的同名或新建资源，并确认继承关系是否一致。源平台在项目层授予、自动下传到仓库的权限，目标平台若没有同样的继承机制，就需要在仓库层逐项补授，这类补授条目要在映射表中单独成行。
一人多角色时按最小权限取舍：保留其岗位职责实际需要的最高权限，其余角色合并或去除。取舍结果由项目负责人确认，映射表中标记“待确认”的条目在试迁移前必须清零，人工复核规则可以定为：涉及生产环境、涉及分支保护例外、涉及审批放行的条目一律双人复核。
在目标平台侧落地这张映射表时，角色定义、成员组和项目授权需要能分层管理。ONES 的项目与成员组配置可以承载角色和成员归属，Jira 迁移场景中官方方案说明可迁移用户、用户组和系统配置，包括权限配置；具体映射粒度仍需在正式迁移前逐项确认。
试迁移：先跑小范围再全量
试迁移的目的是用真实数据验证映射表，而不是提前完成全量切换。试点范围按风险代表性选取：一个权限结构简单的项目、一个含外部协作账号的项目、一个涉及生产环境部署的项目，三类各选一个即可，不必按团队规模铺开。
执行顺序固定为角色、成员、资源授权。先建角色，再按成员表导入人员并归组，最后按资源层级表逐项授权。顺序颠倒会出现成员已就位但角色未定义、只能临时授权的混乱。
试迁移过程中记录三类现象：配置报错或字段无法填写；映射表中没有覆盖到的权限组合；导入后与预期不一致的授权结果。每条记录写明资源、账号、预期结果和实际结果，作为修订映射表的依据。
试迁移结束后回填映射表：修正错误的角色对应、补充遗漏的资源层级、清理无法落地的条目。修订版映射表经复核后才能用于全量迁移。试迁移不通过时，回到映射阶段调整，不带着已知问题扩大范围。
核验与证据：怎么判断权限迁对了
核验以关键账号的实际操作结果为准，配置页面显示正确只作为辅助证据。抽样覆盖四类账号：管理员、普通开发者、只读成员、外部协作方，每类至少两人，其中一人应为试迁移阶段未参与配置的成员，避免配置者按自己的理解验证自己。
按操作逐项验证，每项记录预期结果与实际结果：
- 代码仓库：克隆、推送、创建分支；只读账号推送应被拒绝；分支保护规则对直接推送的拦截是否生效。
- 流水线：手动触发、编辑配置、审批放行；无审批权限的账号应看不到放行入口。
- 环境访问：测试环境部署、生产环境部署与查看；越权访问应被拒绝并留下记录。
- 项目与组织：成员管理入口的可见性、角色变更操作是否仅限管理员。
越权和缺权分开检查。缺权表现为该做的操作做不了，越权表现为不该做的操作能做成。两类问题都记录到核验记录表，附操作时间、账号、资源、操作内容和结果，截图或操作日志作为附件留存。
核验不通过时按问题类型分流：映射错误回到映射表修正后重试该项；目标平台配置缺失由平台管理员补配；权限模型本身不支持的操作，提交迁移负责人评估是否调整方案或接受差异。所有未关闭项在切换前必须有明确结论。
切换与回退：什么时候可以停用旧权限
切换的前提条件逐项确认后才可执行：映射表待确认项清零；试迁移问题全部关闭；核验记录表中关键账号的操作验证全部通过；回退预案已书面确认并演练过至少一次。
并行期内新旧平台同时可用，权限处理遵循两条规则：新平台的权限变更在目标平台执行并登记；源平台在并行期冻结新增授权，只做回收，避免两边权限持续分叉。并行期长度按团队适应情况设定，并以核验通过作为缩短并行期的依据。
回退触发条件提前写死，例如：关键账号在生产环境出现越权访问、核心流水线因权限问题无法发布、外部协作方大面积无法访问仓库。触发后按预案执行：恢复源平台对应权限、暂停目标平台该范围的授权变更、记录回退原因与影响范围，问题修复后重新走核验再切换。
切换完成后回收旧权限：停用源平台的迁移相关账号、撤销并行期临时授权、清理试迁移遗留的测试账号。此后按固定周期复核权限，重点检查外部协作账号有效期、生产环境授权名单和分支保护例外清单。ONES 的迁移方案建议把迁移工具、原厂服务和分阶段切换结合，并在正式迁移前确认数据范围、功能匹配和系统适配；仓库、流水线、制品与环境等权限对象的迁移支持范围，需在实施前与实施方逐项核实并约定回退安排。
常见问题
源平台和目标平台的角色不是一一对应，映射时怎么处理？
先建源角色到目标角色的对应表，逐条标注差异，再写明处理方式。常见差异有三类：源平台一个角色在目标平台被拆成两个角色，按拆分授予处理；目标角色额外带有源平台没有的权限，评估是否接受并配套审批；两边都找不到对应角色，提交人工确认并登记例外名单。差异项不能只写角色名称，要把实际权限点展开对照，否则试迁移时才发现偏差，返工成本更高。
迁移前账号体系还没对接好，能不能先做权限映射？
可以做纸面推演，但进不了试迁移。成员映射依赖账号标识对齐，源平台用本地账号、目标平台走 SSO 时，两边标识不一致会多出一轮人工核对。建议把身份源对接排在权限迁移之前，账号开通、组织架构、角色模板就位后再导入成员。如果对接还在调试，先完成角色映射和资源层级表，成员映射标注为待确认，等账号可登录后再补齐。
试迁移要选多少项目，选什么样的项目？
按风险代表性选，不必按团队规模铺开。建议三类各选一个：权限结构简单的项目，验证基础映射是否走通；含外部协作账号的项目，验证有效期设置和单独授权；涉及生产环境部署的项目，验证环境访问和审批放行。三类覆盖了大部分权限组合，试迁移记录的问题足以支撑映射表修订。
核验时配置页面显示权限正确，还需要实际操作验证吗？
需要。配置页面显示正确只作为辅助证据，验收以关键账号的实际操作结果为准。按操作逐项验证：只读账号推送应被拒绝、分支保护对直接推送的拦截是否生效、无审批权限的账号是否看不到放行入口、越权访问生产环境是否被拒绝并留下记录。抽样时至少安排一名未参与配置的成员，避免配置者按自己的理解验证自己。
并行期内旧平台的权限还要不要继续维护？
并行期源平台冻结新增授权，只做回收。新平台的权限变更在目标平台执行并登记，避免两边权限持续分叉。并行期长度按团队适应情况设定，核验通过可以作为缩短并行期的依据。切换完成后停用源平台迁移相关账号、撤销并行期临时授权、清理试迁移遗留的测试账号，再按固定周期复核外部协作账号有效期和生产环境授权名单。
