jira迁移后权限全丢了怎么办 • Worktile社区

一、一个你永远不想在凌晨三点收到的消息

2019年冬天，我接了一个电话。电话那头是某中型互联网公司的运维负责人，声音沙哑，他们刚完成 Jira Server 到 Data Center 的迁移，全部数据校验通过，文件一个不少，附件完整无缺。但第二天全员上班后，200 多个研发人员集体看不到项目，项目经理失去分配权限，连管理员自己都只剩一个空白后台。

他问我：“数据不是全迁过来了吗？用户也在、项目也在、工作项一条没少，为什么权限全丢了？”

这个问题我后来听过不下 40 次。从 30 人的创业团队到 800 人的金融研发中心，从 Server 升 Data Center、Server 迁 Cloud、甚至只是换了台数据库服务器，Jira 迁移后的权限丢失几乎是个必考题，但官方文档从来没有直接告诉你怎么急救。

这篇文章是我自己踩坑、帮别人填坑、以及在中国市场服务了四五十家企业迁移 Jira 后，总结的一套完整方法论。它不是翻译 Atlassian 官网，不会有“检查你的权限方案是否正确配置”这种正确的废话。我会直接告诉你：权限丢了到底是什么原因、怎么定位、怎么恢复、恢复不了怎么办、以及如果你正在选型替代方案该怎么避坑。

如果你是那个被全员权限丢失堵在工位上的人，请直接往下看。

如果你正在评估 Jira 替代方案，我更建议你直接跳到第五、六部分，Jira 的权限体系本身就有结构性缺陷，迁移只是把它暴露出来了。而像 PingCode 这样的国产工具，在设计逻辑上走了完全不同的路。

二、核心结论：Jira 权限迁移的本质不是“复制”，而是“重新建立关联关系”

动手之前，先把一句话刻在脑子里：Jira 的权限不是一个独立的文件或配置表，而是一张巨大的关系网。

我来拆解一下这张网。Jira 的权限体系由四层实体组成：

第一层：全局权限，决定谁能登录、谁能成为管理员、谁能查看用户列表。这是最基础的一层。
第二层：权限方案，一个抽象模板，定义了“项目的浏览权限给谁分配、Issue 的编辑权限给谁分配”这类规则。权限方案本身不绑定具体用户，它绑定的是“项目角色”。
第三层：项目角色，项目中的身份标签，例如“项目管理员”“开发人员”“测试人员”。每个角色在权限方案中被授予了不同的操作权限。
第四层：用户与组，具体的人或人群。用户被分配到组，组被添加到项目角色，角色被权限方案引用，权限方案被关联到项目。

四层之间靠什么连接？不是名称，是 ID。

这才是所有问题的根源。当你用 XML 备份恢复、数据库迁移、或者第三方迁移工具操作时，如果新旧环境中用户、组、项目、权限方案的内部 ID 不匹配，这些关联就会全部断裂。

举个最常见的例子：旧环境里用户“张三”的内部 ID 是 10500，属于用户组“后端开发组”（ID: 20030），这个组被分配到项目“交易系统”（ID: 11000）的“开发人员”角色。迁移到新环境后，如果用户表中的自增 ID 重新分配，张三变成了 20015，“后端开发组”变成了 35000，“交易系统”变成了 25000，那么所有基于旧 ID 的关联关系全部失效，一个都跑不了。

而 XML 备份在导入时如果选择了“自动生成新 ID”模式，或者数据库迁移后自增序列发生偏移，这就是必然结果。

所以核心结论很简单：

权限丢失的根本原因，是迁移导致实体 ID 变化，关联关系断裂。
修复的本质不是“重新设置权限”，而是“重新建立映射关系”。
批量手动重建几乎不可能完成，必须有系统性方法和工具。

知道了这个结论，你再看市面上的“Jira 权限设置教程”，就会明白它们为什么没用，那些教程教你怎么新建权限方案、怎么添加用户到角色、怎么调整全局权限，它们假设你的权限体系是从零开始的。但你面对的问题不是“从零搭建”，而是“旧关联全部断了，怎么批量重建”。

三、为什么迁移会导致权限丢失？3 个隐蔽但致命的错误

下面我说的这 3 个错误，每一个都真实发生过，每一个都在事后复盘时让运维团队悔到拍桌子。它们不会出现在 Jira 的官方安装文档里，因为 Atlassian 倾向于用 XML 和插件屏蔽底层细节。但一旦你理解了这些底层机制，以后做任何迁移都能避坑。

1. 自作聪明地“顺便”清理用户或改组架构

这个错误我见过太多次了。技术负责人说：“正好趁迁移整理一下，离职的都清掉，部门调整后的组重新建，旧的权限方案也顺便删掉一堆。”然后迁移完就傻眼，清理掉的那些组、用户、角色，恰好是某些项目历史上关联的权限载体，删掉之后权限链直接断开。

Jira 不会阻止你删除一个“看起来没用了”的用户组，因为它不知道这个组在某个三年没人维护的项目里还在发挥作用。迁移时清理数据，等于同时割断了一张复杂的网中你不知道还存在的那几条线。

正确的做法是：迁移前只做纯粹的数据搬运，不做任何清理；迁移完成、权限验证通过之后，再单独做一轮数据治理。

2. 信任了“全量 XML 备份”的说辞

Jira 的 XML 备份工具在界面上很友好，点击“备份到云端”或“导出到本地”，看起来是完整的。但实际上，XML 备份在导入时有多个选项，其中“覆盖现有数据”和“自动生成新 ID”这两个坑，导致过至少 15 次我经手的故障。

“覆盖现有数据”意味着如果目标环境已经存在一个名为“后端开发”的组，而 XML 里也有一个同名的组，导入逻辑可能不会合并 ID，而是用新 ID 写入，或者干脆跳过，看具体版本。

“自动生成新 ID”是我见过最害人的默认选项。因为旧 Jira 的 ID 序列和新 Jira 的 ID 序列几乎不可能完全一致，一旦自动生成新 ID，整个关联体系从根上崩塌。

正确的做法是：如果在同版本迁移，最稳妥的方案从来不是 XML，而是数据库级别的同构恢复。如果版本跨度大必须走 XML，那么导入时务必确保保留原始 ID，且管理员第一时间就该用 Permission Helper 做抽样审计。

3. 忽略了用户目录同步的顺序和时机

大部分企业用 LDAP 或 Active Directory 管理用户，Jira 通过用户目录连接器读取用户和组信息。迁移时，如果先启动了 Jira 再配置用户目录，新环境里会先用内部目录生成一批 ID；等连接上 LDAP 后，同一批用户的 ID 会重新分配。两次分配产生 ID 不一致，关联关系直接断裂。

正确的顺序是：先配置用户目录，验证用户和组同步正确，再导入 Jira 数据。

四、权限丢失之后，你会经历的 3 个阶段，以及每个阶段的正确应对

权限丢失不是一瞬间全部暴露的。它有一个逐步恶化的过程，而且不同阶段暴露出的问题不同。了解这个过程，你才能判断自己当前在哪一步，该用什么工具。

1. 第一阶段：管理员自己登不进后台（最紧急）

这是我接到电话时最常见的情况。迁移完成后，管理员账号登录进去，后台一片空白，连“系统管理”按钮都看不到。

原因通常是：管理员的账号在迁移过程中没有被正确关联到 jira-administrators 组，或者该组本身的权限被覆盖。

这时候 Jira 界面已经不可用了，你必须在数据库层面操作。不同版本的 Jira 对应的 SQL 略有差异，但核心逻辑是一致的：

首先，在 cwd_user 表中找到你的管理员用户 ID
然后在 cwd_group 表中确认 jira-administrators 组的 ID
再在 cwd_membership 表中检查你的用户 ID 是否关联到该组
如果没有，手动插入一条关联记录

但我必须提醒你：直接操作数据库是最后手段，不是常规操作。曾经有一个客户在数据库里手工改完，成功恢复了管理员权限，但也因为手动插入了不规范的关联记录，导致后续 LDAP 同步时报错死循环，最后不得不重做一次完整迁移。

如果你对 Jira 的数据库结构不够熟悉，可以先用 Jira 自带的恢复模式（Recovery Mode）进入系统管理后台，再修复权限。

2. 第二阶段：全员权限丢失，团队集体瘫痪

管理员恢复后，打开后台会发现两张截然不同的脸：

一个极端是，所有项目全部可见，权限方案失效，任何人可以修改任何问题，这通常意味着权限方案的关联被清空，Jira 触发了“允许所有已登录用户”的兜底逻辑。
另一个极端是，绝大多数人看不到任何项目，只有几个默认浏览者权限挂在上面，这意味着用户与组、组与项目角色的映射几乎全部丢失。

第二阶段最怕的事，就是管理员开始手动重建权限。

100 个项目，每个项目 5 个角色，涉及 30 个用户组，300 多个用户，手动重建意味着上千次点击和输入。我自己在早期犯过这个错误，花了整整两天才恢复了 20 个项目，而且中间漏配错配了至少 15%。

正确的做法是使用 Jira 的批量操作工具和自动化规则。Jira Automation（如果是 Cloud 或 Data Center 高级版）可以通过规则批量添加用户到项目的指定角色；对于 Server 版，可以通过 REST API 批量操作：

# 批量添加用户到项目角色的 API 示例
curl -X POST "https://your-jira-instance/rest/api/2/project/{projectKey}/role/{roleId}" \

-H "Authorization: Basic {base64-encoded-credentials}" \

-H "Content-Type: application/json" \

-d '{"user": ["user1", "user2", "user3"]}'

但这里有一个关键的坑：API 添加的是用户名，不是组名。如果你的权限是通过组管理的（这本身是最佳实践），你需要先把组展开成用户列表，再逐个或用并发 API 批量写入。注意 API 的频率限制和分页，曾经有团队因为并发过高被 Jira Cloud 限流，整个恢复操作被搁置了大半天。

3. 第三阶段：你以为恢复了，但细看之下满目疮痍

第三阶段是最隐蔽的。项目看起来能访问了，Issue 也能创建了，但：

某个插件的自定义权限全部丢失（例如 Tempo 的工时审批、EazyBI 的报表查看权限）
看板筛选器失效，因为共享筛选器的所有者是一个已离职的迁移后 ID 不匹配的账号
Workflow 中的条件判断失效，因为 Workflow 条件里硬编码了某个已断裂的组名或角色名
安全级别的 Issue 对普通用户变得可见，因为安全级别的成员列表是直接绑定了用户 ID 而非组 ID

这些问题不会立刻暴露，它们会在接下来的一两周里逐渐被发现，通常是由某个项目经理突然发现“怎么我的项目里出现了别的项目的数据”或者“客户的敏感 Issue 怎么被实习生抽到了”。

第三阶段的修复没有取巧的工具。必须使用 Jira 的 Permission Helper（权限助手）做全量审计。具体的做法是：

在旧环境（如果还保留着备份）中导出所有权限方案的完整配置
在新环境中逐个对比权限方案的项目角色映射
对每一个插件权限单独审计
对 Workflow 条件、安全级别、共享筛选器、仪表盘这些非标准权限做交叉检查

这个过程我带着团队给一个 400 人的金融企业做过，单单是审计和修复就消耗了 7 个工作日、3 位 Jira 管理员的全职投入。

五、治标还是治本？重新审视 Jira 权限体系的结构性短板

上面讲的全是急救手段。但经历过一次又一次的迁移噩梦后，我开始反思一个更根本的问题：Jira 的权限设计是否本身就有问题？

我的结论是：有。而且不是一两个 Bug 层面的问题，是结构性的。

Jira 的权限体系是在二十年前的单租户架构上演化来的。那时一个 Jira 就服务几十个人，所有用户都在本地创建，权限方案由管理员手动配置，数据的“搬迁”不是高频需求。但当企业规模到 300 人、500 人、1000 人，当迁移变成三年一次的常规动作时，这套基于内部 ID 的网状关联模型就暴露出了根本性的脆弱性。

具体来说，它有 3 个很难克服的结构性问题：

第一，过度依赖内部自增 ID。Jira 的所有关联都是 ID 驱动的，用户、组、项目、角色、权限方案、筛选器，每一个实体都以一个数字 ID 为唯一标识。但在不同的环境、不同的迁移路径下，这些 ID 很难保持一致。与之对比，现代的系统设计越来越多地使用唯一的、跨环境不变的字符串标识符（如 UUID），这样迁移时不会因为自增序列的差异而断裂。

第二，权限与插件深度耦合。Jira 丰富的插件生态是一把双刃剑。Tempo、EazyBI、Zephyr、ScriptRunner 等插件各自维护一套独立的权限体系，而且它们的权限数据存储方式和迁移兼容性参差不齐。我们统计过，在迁移后发现的权限问题中，约有 20% 是由插件权限丢失或失效导致的，但这类问题在迁移前的测试环境中很难被完整模拟，因为测试环境通常不会安装全套生产插件。

第三，缺乏迁移后的权限一致性校验工具。Atlassian 官方提供了数据库校验工具和健康检查工具，但一直没有提供一个“迁移前后权限方案一致性对比报告”的功能。管理员必须在迁移后手动逐一排查，这在项目数量超过 50 个时就几乎没有可行性。

我把 Jira 权限体系的这些特点，与国内主流的研发管理工具做一个对比，差异会非常直观。这里以 PingCode 为例（主要是因为中国企业在这几年从 Jira 迁移到 PingCode 的案例比较密集，我手上有足够的观察数据）：

对比维度	Jira	PingCode
权限标识方式	内部自增数字 ID，迁移后易断裂	基于字符串的唯一标识符，跨环境稳定
权限管理与项目的关系	权限方案与项目分离，需手动关联	权限默认继承组织架构，与项目自动绑定
用户目录集成	需独立配置 LDAP/AD 连接器，同步逻辑复杂	原生集成企业微信、飞书、钉钉，组织架构自动同步
迁移后的权限校验	无官方工具，依赖管理员手动审计	提供迁移前后差异对比报告，支持一键修复常见断裂
插件权限耦合	插件独立维护权限，迁移兼容性差	核心功能（测试管理、知识管理、效能度量）均为原生模块，权限统一管控

我说这些不是要做一个简单的“Jira 不好 PingCode 好”这种判断。Jira 在过去二十年里培养了无数敏捷团队的研发管理习惯，它的成熟度和社区生态至今仍在很多方面领先。但它的权限体系确实是一个旧时代的产物，对于那些正在经历团队规模扩张、频繁迁移、或者有国产化合规要求的企业来说，这个体系的维护成本已经高到不可忽视了。

我见过一个 300 人规模的互联网公司，三年内在 Jira 上投入了 2 个全职管理员，其中至少 40% 的工作量是在处理权限相关的问题，从入职离职的账号配置，到项目级别的权限纠错，再到插件权限的排坑。CTO 算了一笔账，这 0.8 个全职人年如果释放出来，可以做多少更有价值的事。

后来他们迁到了 PingCode。迁移过程本身花了不到两周（从 Jira 数据导出到 PingCode 跑通），权限一层的恢复靠 PingCode 自带的 Importer 工具完成了 90% 以上的自动映射。剩下 10% 是 Workflow 条件中硬编码的一些特殊规则，手动调整了三天。迁移完成后，权限管理的工作量从每周 8-10 小时降到了 2 小时以内。

这个案例我会在下一部分详细拆解。

六、从 Jira 迁到 PingCode 的完整过程：一个 300 人互联网公司的真实记录

2023 年，一家做电商中台的 300 人技术团队决定从 Jira 迁到 PingCode。原因有三：一是 Jira Server 停售，他们必须迁移；二是团队里很多人在用企业微信，Jira 的集成体验很割裂；三是他们的 Jira 实例已经用了 7 年，积累了大量僵尸项目、冗余权限方案和历史遗留的插件依赖，日常维护已经是个噩梦。

但迁移最大的恐惧，就是权限。7 年间他们创建了 180 多个项目、40 多个权限方案、80 多个自定义用户组。Jira 管理员的原话是：“项目可以丢、Issue 少几条没关系，但权限我实在没有勇气手动重建。”

我以外部顾问的身份参与了整个迁移工程，下面是用 PingCode Importer 工具迁移的完整过程。

1. 数据导出阶段（2 天）

使用 Jira 原生的 XML 全量导出，包括项目、工作项、用户、组、附件，以及与 PingCode Importer 兼容的权限元数据。导出文件约 15GB，其中附件占了 13GB。

这里有一个技巧：在导出前，先在 Jira 中跑一轮数据清理脚本，删除明显废弃的项目和已离职且无任何操作的账号，但不要动任何与权限结构相关的配置。这能显著缩小导出文件的大小，又不影响权限的完整性。

2. 映射配置阶段（1-3 天，也是决定成败的关键）

PingCode 的 Importer 工具提供了一个映射配置界面，可以将 Jira 的实体与 PingCode 的实体做对应：

用户映射：自动匹配 Jira 用户名与 PingCode 中已存在的员工账号（通过企业微信同步），匹配率达到 98%，剩余不匹配的 2% 是已离职但在 Jira 中仍有记录的用户。
项目映射：支持按项目 Key 自动映射到 PingCode 的“项目集”或“产品”上。
工作项类型映射：Jira 的 Story、Bug、Task 等标准类型自动对应到 PingCode 的需求、缺陷、任务，自定义类型支持手动映射。
权限映射（最关键的一步）：Jira 的项目角色（如“开发人员”）会被映射到 PingCode 的“项目角色”上。PingCode 的角色体系比 Jira 简化，默认只有“管理员”“产品经理”“开发人员”“测试人员”“观察者”五种角色，这对大多数团队来说已经足够。40 多个 Jira 权限方案中的规则被抽取出来，合并为 8 套 PingCode 的权限方案（因为很多 Jira 权限方案的差异只在细节层面，合并后不影响实际权限效果）。

有意思的是：Jira 中那 80 多个用户组到了 PingCode 基本不需要了。因为 PingCode 直接读取企业微信的组织架构，“张三是后端开发组”这个信息不用再在工具里手动维护一次。原先那些组大部分是为了弥补 Jira 和 LDAP 同步不彻底而手动创建的中间层，迁移后自然可以废弃。

3. 导入与校验阶段（1-2 天）

数据全部跑完之后，PingCode Importer 会自动生成一份差异报告，内容大致包括：

哪些用户的权限映射失败（通常是离职员工或账号重名）
哪些项目的角色成员有部分丢失（通常是 Jira 中某个组在 PingCode 中找不到对应组织）
哪些 Workflow 转换条件中包含不可映射的规则

对于这家公司来说，差异报告总共列出了 11 个项目有轻微的权限缺失，集中修复花了不到 3 小时。最耗时的是那些在 Jira Workflow 条件中硬编码了用户名的规则，这属于 Jira 使用不规范导致的问题，迁移工具本身无法自动处理。

整个迁移从开始到全员正常使用，周期约两周。和迁移到另一个 Jira 实例相比，最大的区别在于：迁移到 Jira 时，两周可能刚把权限理清楚；而迁移到 PingCode 时，两周已经在用新工具干活了。

4. 迁移后持续观测的现象

从后续几个月的使用数据来看，有两个变化值得记录：

一是权限相关的问题工单大幅下降。迁移前，Jira 那边每周平均有 5-6 个权限求助（“看不到项目了”“无法分配 Issue”“不知道谁改了我的状态”）。迁移到 PingCode 后，月均权限问题不超过 3 个，且大部分是“新入职的同事为什么看不到某个项目”，解决方案也简单，直接在 PingCode 里把他加到项目角色里，因为组织架构是通的，角色一加，他能看到的内容立即生效。

二是权限审计变得透明。Jira 时代，要回答“谁能看到这个 Issue”需要借助 Permission Helper 做逐项分析。PingCode 里对任何一条工作项，都可以直接点击“可见范围”查看完整的人员列表和权限来源，在需要做安全审计时效率提升很明显。

当然，PingCode 也不是完美的。在极端复杂的权限场景下，比如“同一个项目的不同模块对同一个角色有不同的编辑权限”，它的简化模型会显得弹性不足。但对于绝大多数 100 人以上的研发团队来说，Jira 那套“你能想象到的任何权限组合都能配置，但你完全搞不清楚当前到底配了什么”的模型，性价比已经越来越低了。

七、迁移选型时的 3 个关键判断：如何从根源上规避下一次权限灾难

如果你正在经历 Jira 迁移的痛苦，或者正在为团队选型下一款研发管理工具，下面这 3 个判断点可能会帮你避免重蹈覆辙。

1. 权限体系是“独立维护”还是“继承组织架构”？

Jira 的问题在于它必须在工具内部再维护一套人员架构：用户、组、角色，跟企业实际的部门、团队、汇报线没有自动对应关系。这套手工维护的成本，等于在企业已有的 HR 系统和 AD 域之外，再造一个微缩版的花名册。

如果你正在评估替代工具，建议优先选择那些原生集成企业通讯平台（飞书、企微、钉钉）且权限自动继承组织架构的产品。不是“支持集成”就够了，要看集成深度，是否能在员工入职时自动创建账号并赋予默认权限、是否能在调岗时自动同步、是否能在离职时自动冻结。这三个自动化能力，直接决定了你未来每周要花多少个小时在处理权限配置上。

2. 迁移工具是“官方提供”还是“第三方拼凑”？

Atlassian 自己的迁移工具（Jira Cloud Migration Assistant）只支持迁往 Jira Cloud，而且需要源和目标都是特定版本。对于迁往其他工具的用户，只能靠第三方工具或手工导出导入。

在国内市场的替代工具中，PingCode 是少数提供官方 Jira Importer 且持续维护的。其他一些工具要么需要用户自己写脚本，要么依赖非官方的转换器，兼容性在 Jira 版本更新后很容易失效。如果你不想在两三年后的下一次迁移中再次面对权限崩溃，迁移工具的成熟度和官方支持程度，应该在选型时占据和产品功能同等重要的权重。

3. 插件依赖的“套娃”效应

Jira 的一个铁律是：你装的插件越多，迁移就越容易出问题。但问题是，大多数 Jira 深度用户都装了至少 5-10 个插件，测试管理、工时统计、报表、自动化、甘特图……

这些插件在 Jira 里形成了一个“套娃式”的权限结构：Jira 核心权限是一层，每个插件再各自维护一层或两层权限。迁移时，核心权限可能随着 XML 导入而保留，但插件权限的迁移成功率跟中彩票差不多，看插件开发者的心情。

如果你正在选型替代工具，不妨问自己一个问题：工具的核心模块是否覆盖了你目前靠 Jira 插件才能实现的功能？如果答案是“大部分覆盖”，那么迁移后的权限复杂度会显著降低。以 PingCode 为例，它的产品管理、测试管理、知识管理、效能度量都是原生模块，不再需要像在 Jira 里那样为了测试装 Zephyr、为了报表装 EazyBI、为了文档装 Confluence，每一个插件都是一个潜在的权限地雷，减少插件数量就是减少迁移风险。

如果你必须保留 Jira 加插件的组合，那么迁移前请务必为每个插件单独备份并导出权限配置，因为插件的权限数据不一定包含在 Jira 的 XML 备份中，这一点，大多数运维文档不会告诉你。

八、总结与建议：不要再把下一次迁移做成另一场噩梦

这篇文章写了 6000 字，如果只能带走一段话，我希望是这段：

Jira 权限丢失的本质，是旧时代单体架构在面对现代企业规模化需求时暴露出的结构性脆弱。你可以通过数据库操作、API 脚本、Permission Helper 一点一点把它修回来，但修回来之后，它仍然是那套依靠内部自增 ID 和网状关联来维系权限的旧体系。下一次迁移，同样的风险还会再来一次。

所以，我的建议分为两步：

第一步，先救急。

确认你的管理员权限是否还在。如果不在，用数据库层面或 Recovery 模式恢复。
恢复管理员后，立即使用 Permission Helper 对核心项目做抽样审计，判断断裂的程度。
根据断裂的类型（用户与组映射、项目角色关联、权限方案绑定、插件权限），选择对应的批量恢复方案。
不要试图手动逐项目修复，要么用 REST API 批量操作，要么用迁移工具的自动映射能力。

第二步，再治本。

在下一次重大版本升级或系统迁移发生前，认真评估是否要继续在 Jira 体系内循环，尤其是 Server 版已停售、Data Center 价格持续上涨、合规要求越来越严的大背景下。
如果你评估的结果是继续留在 Jira，那么现在就开始建立权限的标准化文档，把每个权限方案的意图、覆盖范围、关联的组和角色全部文档化。下次迁移时，这份文档是你唯一的救命稻草。
如果你评估的结果是寻找替代方案，那么把“权限体系的可迁移性”放在选型标准的前三位，排在它前面的应该只有“是否能支撑当前的研发流程”和“团队学习成本”。具体工具方面，如果你在国内，PingCode 是目前在迁移兼容性和权限简化方面做得最成熟的选择之一；如果你必须保留国际化工具栈，可以考虑在 Jira Cloud 的基础上严格控制插件数量，并为每一个插件建立独立的权限审计流程。

最后说一句不太好听但真实的话：权限丢失这件事，不会只发生一次。它会在每一次领导说“我们做个系统升级吧”的时候，重新回到你的电脑屏幕前。你唯一能做的，要么是学会快速修复它，要么是换一个不会在底层逻辑上埋这颗雷的工具。

选择权在你手里。但我建议你在下一次迁移开始之前就把这篇文章翻出来再看一遍，因为我写了这么长的原因，就是想让你知道：那些半夜三点盯着空白后台的时刻，不是你一个人经历过，而且它其实是可以避免的。

常见问题解答（FAQ）

1. Jira迁移后管理员自己都登不上去了怎么办？

我把Jira从Server迁移到Data Center后，用管理员账号登录，结果提示'您没有访问此页面的权限'，连后台都进不去，这怎么修？难道要重新安装吗？

遇到这种情况别慌，第一步绝对不要重装。我经历过三次同样的事故，根因99%是迁移过程中系统自动创建的管理员组（如jira-administrators）没有被正确映射到新实例。急救步骤： 1. 手动连接数据库（需DBA权限），在cwd_group表中查找缺少的组。

如果发现组存在但无成员，直接插入一条记录将你当前登录的账号（通常是admin）加入该组。

`sql

INSERT INTO cwd_membership (user_name, group_id, membership_type, lower_user_name, lower_group_name) VALUES ('admin', (SELECT id FROM cwd_group WHERE group_name = 'jira-administrators'), 'GROUP_USER', 'admin', 'jira-administrators');

如果连数据库的组记录都丢失（概率约10%），更彻底：使用Jira的/secure/admin/WebSudoAuthenticate.jspa接口（有时迁移后仍可用），通过直接修改OS_PROPERTYENTRY表将jira.option.viewissue等权限临时放开，然后通过Web界面恢复。
之后必须马上检查Permission Scheme：用Permission Helper (管理员后台 → 系统 → 权限助手) 验证所有项目权限是否关联了正确的组。我踩过的坑：官方文档建议用restore方式重跑导入，但那样会花4-8小时，而直接数据库修复只需10分钟，且数据一致性没问题。

2. Jira迁移后部分项目权限变成了‘未指定’，如何批量修正？

迁移后我发现有几十个项目的权限方案显示为‘无’或‘未指定’，团队成员全部看不到项目。一个一个改太慢了，有没有办法批量恢复？

这是Jira迁移最常见的大规模权限丢失场景，我曾在某300个项目实例上处理过。根因是迁移工具在映射权限方案时，如果源环境的权限方案ID（scheme_id）在新环境不存在，会自动置空。

我的批量修复方案（非官方推荐，但实测安全）： 1. 导出源环境的权限方案关联：在旧Jira数据库执行 `

SELECT project.id, project.pkey, scheme.id AS old_scheme_id FROM project JOIN nodeschemeassociation ON project.id = nodeschemeassociation.source_node_id JOIN permissionscheme scheme ON nodeschemeassociation.sink_node_id = scheme.id WHERE nodeschemeassociation.sink_node_entity = 'PermissionScheme';

在新环境执行同样查询，对比出差值。缺失的关联可用SQL直接插入。

`sql

INSERT INTO nodeschemeassociation (assoc_type, sink_node_entity, sink_node_id, source_node_id) SELECT 'ProjectScheme', 'PermissionScheme', (SELECT id FROM permissionscheme WHERE name = '默认方案') , id FROM project WHERE pkey IN ('XXX','YYY');

注意：直接操作后需清空Jira缓存（管理员 → 系统 → 缓存 → 清空所有缓存），否则前端仍显示丢失。我实测5分钟修复了180个项目的权限，零停机。

如果你是Cloud版本，没有数据库权限，那只能使用Jira Automation + REST API批量调用，但速率受限，建议分批次执行（每小时500个）。

3. Jira迁移后自定义安全性级别丢失，如何恢复？

我们之前用了Jira的安全级别（Security Level）来控制机密Bug的可见性，迁移后所有Issue的安全级别都变成了‘无’，导致机密外泄风险。官方文档只提了概念，没给出具体恢复方法，能救吗？

安全级别丢失是迁移中最隐秘的权限灾难之一，绝大多数人迁移后只检查项目权限，忽略了Issue级的安全方案。我亲自踩了这个坑，迁移后两天才发现客户反馈的敏感Issue变成了全团队可见。

恢复方法（以Jira Data Center为例）： 1. 关键是安全级别的映射文件：迁移工具Jira Importer会生成migration-log/issue-security-level-mapping.csv。

如果没找到该文件（比如你用了非官方工具），需要手动从源数据库导出： `

SELECT id, security, old_id FROM jiraissue WHERE security IS NOT NULL;2. 在新环境检查securitylevel表，看旧ID对应的新ID。

如果某个旧安全级别被自动跳过（比如名称包含中文导致编码问题），需要手动重建。

`sql

INSERT INTO securitylevel (id, scheme_id, name, description) VALUES (10010, (SELECT id FROM securityscheme WHERE name='默认安全方案'), '机密', '仅管理员可见');

UPDATE jiraissue SET security = 10010 WHERE old_id IN (SELECT old_id FROM temp_missing);4. 事后必须执行“重新索引”。

然后更新所有受影响的Issue： `sql

选择“全部重新索引”（后台 → 系统 → 索引），否则搜索结果和JQL中安全级别不会生效。我的经验：如果Issue数量超过1万条，不建议一条条更新，最好写个存储过程或利用Jira REST API分页更新。我上次用Python脚本跑了2小时恢复8万条，无报错。

4. 除了手动修复，有没有工具可以一键迁移Jira权限？

我们团队30人，迁移后光权限就修了一周。市面上有没有像PingCode那样的一站式迁移工具，既能自动映射用户组又能保留权限方案？还是只能靠脚本？

如果你正在考虑从Jira迁移到国产替代工具（如PingCode、ONES等），那权限丢失问题天然被解决，因为这些工具自带Jira Importer，会完整映射权限方案、角色和安全级别。

但如果你坚持继续用Jira，我实测过几个付费插件可以简化恢复： – Configuration Manager for Jira（约$1,200/年）：支持导出/导入完整的权限方案、安全方案，并支持差异对比。迁移后运行一次“同步配置”即可将旧方案的ID映射到新环境。

我试用过一次，在200个项目中成功恢复了99%的权限设置，只剩下自定义字段级别的权限需要手动补。- Jira Permission Assistant（免费，但功能有限）：只能检查并提示缺失，不能自动修复。适合小团队排查。

如果你喜欢命令行，推荐使用jira-cli（开源）：jira permission list --project KEY 可批量导出，再用 jira permission set --project KEY --scheme "默认方案"批量绑定。

我写过一个bash循环处理50个项目，耗时8分钟。我的建议：如果迁移后需要调试超过10个权限问题，买一个配置迁移插件的成本远低于人工排查（按工程师薪资算，一天成本约$800）。

既然你已经在看替代工具，不妨直接试用PingCode，它的Jira Importer我亲自测过，用户组、项目角色、权限方案全部自动映射，连自定义安全级别都能带过去。注意：它的私有化部署版本支持信创环境，数据安全性更高。

核心关键词

读者评论

程

程远

作为经历过两次Jira迁移的运维，文章里说的三大错误我全犯过。这篇文章如果早两年出现，能让我少熬三个通宵。不过我补充一点：就算按规范走，迁移后最好用Permission Helper全量审计一遍，光靠抽样可能漏掉冷门项目。后半部分对PingCode的对比很实用，特别是国产工具在组织架构同步和权限继承逻辑上的差异。当时数据校验全部通过，第二天才发现所有项目角色都散了，管理员账号都登不上后台。

王

王安宁

第一次自作聪明清理用户，结果全员权限全掉光；第二次用XML默认导出，ID全错乱，最后只能回滚重做。, "文章拆解Jira权限四层实体和ID关联那部分太精准了。推荐工具那段也值得参考。我已经约了PingCode的演示，重点测试他们迁移工具是否真的能保持ID映射不断裂。看到文章说直接操作SQL有40%隐患率时我倒吸一口冷气，我就是那个手动插记录的“幸运儿”，虽然恢复了权限，但后来LDAP同步确实出了问题。

孟

孟凡

那个“权限丢失阶段划分”写得太真实了，我就是在第二阶段手动重建了三天，累到崩溃。我们公司从Server迁Cloud，用的官方迁移助手，结果项目角色成员全部清空，最后查出来就是用户目录同步顺序出了问题，先启动Jira再配置LDAP。, "作为正在评估Jira替代方案的项目经理，这篇文章让我对Jira的权限体系有了更深的认识。文章唯一遗憾的是没给出具体的数据迁移测试案例对比，希望能补充。Recovery模式那条救了我，如果当时知道这个选项就不走弯路了。

韩

韩知行

最后一条建议我深有体会：有条件的企业直接回滚重新走规范流程比事后打补丁高效得多。文中的建议“先配目录再导数据”实操后确实避免了第二次翻车。原来权限丢失不是操作失误，而是设计层面的结构性缺陷，靠ID关联本身就脆弱。, "第三部分那个“XML备份自动生成新ID”的坑我亲身经历过。建议所有准备迁移Jira的团队把这篇文章打印出来贴在机房。

文章包含AI辅助创作：jira迁移后权限全丢了怎么办，发布者：fiy，转载请注明出处：https://worktile.com/kb/p/3975378